Internet Draft                                      Naomasa Maruyama 
draft-ietf-idn-aceid-00.txt                           Yoshiro Yoneya 
November 17, 2000                                              JPNIC 
Expires May 17, 2001

           Proposal for a determining process of ACE identifier

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

Abstract

    In IETF IDN WG, various kinds of ASCII Compatible Encodings,
hereafter abbreviated as "ACE", are discussed as methods for realizing
multilingual domain names (hereafter referred to as "MDN").  Each ACE
uses a prefix or a suffix as an identifier in order for MDNs to fit
within the existing ASCII domain name space.  In other words,
acceptance of an ACE proposal as an Internet standard means that the
existing ASCII domain name space will be partitioned, in order to
accommodate MDN space.

    This document describes possible trouble in the standardization
process of ACE, and proposes a solution for it.


1. Present situation and concern

    At present, some specifications relating to MDN specify their own
ACE identifiers.  In these drafts, multilingual domain names encoded
into ASCII character strings, with the ACE identifiers in their heads
or tails, are merely ASCII character strings.  It is possible
accidently or intentionally to register a domain name that is not an
MDN but has the designated ACE identifier string.

    If this kind of registration takes place, there is no warranty
that the domain name will be consistent with MDN semantics.
Furthermore, there is no warranty that the name, interpreted as an
MDN, will comply with the registration policies of the registry, when
the ACE identifier proposal is finally accepted as an Internet
standard.  This might cause problems with name disputes and/or
revocations.

    Therefore, the current situation letting independent ACE proposal
authors arbitrarily select an ACE identifier, hence permitting domain
name registrants registrer such names, may hinder deployment of MDN
technology.


2. Selecting ACE identifiers

    In order to maintain a smooth standardization process for ACE,
this document proposes a strategy for selecting and reserving of ACE
identifiers and a method for assigning them.


2.1 The ACE identifier candidates and tentative suspension of
     registering relevant domain names

    All strings starting with a combination of two alpha-numericals,
followed by two hyphens, are defined to be ACE prefix identifier
candidates.  All strings starting with one hyphen followed by three
alpha-numericals, and strings starting with two hyphens followed by
two alpha-numericals are defined as ACE suffix identifier candidates.
ACE prefix identifier candidates and ACE suffix identifier candidates
are collectively called ACE identifier candidates.

    All the domain name registries recognized by ICANN SHOULD
tentatively suspend registration of domain names which have an ACE
prefix identifier candidate at the heads of one of the labels of the
domain name and those which have an ACE suffix identifier candidate at
the tail of one of the labels of the name.  These domain names are
collectively called "relevant domain names".

    This suspension should be continued until March 1, 2001 00:00:00 UTC.


2.2 Survey of relevant domain name registration

    All registries recognized by ICANN SHOULD conduct a survey about
relevant domain names registered in their zone, and report, no later
than February 10, 2001 00:00:00 UTC, all of the ACE identifier
candidates which are used by relevant domain names.


2.3 Selection of ACE identifiers and permanent blocking of
     relevant domain names

    The IDN WG MUST summarize the reports and list ACE identifier
candidates that are not reported to be used in registered domain names
by February 17, 2001 00:00:00 UTC, and select ten to twenty ACE prefix
identifier candidates and ten to twenty ACE suffix identifier
candidates for ACE identifiers.  Among these twenty to forty ACE
identifiers, one prefix identifier and one suffix identifier will be
used for experiments.  Others will be used, one by one as ACE standard
evolves.

    The list of ACE identifiers will be sent to IANA, and will be
maintained by IANA from February 24, 2001 00:00:00 UTC.  Domain names
relevant to these identifiers SHOULD NOT be registered in any DNS
zone, except for registration of multilingual domain names compliant
to one of future IDN standards.  This new restriction about the domain
name space will be notified to all ICANN recognized registries by IANA
immediately after it receives the list.


2.4 Blocking of registration for relevant domain names

    Domain names relevant to ACE identifiers selected by the procedure
described in section 2.3 SHOULD NOT be registered in any zone of ICANN
recognized registries except for registration of multilingual domain
names compliant to one of future IDN standards.  All ICANN recognized
registries SHOULD implement this restriction no later than March 1,
2001 00:00:00 UTC.

    Registration for domain names relevant to ACE identifier
candidates, tentatively suspended by 2.1, but not relevant to ACE
identifiers selected by section 2.3 MAY be reopened from March 1, 2001
00:00:00 UTC.


3. Use of an ACE identifier in writing an ACE proposal

    When writing an ACE proposal using an ACE identifier, the author
SHOULD either describe the ACE identifier as "to be decided" and left
to discretion of the IDN WG or other organ of IETF or ICANN, or use
either of the ACE identifiers for experiment defined in section 2.3,
with a unique version number added after or before the prefix or
suffix.

    If a proposal is validated and published as an Internet Draft, the
IDN WG or other organ of IETF or ICANN MUST replace the "to be
decided" part with an experimental identifier with a unique version
number added after or before the prefix or the suffix.


4. Determination of ACE identifier

    When an Internet Draft relating to ACE is accepted as an Internet
standard and becomes an RFC, IDN WG or other organ of IETF or ICANN
MUST replace the experimental ACE identifier, augmented by the version
number, with one of the ACE identifiers.


5. Security considerations

None in particular.


6. References

[IDNREQ]        Z Wenzel, J Seng, "Requirements of Internationalized Domain
                Names", draft-ietf-idn-requirements-03.txt, Jun 2000.

[RACE]          P Hoffman, "RACE: Row-based ASCII Compatible Encoding for
                IDN", draft-ietf-idn-race-02.txt, Oct 2000.

[BRACE]         A Costello, "BRACE: Bi-mode Row-based ASCII-Compatible
                Encoding for IDN", draft-ietf-idn-brace-00.txt, Sep 2000.

[LACE]          P Hoffman, "LACE: Length-based ASCII Compatible Encoding for
                IDN", draft-ietf-idn-lace-00.txt, Nov 2000.

[VERSION]       M Blanchet, "Handling versions of internationalized domain
                names protocols", draft-ietf-idn-version-00.txt, Nov 2000.


7. Acknowledgements

JPNIC IDN-TF members,
Dave Crocker.

8. Author's Address

Naomasa Maruyama
Japan Network Information Center
Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
Chiyoda-ku Tokyo 101-0052, Japan
maruyama@nic.ad.jp

Yoshiro Yoneya
Japan Network Information Center
Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
Chiyoda-ku Tokyo 101-0052, Japan
yone@nic.ad.jp
