idnits 2.17.1 draft-ietf-idn-version-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: ---------------------------------------------------------------------------- ** 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. == 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 255 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 53 instances of too long lines in the document, the longest one being 5 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 108: '...ny idn processor MUST verify the versi...' RFC 2119 keyword, line 110: '...cted, processing MUST be stopped and r...' RFC 2119 keyword, line 112: '...diate processors MUST forward the idn ...' RFC 2119 keyword, line 136: '...ars, codepoint, properties MUST NOT be...' 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 (October 26, 2000) is 8582 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) == Missing Reference: 'IDNE' is mentioned on line 78, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'NAMEPREP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RACE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDNA' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Marc Blanchet 3 draft-ietf-idn-version-00.txt Viagenie 4 October 26, 2000 5 Expires in six 6 months 8 Handling versions of internationalized domain names protocols 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes some issues related to handling changes in the 35 codepoints and other features in the chars space of an internationalized 36 domain name as well as changes in the protocol that supports it (whatever 37 that be). It also presents some solutions to these issues. 39 1. Rationale 41 The nameprep draft [NAMEPREP] is defining prohibited chars, normalization 42 algorithms, etc.. The current concensus is to take the safer approach of 43 not accepting new chars if they are not listed, since the new characters 44 that can be included in the subsequent releases of the universal character 45 set can have an impact on the domain name (for example, a new variation of 46 the dot . will mostly be non-compatible and being excluded). 48 The Unicode and ISO-10646 versioning is designed not for the same purpose 49 as the idn work: for example, some chars or properties can be changed or 50 added to those repertoires that cannot be taken as is by the idn 51 protocol. In essence, the idn nameprep versions cannot be in sync with 52 unicode/iso versions. idn need its own versioning of the accepted character 53 set, which can or cannot be synchronized with the two others. While saying 54 that, there is no intent at all to define new codepoints inside this work 55 and any attempt to do that must be rejected. 57 Since internationalization and specifically internationalization of the 58 domain names is new, we don't really know if the chosen algorithm, protocol 59 and codepoitns will not have any problem in the future. We need to handle 60 versions of the protocol and to have a specific table for idn accepted chars. 62 2. Versioning of the protocol 64 Since the idn table of chars will be changed in the future, and possibly 65 the algorithms and the processing, then there is a need to handle these 66 situations in a controlled way. A version of the idn protocol should be 67 defined and included as part of the exchange between the parties so that 68 they can handle smoothly the new revisions. 70 2.1 Implementing the version in the protocol 71 Depending on which way the idn protocol will be, a different versioning 72 will have to be defined. We will discuss the current proposals and identify 73 where a versioning system can be handled. 75 2.1.1 Proposals based on extensions of the DNS protocol 76 Proposals based on extensions of the DNS protocol should include in the 77 bits the version number and a way to exchange version numbers between the 78 parties. [IDNE] already defined a version number as part of the use of 79 EDNS. Similar versioning should be defined in the other proposed protocols. 81 2.1.2 Proposals based on ACE and application 82 Since ACEs (for example [RACE]) in applications [IDNA] do not change the 83 DNS protocol but only encode the idn in a ascii compatible way, it looks 84 more difficult to include a version number in the ACE encoding, since it 85 will change the domain name. The proposal is to use a different 86 prefix/suffix for each version, by using one of the chars used in the 87 prefix as a version number, beginning with the lowest possible ascii char 88 available and increase the ascii codepoint of the char by 1 for each 89 version. For example, if the prefix is "ra--", then the first version of 90 idn will be "ra--", the second version will be "rb--", the third "rc--". 91 While this would be more elegant, one can handle versioning by having 92 different prefixes for each version, while chosing prefixes randomly (i.e. 93 1st version: rq--, 2nd version: wz--, ...). IANA should block all possible 94 prefixes so that no pre-registration is permitted. 96 2.2 Major and minor version numbers 98 A . version number is proposed (i.e. 1.0, 1.1, 2.0). A 99 minor revision is defined to be as new chars or small changes in the table 100 to be handled without any modification of algorithm. The idea here is to 101 enable easy upgrading of idn processors when only new chars will be 102 handled. In this case, the binary software do not have to be changed and 103 only the table containing the chars has to be changed to enable a new 104 version. A major revision means that the software has to be upgraded since 105 it implies new ways of handling idn which are not identified in the table. 107 2.3 Processing of the version numbers 108 Any idn processor MUST verify the version number before processing. When a 109 major version number is higher than what the processor currently handle is 110 detected, processing MUST be stopped and rejected. When a minor version 111 number is higher than what the processor currently handle, then any 112 intermediate processors MUST forward the idn but the end processor (i.e. 113 the dns server authoritative for that zone that is handling the request) 114 MUST stop and reject the request. Specific handling of rejecting the 115 request should be defined in the protocol document. 117 2.4 Version numbers 118 Version numbers of the idn protocol will be handled by IANA. A 119 IESG-reviewed document should be used as the basis for IANA to define a new 120 protocol version number. 122 3. Idn table 123 Since the unicode consortium and ISO will issue new versions not at the 124 same time as the idn protocol versioning, the IETF need to have its own 125 registered table of accepted idn chars. This will also enable specific data 126 only useful for idn. The intent is not to duplicate the unicode/iso effort, 127 it is to support the specific needs of the idn group. For example, it is 128 possible that specific chars will have a different behavior than the normal 129 Unicode way: the special casing for final or non-final letters in the 130 Unicode SpecialCasing.txt file can be merged (ie not totally identical to 131 the unicode processing) to only one casing since final and non-final 132 letters have less meaning in a domain name. Simpler processing for idn is 133 also useful: for example, the Lud property is probably not useful in the 134 idn context and can be considered equivalent to Lu. Combining those 135 properties together means much simple table and simpler processing and less 136 errors in implementations. Added chars, codepoint, properties MUST NOT be 137 done in this file, but must be done within the Unicode/ISO process. 139 This document proposes a table contained in an ascii file handled by IANA 140 and available in the IANA public directory. The source of the table will be 141 the Unicode table, with a similar format, but a simpler, and perhaps 142 different, content based on the needs of the idn protocol. Proposed 143 filename is: idntab.txt. 145 This file format will also help implementors to have the same input 146 description and exhaustive list of which chars and processing to handle 147 idn. This is easier for implementors to have a complete list of accepted 148 chars instead a list of non-accepted chars. The hope is also to help 149 decrease the different behaviors between the different implementations. 150 This table can be considered as an implementation of [NAMEPREP]. 152 3.1 File format 154 The file is divided in two parts. The first part contains variables. The 155 second part contains all the chars accepted for idn. The two parts are 156 separated by a empty line. 158 The format of the first part is: 159 tag=value 161 Currently, only the version tag is defined. The "version" tag defines the 162 highest idn version number that can be found in this table. The intent is 163 to have only one file that is kept current but where the beginning of the 164 file can be used by parsers to identify the latest version of the file. 166 The first idntab.txt file will define version=1.0: 167 version=1.0 169 The format of the second part is: 170 one codepoint per line 171 lines separated by CR/LF 172 each field in the line separated by ";" 174 The fields are (in order, from left to right): 175 1. codepoint in hexadecimal (as in unicode table): HHHH 176 2. first version of idn table that this char is supported 178 It is possible that new fields will be added in the future. Parsers should 179 ignore the fields that they don't understand. 181 Spaces (ascii 0x20) are ignored. Comments are identified by "#". All text 182 following the comment char up to the end of line is ignored. Any codepoint 183 not in the table is considered prohibited. Codepoints that are prohibited 184 may be included in the table inside commented lines in order to help a 185 reader to see explicitly which ones are prohibited. 187 Example of the file idntab10.txt: 188 version=1.0 189 190 0041;1.0; 192 4. Security Considerations 194 Changing the way a software react about domain names is clearly something 195 that have security impacts. While the actual table doesn't present any 196 security threat by itself, if there is someways by a intruder to reload a 197 new table into a idn processor software without the knowledge of the user, 198 then it can completly disables name resolution or have other possible 199 threats. In conclusion, care must be taken by software developers on how 200 to manage the insertion of a new idn table in a idn processor software. 202 5. IANA Considerations 203 This document describes versions of the idn file called idntab.txt. The 204 file should be kept in the IANA public directory for references purposes. 205 New versions of the file should be made available after IESG review of a 206 document. Old revisions of the file (idntab-xy.txt) should be kept for 207 documentation purposes. 209 6. Acknowledgements 210 The author would like to acknowledge the comments and idea of the 211 following people: Fran�ois Yergeau and Paul Hoffman. 213 7. Author 215 Marc Blanchet 216 Viagenie 217 2875 boul. Laurier, bur. 300 218 Ste-Foy, Quebec, Canada 219 G1V 2M2 220 Marc.Blanchet@viagenie.qc.ca 221 tel: 418-656-9254 223 8. References 225 [NAMEPREP] Preparation of Internationalized Host Names, Paul Hoffman, Marc 226 Blanchet. Work in progress. 228 [RACE] RACE: Row-based ASCII Compatible Encoding for IDN, Paul Hoffman. 229 Work in progress. 231 [IDNA] Internationalizing Host Names In Applications (IDNA), Paul Hoffman, 232 Patrick Falstrom. Work in progress. 234 Marc Blanchet 235 Viag�nie inc. 236 tel: 418-656-9254 237 http://www.viagenie.qc.ca 239 ---------------------------------------------------------- 240 Normos (http://www.normos.org): Internet standards portal: 241 IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.