idnits 2.17.00 (12 Aug 2021) /tmp/idnits64307/draft-ietf-dnsext-insensitive-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 356. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 348), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document updates RFC1034, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC1035, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 164 has weird spacing: '... and a\000...' -- 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 (July 2005) is 6147 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: '2606' is mentioned on line 95, but not defined == Missing Reference: 'RFC 1035' is mentioned on line 197, but not defined == Missing Reference: 'RFC 2535' is mentioned on line 494, but not defined ** Obsolete undefined reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'RFC 4034' is mentioned on line 495, but not defined == Unused Reference: 'RFC 1034' is defined on line 363, but no explicit reference was found in the text == Unused Reference: '1035' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC 2136' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC 3007' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'ISO 8859-1' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'ISO 8859-2' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'RFC 2606' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'RFC 2673' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'RFC 3092' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC 3490' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC 3492' is defined on line 429, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Duplicate reference: RFC1034, mentioned in '1035', was also mentioned in 'RFC 1034'. == Outdated reference: draft-ietf-dnsext-unknown-rrs has been published as RFC 3597 -- Obsolete informational reference (is this intentional?): RFC 2929 (Obsoleted by RFC 5395) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2673 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3491 (Obsoleted by RFC 5891) Summary: 10 errors (**), 0 flaws (~~), 21 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Updates RFC 1034, 1035 Motorola Laboratories 3 Expires January 2006 July 2005 5 Domain Name System (DNS) Case Insensitivity Clarification 6 ------ ---- ------ ----- ---- ------------- ------------- 7 9 Donald E. Eastlake 3rd 11 Status of This Document 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Distribution of this document is unlimited. Comments should be sent 19 to the DNSEXT working group at namedroppers@ops.ietf.org. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than a "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 Domain Name System (DNS) names are "case insensitive". This document 44 explains exactly what that means and provides a clear specification 45 of the rules. This clarification updates RFCs 1034 and 1035. 47 Acknowledgements 49 The contributions to this document of Rob Austein, Olafur 50 Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, 51 Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman 52 are gratefully acknowledged. 54 Table of Contents 56 Status of This Document....................................1 57 Copyright Notice...........................................1 58 Abstract...................................................1 60 Acknowledgements...........................................2 61 Table of Contents..........................................2 63 1. Introduction............................................3 64 2. Case Insensitivity of DNS Labels........................3 65 2.1 Escaping Unusual DNS Label Octets......................3 66 2.2 Example Labels with Escapes............................4 67 3. Name Lookup, Label Types, and CLASS.....................4 68 3.1 Original DNS Label Types...............................5 69 3.2 Extended Label Type Case Insensitivity Considerations..5 70 3.3 CLASS Case Insensitivity Considerations................5 71 4. Case on Input and Output................................6 72 4.1 DNS Output Case Preservation...........................6 73 4.2 DNS Input Case Preservation............................6 74 5. Internationalized Domain Names..........................7 75 6. Security Considerations.................................8 77 Copyright and Disclaimer...................................9 78 Normative References.......................................9 79 Informative References....................................10 81 Changes Between Draft Version.............................11 82 -02 to -03 Changes........................................11 83 -03 to -04 Changes........................................11 84 -04 to -05 Changes........................................11 85 -05 to -06 Changes........................................12 87 Author's Address..........................................13 88 Expiration and File Name..................................13 90 1. Introduction 92 The Domain Name System (DNS) is the global hierarchical replicated 93 distributed database system for Internet addressing, mail proxy, and 94 other information. Each node in the DNS tree has a name consisting of 95 zero or more labels [STD 13][RFC 1591, 2606] that are treated in a 96 case insensitive fashion. This document clarifies the meaning of 97 "case insensitive" for the DNS. This clarification updates RFCs 1034 98 and 1035 [STD 13]. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC 2119]. 104 2. Case Insensitivity of DNS Labels 106 DNS was specified in the era of [ASCII]. DNS names were expected to 107 look like most host names or Internet email address right halves (the 108 part after the at-sign, "@") or be numeric as in the in-addr.arpa 109 part of the DNS name space. For example, 111 foo.example.net. 112 aol.com. 113 www.gnu.ai.mit.edu. 114 or 69.2.0.192.in-addr.arpa. 116 Case varied alternatives to the above would be DNS names like 118 Foo.ExamplE.net. 119 AOL.COM. 120 WWW.gnu.AI.mit.EDU. 121 or 69.2.0.192.in-ADDR.ARPA. 123 However, the individual octets of which DNS names consist are not 124 limited to valid ASCII character codes. They are 8-bit bytes and all 125 values are allowed. Many applications, however, interpret them as 126 ASCII characters. 128 2.1 Escaping Unusual DNS Label Octets 130 In Master Files [STD 13] and other human readable and writable ASCII 131 contexts, an escape is needed for the byte value for period (0x2E, 132 ".") and all octet values outside of the inclusive range of 0x21 133 ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in 134 the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. 136 One typographic convention for octets that do not correspond to an 137 ASCII printing graphic is to use a back-slash followed by the value 138 of the octet as an unsigned integer represented by exactly three 139 decimal digits. 141 The same convention can be used for printing ASCII characters so that 142 they will be treated as a normal label character. This includes the 143 back-slash character used in this convention itself which can be 144 expressed as \092 or \\ and the special label separator period (".") 145 which can be expressed as and \046 or \. respectively. It is 146 advisable to avoid using a backslash to quote an immediately 147 following non-printing ASCII character code to avoid implementation 148 difficulties. 150 A back-slash followed by only one or two decimal digits is undefined. 151 A back-slash followed by four decimal digits produces two octets, the 152 first octet having the value of the first three digits considered as 153 a decimal number and the second octet being the character code for 154 the fourth decimal digit. 156 2.2 Example Labels with Escapes 158 The first example below shows embedded spaces and a period (".") 159 within a label. The second one show a 5-octet label where the second 160 octet has all bits zero, the third is a backslash, and the fourth 161 octet has all bits one. 163 Donald\032E\.\032Eastlake\0323rd.example. 164 and a\000\\\255z.example. 166 3. Name Lookup, Label Types, and CLASS 168 The original DNS design decision was made that comparisons on name 169 lookup for DNS queries should be case insensitive [STD 13]. That is 170 to say, a lookup string octet with a value in the inclusive range of 171 0x41 to 0x5A, the upper case ASCII letters, MUST match the identical 172 value and also match the corresponding value in the inclusive range 173 0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet 174 with a lower case ASCII letter value MUST similarly match the 175 identical value and also match the corresponding value in the upper 176 case ASCII letter range. 178 (Historical Note: the terms "upper case" and "lower case" were 179 invented after movable type. The terms originally referred to the 180 two font trays for storing, in partitioned areas, the different 181 physical type elements. Before movable type, the nearest equivalent 182 terms were "majuscule" and "minuscule".) 184 One way to implement this rule would be, when comparing octets, to 185 subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A 186 before the comparison. Such an operation is commonly known as "case 187 folding" but implementation via case folding is not required. Note 188 that the DNS case insensitivity does NOT correspond to the case 189 folding specified in [iso-8859-1] or [iso-8859-2]. For example, the 190 octets 0xDD (\221) and 0xFD (\253) do NOT match although in other 191 contexts, where they are interpreted as the upper and lower case 192 version of "Y" with an acute accent, they might. 194 3.1 Original DNS Label Types 196 DNS labels in wire-encoded names have a type associated with them. 197 The original DNS standard [RFC 1035] had only two types. ASCII 198 labels, with a length of from zero to 63 octets, and indirect (or 199 compression) labels which consist of an offset pointer to a name 200 location elsewhere in the wire encoding on a DNS message. (The ASCII 201 label of length zero is reserved for use as the name of the root node 202 of the name tree.) ASCII labels follow the ASCII case conventions 203 described herein and, as stated above, can actually contain arbitrary 204 byte values. Indirect labels are, in effect, replaced by the name to 205 which they point which is then treated with the case insensitivity 206 rules in this document. 208 3.2 Extended Label Type Case Insensitivity Considerations 210 DNS was extended by [RFC 2671] to have additional label type numbers 211 available. (The only such type defined so far is the BINARY type [RFC 212 2673] which is now Experimental [RFC 3363].) 214 The ASCII case insensitivity conventions only apply to ASCII labels, 215 that is to say, label type 0x0, whether appearing directly or invoked 216 by indirect labels. 218 3.3 CLASS Case Insensitivity Considerations 220 As described in [STD 13] and [RFC 2929], DNS has an additional axis 221 for data location called CLASS. The only CLASS in global use at this 222 time is the "IN" or Internet CLASS. 224 The handling of DNS label case is not CLASS dependent. With the 225 original design of DNS, it was intended that a recursive DNS resolver 226 be able to handle new CLASSes that were unknown at the time of its 227 implementation. This requires uniform handling of label case 228 insensitivity. Should it become desireable, for example, to allocate 229 a CLASS with "case sensitive ASCII labels" for example, it would be 230 necessary to allocate a new label type for these labels. 232 4. Case on Input and Output 234 While ASCII label comparisons are case insensitive, [STD 13] says 235 case MUST be preserved on output, and preserved when convenient on 236 input. However, this means less than it would appear since the 237 preservation of case on output is NOT required when output is 238 optimized by the use of indirect labels, as explained below. 240 4.1 DNS Output Case Preservation 242 [STD 13] views the DNS namespace as a node tree. ASCII output is as 243 if a name was marshaled by taking the label on the node whose name is 244 to be output, converting it to a typographically encoded ASCII 245 string, walking up the tree outputting each label encountered, and 246 preceding all labels but the first with a period ("."). Wire output 247 follows the same sequence but each label is wire encoded and no 248 periods inserted. No "case conversion" or "case folding" is done 249 during such output operations, thus "preserving" case. However, to 250 optimize output, indirect labels may be used to point to names 251 elsewhere in the DNS answer. In determining whether the name to be 252 pointed to, for example the QNAME, is the "same" as the remainder of 253 the name being optimized, the case insensitive comparison specified 254 above is done. Thus such optimization may easily destroy the output 255 preservation of case. This type of optimization is commonly called 256 "name compression". 258 4.2 DNS Input Case Preservation 260 Originally, DNS data came from an ASCII Master File as defined in 261 [STD 13] or a zone transfer. DNS Dynamic update and incremental zone 262 transfers [RFC 1995] have been added as a source of DNS data [RFC 263 2136, 3007]. When a node in the DNS name tree is created by any of 264 such inputs, no case conversion is done. Thus the case of ASCII 265 labels is preserved if they are for nodes being created. However, 266 when a name label is input for a node that already exist in DNS data 267 being held, the situation is more complex. Implementations are free 268 to retain the case first loaded for such a label or allow new input 269 to override the old case or even maintain separate copies preserving 270 the input case. 272 For example, if data with owner name "foo.bar.example" is loaded and 273 then later data with owner name "xyz.BAR.example" is input, the name 274 of the label on the "bar.example" node, i.e. "bar", might or might 275 not be changed to "BAR" in the DNS stored data or the actual input 276 case could be preserved. Thus later retrieval of data stored under 277 "xyz.bar.example" in this case can return all data with 278 "xyz.BAR.example" or all data with "xyz.bar.example" or even, when 279 more than one RR is being returned, a mixture of these two cases. 280 This last case is unlikely because optimization of answer length 281 through indirect labels tends to cause only copy of the name tail 282 ("bar.example" or "BAR.example") to be used for all returned RRs. 283 Note that none of this has any effect on the number of completeness 284 of the RR set returned, only on the case of the names in the RR set 285 returned. 287 The same considerations apply when inputting multiple data records 288 with owner names differing only in case. For example, if an "A" 289 record is the first resourced record stored under owner name 290 "xyz.BAR.example" and then a second "A" record is stored under 291 "XYZ.BAR.example", the second MAY be stored with the first (lower 292 case initial label) name or the second MAY override the first so that 293 only an upper case initial label is retained or both capitalizations 294 MAY be kept in the DNS stored data. In any case, a retrieval with 295 either capitalization will retrieve all RRs with either 296 capitalization. 298 Note that the order of insertion into a server database of the DNS 299 name tree nodes that appear in a Master File is not defined so that 300 the results of inconsistent capitalization in a Master File are 301 unpredictable output capitalization. 303 5. Internationalized Domain Names 305 A scheme has been adopted for "internationalized domain names" and 306 "internationalized labels" as described in [RFC 3490, 3454, 3491, and 307 3492]. It makes most of [UNICODE] available through a separate 308 application level transformation from internationalized domain name 309 to DNS domain name and from DNS domain name to internationalized 310 domain name. Any case insensitivity that internationalized domain 311 names and labels have varies depending on the script and is handled 312 entirely as part of the transformation described in [RFC 3454] and 313 [RFC 3491] which should be seen for further details. This is not a 314 part of the DNS as standardized in STD 13. 316 6. Security Considerations 318 The equivalence of certain DNS label types with case differences, as 319 clarified in this document, can lead to security problems. For 320 example, a user could be confused by believing two domain names 321 differing only in case were actually different names. 323 Furthermore, a domain name may be used in contexts other than the 324 DNS. It could be used as a case sensitive index into some data base 325 or file system. Or it could be interpreted as binary data by some 326 integrity or authentication code system. These problems can usually 327 be handled by using a standardized or "canonical" form of the DNS 328 ASCII type labels, that is, always mapping the ASCII letter value 329 octets in ASCII labels to some specific pre-chosen case, either upper 330 case or lower case. An example of a canonical form for domain names 331 (and also a canonical ordering for them) appears in Section 6 of [RFC 332 4034]. See also [RFC 3597]. 334 Finally, a non-DNS name may be stored into DNS with the false 335 expectation that case will always be preserved. For example, although 336 this would be quite rare, on a system with case sensitive email 337 address local parts, an attempt to store two "RP" records that 338 differed only in case would probably produce unexpected results that 339 might have security implications. That is because the entire email 340 address, including the possibly case sensitive local or left hand 341 part, is encoded into a DNS name in a readable fashion where the case 342 of some letters might be changed on output as described above. 344 Copyright and Disclaimer 346 Copyright (C) The Internet Society (2005). This document is subject 347 to the rights, licenses and restrictions contained in BCP 78, and 348 except as set forth therein, the authors retain all their rights. 350 This document and the information contained herein are provided on an 351 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 352 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 353 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 354 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 355 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 356 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 358 Normative References 360 [ASCII] - ANSI, "USA Standard Code for Information Interchange", 361 X3.4, American National Standards Institute: New York, 1968. 363 [RFC 1034, 1035] - See [STD 13]. 365 [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August 366 1996. 368 [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate 369 Requirement Levels", March 1997. 371 [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, 372 "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. 374 [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic 375 Update", November 2000. 377 [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", 378 draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. 380 [RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S. 381 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, 382 March 2005. 384 [STD 13] 385 - P. Mockapetris, "Domain names - concepts and facilities", RFC 386 1034, November 1987. 387 - P. Mockapetris, "Domain names - implementation and 388 specification", RFC 1035, November 1987. 390 Informative References 392 [ISO 8859-1] - International Standards Organization, Standard for 393 Character Encodings, Latin-1. 395 [ISO 8859-2] - International Standards Organization, Standard for 396 Character Encodings, Latin-2. 398 [RFC 1591] - J. Postel, "Domain Name System Structure and 399 Delegation", March 1994. 401 [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", 402 June 1999. 404 [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain 405 Name System (DNS) IANA Considerations", September 2000. 407 [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August 408 1999. 410 [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", 411 August 1999. 413 [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of 414 Foo", 1 April 2001. 416 [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 417 Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in 418 the Domain Name System (DNS)", RFC 3363, August 2002. 420 [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of 421 Internationalized String ("stringprep")", December 2002. 423 [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, 424 "Internationalizing Domain Names in Applications (IDNA)", March 2003. 426 [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile 427 for Internationalized Domain Names (IDN)", March 2003. 429 [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode 430 for Internationalized Domain Names in Applications (IDNA)", March 431 2003. 433 [UNICODE] - The Unicode Consortium, "The Unicode Standard", 434 . 436 Changes Between Draft Version 438 RFC Editor: The following summaries of changes between draft versions 439 are to be removed before publication. 441 -02 to -03 Changes 443 The following changes were made between draft version -02 and -03: 445 1. Add internationalized domain name section and references. 447 2. Change to indicate that later input of a label for an existing DNS 448 name tree node may or may not be normalized to the earlier input or 449 override it or both may be preserved. 451 3. Numerous minor wording changes. 453 -03 to -04 Changes 455 The following changes were made between draft versions -03 and -04: 457 1. Change to conform to the new IPR, Copyright, etc., notice 458 requirements. 460 2. Change in some section headers for clarity. 462 3. Drop section on wildcards. 464 4. Add emphasis on loss of case preservation due to name compression. 466 5. Add references to RFCs 1995 and 3092. 468 -04 to -05 Changes 470 The following changes were made between draft versions -04 and -05: 472 1. More clearly state that this draft updates RFCs 1034, 1035 [STD 473 13]. 475 2. Add informative references to ISO 8859-1 and ISO 8859-2. 477 3. Fix hyphenation and capitalization nits. 479 -05 to -06 Changes 481 The following changes were made between draft version -05 and -06. 483 1. Add notation to the RFC Editor that the draft version change 484 summaries are to be removed before RFC publication. 486 2. Additional text explaining why labe case insensitivity is CLASS 487 independent. 489 3. Changes and additional text clarifying that the fact that 490 inconsistent case in data loaded into DNS may result in 491 unpredicatable or inconsistent case in DNS storage but has no effect 492 on the completeness of RR sets retrieved. 494 4. Add reference to [RFC 3363] and update reference to [RFC 2535] to 495 be to [RFC 4034]. 497 Author's Address 499 Donald E. Eastlake 3rd 500 Motorola Laboratories 501 155 Beaver Street 502 Milford, MA 01757 USA 504 Telephone: +1 508-786-7554 (w) 506 EMail: Donald.Eastlake@motorola.com 508 Expiration and File Name 510 This draft expires January 2006. 512 Its file name is draft-ietf-dnsext-insensitive-06.txt.