idnits 2.17.00 (12 Aug 2021) /tmp/idnits60489/draft-ietf-idnabis-mappings-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 10, 2009) is 4666 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: 'RFC3490' is defined on line 161, but no explicit reference was found in the text == Unused Reference: 'RFC3491' is defined on line 165, but no explicit reference was found in the text == Outdated reference: draft-ietf-idnabis-protocol has been published as RFC 5891 ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode51' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDNABIS P. Resnick 3 Internet-Draft Qualcomm Incorporated 4 Intended status: Standards Track P. Hoffman 5 Expires: February 11, 2010 VPN Consortium 6 August 10, 2009 8 Mapping Characters in IDNA 9 draft-ietf-idnabis-mappings-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on February 11, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 In the original version of the Internationalized Domain Names in 58 Applications (IDNA) protocol, any Unicode code points taken from user 59 input were mapped into a set of Unicode code points that "make 60 sense", which were then encoded and passed to the domain name system 61 (DNS). The current version of IDNA presumes that the input to the 62 protocol comes from a set of "permitted" code points, which it then 63 encodes and passes to the DNS, but does not specify what to do with 64 the result of user input. This document describes the actions taken 65 by an implementation between user input and passing permitted code 66 points to the new IDNA protocol. 68 1. Introduction 70 This document describes the operations that can be applied to user 71 input in order to get it into a form acceptable by the 72 Internationalized Domain Names in Applications (IDNA) protocol 73 [I-D.ietf-idnabis-protocol]. The document describes a general 74 implementation procedure for mapping in section 2. 76 It should be noted that this document does not specify the behavior 77 of a protocol that appears "on the wire". It describes an operation 78 that is to be applied to user input in order to prepare that user 79 input for use in an "on the network" protocol. As unusual as this 80 may be for an IETF protocol document, it is a necessary operation to 81 maintain interoperability. 83 2. The General Procedure 85 This section defines a general algorithm that applications ought to 86 implement in order to produce Unicode code points that will be valid 87 under the IDNA protocol. An application might implement the full 88 mapping as described below, or can choose a different mapping. In 89 fact, an application might want to implement a full mapping that is 90 substantially compatible with the original IDNA protocol instead of 91 the algorithm given here. 93 The general algorithm that an application (or the input method 94 provided by an operating system) ought to use is relatively 95 straightforward: 97 1. Upper case characters are mapped to their lower case equivalents 98 by using the algorithm for mapping Unicode characters. 100 2. Full-width and half-width characters (those defined with 101 Decomposition Types and ) are mapped to their 102 decomposition mappings as shown in the Unicode character 103 database. 105 3. All characters are mapped using Unicode Normalization Form C 106 (NFC). 108 Definitions for the rules in this algorithm can be found in 109 [Unicode51]. Specifically: 111 o Unicode Normalization Form C can be found in Annex #15 of 112 [Unicode51]. 114 o In order to map upper case characters to their lower case 115 equivalents (defined in section 3.13 of [Unicode51]), first map 116 characters to the "Lowercase_Mapping" property (the "" 117 entry in the second column) in 118 , if any. 119 Then, map characters to the "Simple_Lowercase_Mapping" property 120 (the fourteenth column) in 121 , if any. 123 o In order to map full-width and half-width characters to their 124 decomposition mappings, map any character whose 125 "Decomposition_Type" (contained in the first part of of the sixth 126 column) in 127 is either "" or "" to the "Decomposition_Mapping" of 128 that character (contained in the second part of the sixth column) 129 in . 131 o The web page has 132 useful descriptions of the contents of these files. 134 If this mappings in this document are applied to versions of Unicode 135 later than Unicode 5.1, the later versions of the Unicode Standard 136 should be consulted. 138 These are a minimal set of mappings that an application should 139 strongly consider doing. Of course, there are many others that might 140 be done. 142 3. IANA Considerations 144 This memo includes no request to IANA. 146 4. Security Considerations 148 This document suggests creating mappings that might cause confusion 149 for some users while alleviating confusion in other users. Such 150 confusion is not covered in any depth in this document (nor in the 151 other IDNA-related documents). 153 5. Normative References 155 [I-D.ietf-idnabis-protocol] 156 Klensin, J., "Internationalized Domain Names in 157 Applications (IDNA): Protocol", 158 draft-ietf-idnabis-protocol-14 (work in progress), 159 August 2009. 161 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 162 "Internationalizing Domain Names in Applications (IDNA)", 163 RFC 3490, March 2003. 165 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 166 Profile for Internationalized Domain Names (IDN)", 167 RFC 3491, March 2003. 169 [Unicode51] 170 The Unicode Consortium, "The Unicode Standard, Version 171 5.1.0", 2008. 173 defined by: The Unicode Standard, Version 5.0, Boston, MA, 174 Addison-Wesley, 2007, ISBN 0-321-48091-0, as amended by 175 Unicode 5.1.0 176 (). 178 Authors' Addresses 180 Peter W. Resnick 181 Qualcomm Incorporated 182 5775 Morehouse Drive 183 San Diego, CA 92121-1714 184 US 186 Phone: +1 858 651 4478 187 Email: presnick@qualcomm.com 188 URI: http://www.qualcomm.com/~presnick/ 190 Paul Hoffman 191 VPN Consortium 192 127 Segre Place 193 Santa Cruz, CA 95060 194 US 196 Phone: 1-831-426-9827 197 Email: paul.hoffman@vpnc.org