[idn] draft-ietf-aceid

["James Seng/Personal" <James@Seng.cc>]

> Date: Fri, 8 Dec 2000 06:16:10 +0900 (JST)
> Message-Id: <200012072116.GAA18670@pc92.nic.ad.jp>
> To: idn@ops.ietf.org
> CC: idn-tf@nic.ad.jp
> Subject: draft-ietf-aceid
> From: maruyama@nic.ad.jp
>
> Hi folks.
>
> We revised draft-ietf-idn-aceid to version 01.  I enclose it.
>
> See you soon.
>
> -- Masa
>
> ----
> NaoMASA Maruyama (Vice President of JPNIC)
> maruyama@nic.ad.jp
>
> ----------------------------------------------------------------
> Internet Draft                                      Naomasa Maruyama
> draft-ietf-idn-aceid-01.txt                           Yoshiro Yoneya
> Dec 8, 2000                                              JPNIC
> Expires June 8, 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 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 head of at least one label of the
> domain name and those which have an ACE suffix identifier candidate at
> the tail of at least one label 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 or other organ of IETF or ICANN 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. Changes from the previous version
>
>     We excluded suffixes of one hyphen followed by three alpha-
> numericals from the candidates.  This is because we found that, as of
> Nov. 29, 2000, there were 23,921 domain name registration in the .JP
> space relevant to these suffixes.  This was more than 10% of 227,852
> total registraions in the JPNIC database at the moment, and hence we
> felt these suffixes are not good candidates.
>
>     In addtion to this and some minor linguistic corrections, we
> changed "IDN WG" in section 2.3 to "IDN WG or other organ of IETF or
> ICANN".
>
>
> 7. 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.
>
>
> 8. Acknowledgements
>
>     We would like to express our herity thanks to members of JPNIC IDN
> Task Force for valuable discussions about this issue.  We also woould
> like to express our appreciation to Mr. Dave Crocker for checking and
> correcting the preliminary version of this draft.
>
>
> 9. 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
>