idnits 2.17.1 draft-hoffman-rfc3491bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 239 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-hoffman-rfc3491bis-01.txt P. Hoffman 2 April 14, 2004 IMC & VPNC 3 Expires in six months M. Blanchet 4 Viagenie 6 Nameprep: A Stringprep Profile for 7 Internationalized Domain Names (IDN) 9 Abstract 11 This document describes how to prepare internationalized domain name 12 (IDN) labels in order to increase the likelihood that name input and 13 name comparison work in ways that make sense for typical users 14 throughout the world. This profile of the stringprep protocol is 15 used as part of a suite of on-the-wire protocols for 16 internationalizing the Domain Name System (DNS). 18 1. Introduction 20 This document specifies processing rules that will allow users to 21 enter internationalized domain names (IDNs) into applications and 22 have the highest chance of getting the content of the strings 23 correct. It is a profile of stringprep [STRINGPREP]. These 24 processing rules are only intended for internationalized domain 25 names, not for arbitrary text. 27 This profile defines the following, as required by [STRINGPREP]. 29 - The intended applicability of the profile: internationalized 30 domain names processed by IDNA. 32 - The character repertoire that is the input and output to 33 stringprep: Unicode 3.2, specified in section 2. 35 - The mappings used: specified in section 3. 37 - The Unicode normalization used: specified in section 4. 39 - The characters that are prohibited as output: specified in section 40 5. 42 - Bidirectional character handling: specified in section 6. 44 1.1 Interaction of protocol parts 46 Nameprep is used by the IDNA [IDNA] protocol for preparing domain 47 names; it is not designed for any other purpose. It is explicitly 48 not designed for processing arbitrary free text and SHOULD NOT be 49 used for that purpose. Nameprep is a profile of Stringprep 50 [STRINGPREP]. Implementations of Nameprep MUST fully implement 51 Stringprep. Specifically, Nameprep mandates a set of steps that 52 must be executed in the same manner and the same order as they 53 are described in Stringprep. 54 1) Map 55 2) Normalize 56 3) Prohibit 57 4) Check bidi 59 Nameprep is used to process domain name labels, not domain names. 60 IDNA calls nameprep for each label in a domain name, not for the 61 whole domain name. 63 1.2 Terminology 65 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 66 in this document are to be interpreted as described in BCP 14, RFC 67 2119 [RFC2119]. 69 2. Character Repertoire 71 This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A. 73 3. Mapping 75 This profile specifies mapping using the following tables from 76 [STRINGPREP]: 78 Table B.1 79 Table B.2 81 4. Normalization 83 This profile specifies using Unicode normalization form KC, as 84 described in [STRINGPREP]. 86 5. Prohibited Output 88 This profile specifies prohibiting using the following tables from 89 [STRINGPREP]: 91 Table C.1.2 92 Table C.2.2 93 Table C.3 94 Table C.4 95 Table C.5 96 Table C.6 97 Table C.7 98 Table C.8 99 Table C.9 101 IMPORTANT NOTE: The IDNA protocol has additional prohibitions 102 that are checked outside of this profile. 104 6. Bidirectional characters 106 This profile specifies checking bidirectional strings as described in 107 [STRINGPREP] section 6. 109 7. Unassigned Code Points in Internationalized Domain Names 111 If the processing in [IDNA] specifies that a list of unassigned code 112 points be used, the system uses table A.1 from [STRINGPREP] as its 113 list of unassigned code points. 115 8. References 117 8.1 Normative References 119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 120 Requirement Levels", BCP 14, RFC 2119, March 1997. 122 [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of 123 Internationalized Strings ("stringprep")", 124 draft-hoffman-rfc3454bis. 126 [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, 127 "Internationalizing Domain Names in Applications 128 (IDNA)", draft-hoffman-rfc3490bis. 130 8.2 Informative references 132 [STD13] Mockapetris, P., "Domain names - concepts and 133 facilities", STD 13, RFC 1034, and "Domain names - 134 implementation and specification", STD 13, RFC 1035, 135 November 1987. 137 9. Security Considerations 139 The Unicode and ISO/IEC 10646 repertoires have many characters that 140 look similar. In many cases, users of security protocols might do 141 visual matching, such as when comparing the names of trusted third 142 parties. Because it is impossible to map similar-looking characters 143 without a great deal of context such as knowing the fonts used, 144 stringprep does nothing to map similar-looking characters together 145 nor to prohibit some characters because they look like others. 147 Security on the Internet partly relies on the DNS. Thus, any change 148 to the characteristics of the DNS can change the security of much of 149 the Internet. 151 Domain names are used by users to connect to Internet servers. The 152 security of the Internet would be compromised if a user entering a 153 single internationalized name could be connected to different servers 154 based on different interpretations of the internationalized domain 155 name. 157 Current applications might assume that the characters allowed in 158 domain names will always be the same as they are in [STD13]. This 159 document vastly increases the number of characters available in 160 domain names. Every program that uses "special" characters in 161 conjunction with domain names may be vulnerable to attack based on 162 the new characters allowed by this specification. 164 10. IANA Considerations 166 This is a profile of stringprep. It has been registered by the IANA 167 in the stringprep profile registry 168 (www.iana.org/assignments/stringprep-profiles). 170 Name of this profile: 171 Nameprep 173 RFC in which the profile is defined: 174 This document. 176 Indicator whether or not this is the newest version of the 177 profile: 178 This is the first version of Nameprep. 180 11. Acknowledgements 182 Many people from the IETF IDN Working Group and the Unicode Technical 183 Committee contributed ideas that went into this document. 185 The IDN Nameprep design team made many useful changes to the 186 document. That team and its advisors include: 188 Asmus Freytag 189 Cathy Wissink 190 Francois Yergeau 191 James Seng 192 Marc Blanchet 193 Mark Davis 194 Martin Duerst 195 Patrik Faltstrom 196 Paul Hoffman 198 Additional significant improvements were proposed by: 200 Jonathan Rosenne 201 Kent Karlsson 202 Scott Hollenbeck 203 Dave Crocker 204 Erik Nordmark 205 Matitiahu Allouche 207 12. Authors' Addresses 209 Paul Hoffman 210 Internet Mail Consortium and VPN Consortium 211 127 Segre Place 212 Santa Cruz, CA 95060 USA 214 EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org 216 Marc Blanchet 217 Viagenie inc. 218 2875 boul. Laurier, bur. 300 219 Ste-Foy, Quebec, Canada, G1V 2M2 221 EMail: Marc.Blanchet@viagenie.qc.ca 223 A. Changes from RFC 3491 225 This document is a revision of RFC 3491. None of the changes affect the 226 protocol described in RFC 3491; that is, all implementations of RFC 3491 227 will be identical with implementations of the specification in this 228 document. The items that have changed RFC 3491 document are: 230 - In section 1.1, a sentence was added to the end of the first paragraph 231 to make it clear that implementations must follow the same steps in 232 Stringprep, not just use the tables from Stringprep. The numbered list 233 added as well. 235 - In section 5, removed "This profile MUST be used with the IDNA 236 protocol" because it is expected that other protocols might use this 237 profile as well.