idnits 2.17.1 draft-klensin-idna-registry-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5892, but the abstract doesn't seem to directly say this. It does mention RFC5892 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5892, updated by this document, for RFC5378 checks: 2008-04-26) -- 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 (June 8, 2011) is 4698 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft June 8, 2011 4 Updates: 5892 (if approved) 5 Intended status: Standards Track 6 Expires: December 10, 2011 8 Clarified IANA Considerations for IDNA 9 draft-klensin-idna-registry-00.txt 11 Abstract 13 As part of the IDNA package, the IANA Considerations Section of RFC 14 5892 specified an "IDNA Derived Properties" registry. Experience 15 with that specification demonstrated it to be insufficiently clear on 16 several details. This document respecifies that registry to 17 eliminate any confusion. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 10, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Reasons for this Specification . . . . . . . . . . . . . . 3 55 2. Explanation of the Updating Model . . . . . . . . . . . . . . . 3 56 3. Specific Updates to RFC 5892 . . . . . . . . . . . . . . . . . 4 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 1.1. Reasons for this Specification 69 As part of the IDNA package [RFC5890], the IANA Considerations 70 Section of RFC 5892 [RFC5892] specified an "IDNA Derived Properties" 71 registry. Experience with that specification demonstrated it to be 72 insufficiently clear on several details. This document respecifies 73 that registry to eliminate any confusion. In particular, 74 clarifications are required for the following: 76 Preservation of tables 77 The registry actually consists of one table per Unicode version 78 starting with the Unicode 5.2 table that was included in RFC 5892. 80 Identification of tables 81 Each table in the registry will be identified with a reference to 82 the particular Unicode version from which it was generated and the 83 date on which it was installed. 85 Timing and Mechanism for Generating Tables 86 The text in RFC 5982 is not clear about who is responsible for 87 generating tables and when new tables are to be installed and this 88 requires clarification. 90 2. Explanation of the Updating Model 92 [[RFC Editor, please remove this section -- Note in Draft only]] 94 As of the time of posting the first draft of this document, there had 95 been no real discussion in the community of the mechanisms and timing 96 for getting new versions posted. The suggestion made below is very 97 tentative and intended to encourage discussion. It tries to preserve 98 the intent and discussions leading up to RFC 5892 to the extent 99 possible by putting the burden of deciding when new table versions 100 are appropriate on the expert reviewer. Itj also makes IANA 101 responsible for the actual work of producing and installing new 102 tables, but identifies mechanisms by which they can get help with 103 tables and with identifying the existence of new versions of Unicode 104 as needed. 106 The procedure outlined below delays any posting of a table by IANA 107 until either (i) the expert reviews signs off that no changes to RFC 108 5892 rules are needed or (ii) IESG, after being notified by the 109 expert reviewer that there is a problem, figures out how to handle 110 things in terms of documentation and community consensus, and 111 approves the result. If the community would prefer posting of a 112 table for comparison or checking purposes as soon as possible after a 113 new Unicode version is completed, it would be possible to devise a 114 model for "Preliminary" (just after Unicode gets through) and "Final" 115 (after IETF is sure it is through) versions of a table with 116 procedures for getting from one to the other.. 118 3. Specific Updates to RFC 5892 120 The following subsections are added to the specification of RFC 5892 121 Section 5.1 "IDNA-Derived Property Value Registry". The numbers in 122 parentheses are the subsection numbers the paragraphs would have if 123 actually inserted in RFC 8582. 125 (5.1.1) The registry consists of a set of tables, one table per 126 version of Unicode starting with Unicode 5.2 and continuing 127 with each new version of Unicode as specified below. 129 (5.1.2) Each table in the registry shall be identified with the 130 Unicode version, a reference to the specification of that 131 version, and the date the table was last updated. 133 (5.1.3) As soon as feasible after a new version of Unicode is 134 finalized and published, IANA or the expert reviewer (as 135 they mutually agree) will generate a new version of the 136 table. The expert reviewer will then conduct a review. If 137 issues are found, they are brought to IESG attention as 138 discussed in RFC 5892. If not, the expert reviewer will 139 advise IANA to install the new table version in the 140 registry, identifying it as described above. 142 Members of the community are encouraged to call new 143 versions of Unicode to the attention of IANA and the expert 144 reviewer. IANA is encouraged to call on the expert 145 reviewer or others for assistance in compiling and 146 verifying Preliminary tables as needed. 148 4. Security Considerations 150 This document clarifies the management, content, and organization of 151 an IANA registry. It does not introduce any security issues not 152 already covered in RFC 5890 and 5892. 154 5. IANA Considerations 156 This document is a specification of the requirements for an IANA 157 registry. Details appear in Section 3. 159 6. Acknowledgments 161 This specification was motivated by issues with the clarity of the 162 RFC 5892 "IANA Considerations" section identified by Roni Even, Paul 163 Hoffman, Russ Housley, and others. 165 7. References 167 7.1. Normative References 169 [RFC5892] Faltstrom, P., "The Unicode Code Points and 170 Internationalized Domain Names for Applications (IDNA)", 171 RFC 5892, August 2010. 173 7.2. Informative References 175 [RFC5890] Klensin, J., "Internationalized Domain Names for 176 Applications (IDNA): Definitions and Document Framework", 177 RFC 5890, August 2010. 179 Author's Address 181 John C Klensin 182 1770 Massachusetts Ave, #322 183 Cambridge, MA 02140 184 USA 186 Phone: +1 617 491 5735 187 Email: john-ietf@jck.com