idnits 2.17.1 draft-ietf-idn-aceid-02.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 219 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 6 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 80: '... registries recognized by ICANN SHOULD...' RFC 2119 keyword, line 92: '...ognized by ICANN SHOULD conduct a surv...' RFC 2119 keyword, line 100: '...an of IETF or ICANN MUST summarize the...' 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 (Dec 19, 2001) is 8165 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 171, but no explicit reference was found in the text == Unused Reference: 'RACE' is defined on line 174, but no explicit reference was found in the text == Unused Reference: 'BRACE' is defined on line 177, but no explicit reference was found in the text == Unused Reference: 'LACE' is defined on line 180, but no explicit reference was found in the text == Unused Reference: 'VERSION' is defined on line 183, 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-02.txt Yoshiro Yoneya 3 Jun 19, 2000 JPNIC 4 Expires Dec 19, 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 two hyphens followed by two 76 alpha-numericals are defined as ACE suffix identifier candidates. ACE 77 prefix identifier candidates and ACE suffix identifier candidates are 78 collectively called ACE identifier candidates. 80 All the domain name registries recognized by ICANN SHOULD 81 tentatively suspend registration of domain names which have an ACE 82 prefix identifier candidate at the head of at least one label of the 83 domain name and those which have an ACE suffix identifier candidate at 84 the tail of at least one label of the name. These domain names are 85 collectively called "relevant domain names". 87 This suspension should be continued until September 1, 2001 88 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 August 11, 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 or other organ of IETF or ICANN MUST summarize the 101 reports and list ACE identifier candidates that are not reported to be 102 used in registered domain names by August 18, 2001 00:00:00 UTC, and 103 select ten to twenty ACE prefix identifier candidates and ten to 104 twenty ACE suffix identifier candidates for ACE identifiers. Among 105 these twenty to forty ACE identifiers, one prefix identifier and one 106 suffix identifier will be used for experiments. Others will be used, 107 one by one as ACE standard evolves. 109 The list of ACE identifiers will be sent to IANA, and will be 110 maintained by IANA from August 25, 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 September 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 September 1, 129 2001 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. Changes from the previous version 158 We excluded suffixes of one hyphen followed by three alpha- 159 numericals from the candidates. This is because we found that, as of 160 Nov. 29, 2000, there were 23,921 domain names registered in the .JP 161 space relevant to these suffixes. This was more than 10% of 227,852 162 total registrations in the JPNIC database at the moment, and hence we 163 felt these suffixes are not good candidates. 165 In addition to this and some minor linguistic corrections, we 166 changed "The IDN WG" in section 2.3 to "The IDN WG or other organ of 167 IETF or ICANN". 169 7. References 171 [IDNREQ] Z Wenzel, J Seng, "Requirements of Internationalized Domain 172 Names", draft-ietf-idn-requirements-03.txt, Jun 2000. 174 [RACE] P Hoffman, "RACE: Row-based ASCII Compatible Encoding for 175 IDN", draft-ietf-idn-race-02.txt, Oct 2000. 177 [BRACE] A Costello, "BRACE: Bi-mode Row-based ASCII-Compatible 178 Encoding for IDN", draft-ietf-idn-brace-00.txt, Sep 2000. 180 [LACE] P Hoffman, "LACE: Length-based ASCII Compatible Encoding for 181 IDN", draft-ietf-idn-lace-00.txt, Nov 2000. 183 [VERSION] M Blanchet, "Handling versions of internationalized domain 184 names protocols", draft-ietf-idn-version-00.txt, Nov 2000. 186 8. Acknowledgements 188 We would like to express our hearty thanks to members of JPNIC IDN 189 Task Force for valuable discussions about this issue. We also would 190 like to express our appreciation to Mr. Dave Crocker for checking and 191 correcting the preliminary version of this draft. 193 9. Author's Address 195 Naomasa Maruyama 196 Japan Network Information Center 197 Fuundo Bldg 1F, 1-2 Kanda-ogawamachi 198 Chiyoda-ku Tokyo 101-0052, Japan 199 maruyama@nic.ad.jp 201 Yoshiro Yoneya 202 Japan Network Information Center 203 Fuundo Bldg 1F, 1-2 Kanda-ogawamachi 204 Chiyoda-ku Tokyo 101-0052, Japan 205 yone@nic.ad.jp