idnits 2.17.1 draft-ietf-idn-aceid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 202 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 81: '... registries recognized by ICANN SHOULD...' RFC 2119 keyword, line 92: '...ognized by ICANN SHOULD conduct a surv...' RFC 2119 keyword, line 100: '... The IDN WG MUST summarize the repo...' RFC 2119 keyword, line 111: '...hese identifiers SHOULD NOT be registe...' RFC 2119 keyword, line 120: '...d in section 2.3 SHOULD NOT be registe...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 17, 2001) is 8374 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IDNREQ' is defined on line 158, but no explicit reference was found in the text == Unused Reference: 'RACE' is defined on line 161, but no explicit reference was found in the text == Unused Reference: 'BRACE' is defined on line 164, but no explicit reference was found in the text == Unused Reference: 'LACE' is defined on line 167, but no explicit reference was found in the text == Unused Reference: 'VERSION' is defined on line 170, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-idn-requirements-03 -- Possible downref: Normative reference to a draft: ref. 'IDNREQ' == Outdated reference: A later version (-03) exists of draft-ietf-idn-race-02 -- Possible downref: Normative reference to a draft: ref. 'RACE' -- Possible downref: Normative reference to a draft: ref. 'BRACE' == Outdated reference: A later version (-01) exists of draft-ietf-idn-lace-00 -- Possible downref: Normative reference to a draft: ref. 'LACE' -- Possible downref: Normative reference to a draft: ref. 'VERSION' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Naomasa Maruyama 2 draft-ietf-idn-aceid-00.txt Yoshiro Yoneya 3 November 17, 2000 JPNIC 4 Expires May 17, 2001 6 Proposal for a determining process of ACE identifier 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 In IETF IDN WG, various kinds of ASCII Compatible Encodings, 31 hereafter abbreviated as "ACE", are discussed as methods for realizing 32 multilingual domain names (hereafter referred to as "MDN"). Each ACE 33 uses a prefix or a suffix as an identifier in order for MDNs to fit 34 within the existing ASCII domain name space. In other words, 35 acceptance of an ACE proposal as an Internet standard means that the 36 existing ASCII domain name space will be partitioned, in order to 37 accommodate MDN space. 39 This document describes possible trouble in the standardization 40 process of ACE, and proposes a solution for it. 42 1. Present situation and concern 44 At present, some specifications relating to MDN specify their own 45 ACE identifiers. In these drafts, multilingual domain names encoded 46 into ASCII character strings, with the ACE identifiers in their heads 47 or tails, are merely ASCII character strings. It is possible 48 accidently or intentionally to register a domain name that is not an 49 MDN but has the designated ACE identifier string. 51 If this kind of registration takes place, there is no warranty 52 that the domain name will be consistent with MDN semantics. 53 Furthermore, there is no warranty that the name, interpreted as an 54 MDN, will comply with the registration policies of the registry, when 55 the ACE identifier proposal is finally accepted as an Internet 56 standard. This might cause problems with name disputes and/or 57 revocations. 59 Therefore, the current situation letting independent ACE proposal 60 authors arbitrarily select an ACE identifier, hence permitting domain 61 name registrants registrer such names, may hinder deployment of MDN 62 technology. 64 2. Selecting ACE identifiers 66 In order to maintain a smooth standardization process for ACE, 67 this document proposes a strategy for selecting and reserving of ACE 68 identifiers and a method for assigning them. 70 2.1 The ACE identifier candidates and tentative suspension of 71 registering relevant domain names 73 All strings starting with a combination of two alpha-numericals, 74 followed by two hyphens, are defined to be ACE prefix identifier 75 candidates. All strings starting with one hyphen followed by three 76 alpha-numericals, and strings starting with two hyphens followed by 77 two alpha-numericals are defined as ACE suffix identifier candidates. 78 ACE prefix identifier candidates and ACE suffix identifier candidates 79 are collectively called ACE identifier candidates. 81 All the domain name registries recognized by ICANN SHOULD 82 tentatively suspend registration of domain names which have an ACE 83 prefix identifier candidate at the heads of one of the labels of the 84 domain name and those which have an ACE suffix identifier candidate at 85 the tail of one of the labels of the name. These domain names are 86 collectively called "relevant domain names". 88 This suspension should be continued until March 1, 2001 00:00:00 UTC. 90 2.2 Survey of relevant domain name registration 92 All registries recognized by ICANN SHOULD conduct a survey about 93 relevant domain names registered in their zone, and report, no later 94 than February 10, 2001 00:00:00 UTC, all of the ACE identifier 95 candidates which are used by relevant domain names. 97 2.3 Selection of ACE identifiers and permanent blocking of 98 relevant domain names 100 The IDN WG MUST summarize the reports and list ACE identifier 101 candidates that are not reported to be used in registered domain names 102 by February 17, 2001 00:00:00 UTC, and select ten to twenty ACE prefix 103 identifier candidates and ten to twenty ACE suffix identifier 104 candidates for ACE identifiers. Among these twenty to forty ACE 105 identifiers, one prefix identifier and one suffix identifier will be 106 used for experiments. Others will be used, one by one as ACE standard 107 evolves. 109 The list of ACE identifiers will be sent to IANA, and will be 110 maintained by IANA from February 24, 2001 00:00:00 UTC. Domain names 111 relevant to these identifiers SHOULD NOT be registered in any DNS 112 zone, except for registration of multilingual domain names compliant 113 to one of future IDN standards. This new restriction about the domain 114 name space will be notified to all ICANN recognized registries by IANA 115 immediately after it receives the list. 117 2.4 Blocking of registration for relevant domain names 119 Domain names relevant to ACE identifiers selected by the procedure 120 described in section 2.3 SHOULD NOT be registered in any zone of ICANN 121 recognized registries except for registration of multilingual domain 122 names compliant to one of future IDN standards. All ICANN recognized 123 registries SHOULD implement this restriction no later than March 1, 124 2001 00:00:00 UTC. 126 Registration for domain names relevant to ACE identifier 127 candidates, tentatively suspended by 2.1, but not relevant to ACE 128 identifiers selected by section 2.3 MAY be reopened from March 1, 2001 129 00:00:00 UTC. 131 3. Use of an ACE identifier in writing an ACE proposal 133 When writing an ACE proposal using an ACE identifier, the author 134 SHOULD either describe the ACE identifier as "to be decided" and left 135 to discretion of the IDN WG or other organ of IETF or ICANN, or use 136 either of the ACE identifiers for experiment defined in section 2.3, 137 with a unique version number added after or before the prefix or 138 suffix. 140 If a proposal is validated and published as an Internet Draft, the 141 IDN WG or other organ of IETF or ICANN MUST replace the "to be 142 decided" part with an experimental identifier with a unique version 143 number added after or before the prefix or the suffix. 145 4. Determination of ACE identifier 147 When an Internet Draft relating to ACE is accepted as an Internet 148 standard and becomes an RFC, IDN WG or other organ of IETF or ICANN 149 MUST replace the experimental ACE identifier, augmented by the version 150 number, with one of the ACE identifiers. 152 5. Security considerations 154 None in particular. 156 6. References 158 [IDNREQ] Z Wenzel, J Seng, "Requirements of Internationalized Domain 159 Names", draft-ietf-idn-requirements-03.txt, Jun 2000. 161 [RACE] P Hoffman, "RACE: Row-based ASCII Compatible Encoding for 162 IDN", draft-ietf-idn-race-02.txt, Oct 2000. 164 [BRACE] A Costello, "BRACE: Bi-mode Row-based ASCII-Compatible 165 Encoding for IDN", draft-ietf-idn-brace-00.txt, Sep 2000. 167 [LACE] P Hoffman, "LACE: Length-based ASCII Compatible Encoding for 168 IDN", draft-ietf-idn-lace-00.txt, Nov 2000. 170 [VERSION] M Blanchet, "Handling versions of internationalized domain 171 names protocols", draft-ietf-idn-version-00.txt, Nov 2000. 173 7. Acknowledgements 175 JPNIC IDN-TF members, 176 Dave Crocker. 178 8. Author's Address 180 Naomasa Maruyama 181 Japan Network Information Center 182 Fuundo Bldg 1F, 1-2 Kanda-ogawamachi 183 Chiyoda-ku Tokyo 101-0052, Japan 184 maruyama@nic.ad.jp 186 Yoshiro Yoneya 187 Japan Network Information Center 188 Fuundo Bldg 1F, 1-2 Kanda-ogawamachi 189 Chiyoda-ku Tokyo 101-0052, Japan 190 yone@nic.ad.jp