draft-ietf-dnsext-insensitive-06.txt		rfc4343.txt
	INTERNET-DRAFT Donald E. Eastlake 3rd		Network Working Group D. Eastlake 3rd
	Updates RFC 1034, 1035 Motorola Laboratories		Request for Comments: 4343 Motorola Laboratories
	Expires January 2006 July 2005		Updates: 1034, 1035, 2181 January 2006
			Category: Standards Track
	Domain Name System (DNS) Case Insensitivity Clarification		Domain Name System (DNS) Case Insensitivity Clarification
	------ ---- ------ ----- ---- ------------- -------------
	<draft-ietf-dnsext-insensitive-06.txt>
	Donald E. Eastlake 3rd
	Status of This Document
	By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Distribution of this document is unlimited. Comments should be sent		Status of This Memo
	to the DNSEXT working group at namedroppers@ops.ietf.org.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than a "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		This document specifies an Internet standards track protocol for the
	http://www.ietf.org/shadow.html		Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
			Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	Domain Name System (DNS) names are "case insensitive". This document		Domain Name System (DNS) names are "case insensitive". This document
	explains exactly what that means and provides a clear specification		explains exactly what that means and provides a clear specification
	of the rules. This clarification updates RFCs 1034 and 1035.		of the rules. This clarification updates RFCs 1034, 1035, and 2181.
	INTERNET-DRAFT DNS Case Insensitivity
	Acknowledgements
	The contributions to this document of Rob Austein, Olafur
	Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
	Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
	are gratefully acknowledged.
	Table of Contents		Table of Contents
	Status of This Document....................................1		1. Introduction ....................................................2
	Copyright Notice...........................................1		2. Case Insensitivity of DNS Labels ................................2
	Abstract...................................................1		2.1. Escaping Unusual DNS Label Octets ..........................2
			2.2. Example Labels with Escapes ................................3
	Acknowledgements...........................................2		3. Name Lookup, Label Types, and CLASS .............................3
	Table of Contents..........................................2		3.1. Original DNS Label Types ...................................4
			3.2. Extended Label Type Case Insensitivity Considerations ......4
	1. Introduction............................................3		3.3. CLASS Case Insensitivity Considerations ....................4
	2. Case Insensitivity of DNS Labels........................3		4. Case on Input and Output ........................................5
	2.1 Escaping Unusual DNS Label Octets......................3		4.1. DNS Output Case Preservation ...............................5
	2.2 Example Labels with Escapes............................4		4.2. DNS Input Case Preservation ................................5
	3. Name Lookup, Label Types, and CLASS.....................4		5. Internationalized Domain Names ..................................6
	3.1 Original DNS Label Types...............................5		6. Security Considerations .........................................6
	3.2 Extended Label Type Case Insensitivity Considerations..5		7. Acknowledgements ................................................7
	3.3 CLASS Case Insensitivity Considerations................5		Normative References................................................7
	4. Case on Input and Output................................6		Informative References..............................................8
	4.1 DNS Output Case Preservation...........................6
	4.2 DNS Input Case Preservation............................6
	5. Internationalized Domain Names..........................7
	6. Security Considerations.................................8
	Copyright and Disclaimer...................................9
	Normative References.......................................9
	Informative References....................................10
	Changes Between Draft Version.............................11
	-02 to -03 Changes........................................11
	-03 to -04 Changes........................................11
	-04 to -05 Changes........................................11
	-05 to -06 Changes........................................12
	Author's Address..........................................13
	Expiration and File Name..................................13
	INTERNET-DRAFT DNS Case Insensitivity
	1. Introduction		1. Introduction
	The Domain Name System (DNS) is the global hierarchical replicated		The Domain Name System (DNS) is the global hierarchical replicated
	distributed database system for Internet addressing, mail proxy, and		distributed database system for Internet addressing, mail proxy, and
	other information. Each node in the DNS tree has a name consisting of		other information. Each node in the DNS tree has a name consisting
	zero or more labels [STD 13][RFC 1591, 2606] that are treated in a		of zero or more labels [STD13, RFC1591, RFC2606] that are treated in
	case insensitive fashion. This document clarifies the meaning of		a case insensitive fashion. This document clarifies the meaning of
	"case insensitive" for the DNS. This clarification updates RFCs 1034		"case insensitive" for the DNS. This clarification updates RFCs
	and 1035 [STD 13].		1034, 1035 [STD13], and [RFC2181].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC 2119].		document are to be interpreted as described in [RFC 2119].
	2. Case Insensitivity of DNS Labels		2. Case Insensitivity of DNS Labels
	DNS was specified in the era of [ASCII]. DNS names were expected to		DNS was specified in the era of [ASCII]. DNS names were expected to
	look like most host names or Internet email address right halves (the		look like most host names or Internet email address right halves (the
	part after the at-sign, "@") or be numeric as in the in-addr.arpa		part after the at-sign, "@") or to be numeric, as in the in-addr.arpa
	part of the DNS name space. For example,		part of the DNS name space. For example,
	foo.example.net.		foo.example.net.
	aol.com.		aol.com.
	www.gnu.ai.mit.edu.		www.gnu.ai.mit.edu.
	or 69.2.0.192.in-addr.arpa.		or 69.2.0.192.in-addr.arpa.
	Case varied alternatives to the above would be DNS names like		Case-varied alternatives to the above [RFC3092] would be DNS names
			like
	Foo.ExamplE.net.		Foo.ExamplE.net.
	AOL.COM.		AOL.COM.
	WWW.gnu.AI.mit.EDU.		WWW.gnu.AI.mit.EDU.
	or 69.2.0.192.in-ADDR.ARPA.		or 69.2.0.192.in-ADDR.ARPA.
	However, the individual octets of which DNS names consist are not		However, the individual octets of which DNS names consist are not
	limited to valid ASCII character codes. They are 8-bit bytes and all		limited to valid ASCII character codes. They are 8-bit bytes, and
	values are allowed. Many applications, however, interpret them as		all values are allowed. Many applications, however, interpret them
	ASCII characters.		as ASCII characters.
	2.1 Escaping Unusual DNS Label Octets		2.1. Escaping Unusual DNS Label Octets
	In Master Files [STD 13] and other human readable and writable ASCII		In Master Files [STD13] and other human-readable and -writable ASCII
	contexts, an escape is needed for the byte value for period (0x2E,		contexts, an escape is needed for the byte value for period (0x2E,
	".") and all octet values outside of the inclusive range of 0x21		".") and all octet values outside of the inclusive range from 0x21
	("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in		("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
	the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.		the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
	INTERNET-DRAFT DNS Case Insensitivity
	One typographic convention for octets that do not correspond to an		One typographic convention for octets that do not correspond to an
	ASCII printing graphic is to use a back-slash followed by the value		ASCII printing graphic is to use a back-slash followed by the value
	of the octet as an unsigned integer represented by exactly three		of the octet as an unsigned integer represented by exactly three
	decimal digits.		decimal digits.
	The same convention can be used for printing ASCII characters so that		The same convention can be used for printing ASCII characters so that
	they will be treated as a normal label character. This includes the		they will be treated as a normal label character. This includes the
	back-slash character used in this convention itself which can be		back-slash character used in this convention itself, which can be
	expressed as \092 or \\ and the special label separator period (".")		expressed as \092 or \\, and the special label separator period
	which can be expressed as and \046 or \. respectively. It is		("."), which can be expressed as and \046 or \. It is advisable to
	advisable to avoid using a backslash to quote an immediately		avoid using a backslash to quote an immediately following non-
	following non-printing ASCII character code to avoid implementation		printing ASCII character code to avoid implementation difficulties.
	difficulties.
	A back-slash followed by only one or two decimal digits is undefined.		A back-slash followed by only one or two decimal digits is undefined.
	A back-slash followed by four decimal digits produces two octets, the		A back-slash followed by four decimal digits produces two octets, the
	first octet having the value of the first three digits considered as		first octet having the value of the first three digits considered as
	a decimal number and the second octet being the character code for		a decimal number, and the second octet being the character code for
	the fourth decimal digit.		the fourth decimal digit.
	2.2 Example Labels with Escapes		2.2. Example Labels with Escapes
	The first example below shows embedded spaces and a period (".")		The first example below shows embedded spaces and a period (".")
	within a label. The second one show a 5-octet label where the second		within a label. The second one shows a 5-octet label where the
	octet has all bits zero, the third is a backslash, and the fourth		second octet has all bits zero, the third is a backslash, and the
	octet has all bits one.		fourth octet has all bits one.
	Donald\032E\.\032Eastlake\0323rd.example.		Donald\032E\.\032Eastlake\0323rd.example.
	and a\000\\\255z.example.		and a\000\\\255z.example.
	3. Name Lookup, Label Types, and CLASS		3. Name Lookup, Label Types, and CLASS
	The original DNS design decision was made that comparisons on name		According to the original DNS design decision, comparisons on name
	lookup for DNS queries should be case insensitive [STD 13]. That is		lookup for DNS queries should be case insensitive [STD 13]. That is
	to say, a lookup string octet with a value in the inclusive range of		to say, a lookup string octet with a value in the inclusive range
	0x41 to 0x5A, the upper case ASCII letters, MUST match the identical		from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
	value and also match the corresponding value in the inclusive range		identical value and also match the corresponding value in the
	0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet		inclusive range from 0x61 to 0x7A, the lowercase ASCII letters. A
	with a lower case ASCII letter value MUST similarly match the		lookup string octet with a lowercase ASCII letter value MUST
	identical value and also match the corresponding value in the upper		similarly match the identical value and also match the corresponding
	case ASCII letter range.		value in the uppercase ASCII letter range.
	(Historical Note: the terms "upper case" and "lower case" were
	invented after movable type. The terms originally referred to the
	two font trays for storing, in partitioned areas, the different
	physical type elements. Before movable type, the nearest equivalent
	INTERNET-DRAFT DNS Case Insensitivity
	terms were "majuscule" and "minuscule".)
	One way to implement this rule would be, when comparing octets, to		(Historical note: The terms "uppercase" and "lowercase" were invented
	subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A		after movable type. The terms originally referred to the two font
	before the comparison. Such an operation is commonly known as "case		trays for storing, in partitioned areas, the different physical type
	folding" but implementation via case folding is not required. Note		elements. Before movable type, the nearest equivalent terms were
	that the DNS case insensitivity does NOT correspond to the case		"majuscule" and "minuscule".)
	folding specified in [iso-8859-1] or [iso-8859-2]. For example, the		One way to implement this rule would be to subtract 0x20 from all
	octets 0xDD (\221) and 0xFD (\253) do NOT match although in other		octets in the inclusive range from 0x61 to 0x7A before comparing
	contexts, where they are interpreted as the upper and lower case		octets. Such an operation is commonly known as "case folding", but
	version of "Y" with an acute accent, they might.		implementation via case folding is not required. Note that the DNS
			case insensitivity does NOT correspond to the case folding specified
			in [ISO-8859-1] or [ISO-8859-2]. For example, the octets 0xDD (\221)
			and 0xFD (\253) do NOT match, although in other contexts, where they
			are interpreted as the upper- and lower-case version of "Y" with an
			acute accent, they might.
	3.1 Original DNS Label Types		3.1. Original DNS Label Types
	DNS labels in wire-encoded names have a type associated with them.		DNS labels in wire-encoded names have a type associated with them.
	The original DNS standard [RFC 1035] had only two types. ASCII		The original DNS standard [STD13] had only two types: ASCII labels,
	labels, with a length of from zero to 63 octets, and indirect (or		with a length from zero to 63 octets, and indirect (or compression)
	compression) labels which consist of an offset pointer to a name		labels, which consist of an offset pointer to a name location
	location elsewhere in the wire encoding on a DNS message. (The ASCII		elsewhere in the wire encoding on a DNS message. (The ASCII label of
	label of length zero is reserved for use as the name of the root node		length zero is reserved for use as the name of the root node of the
	of the name tree.) ASCII labels follow the ASCII case conventions		name tree.) ASCII labels follow the ASCII case conventions described
	described herein and, as stated above, can actually contain arbitrary		herein and, as stated above, can actually contain arbitrary byte
	byte values. Indirect labels are, in effect, replaced by the name to		values. Indirect labels are, in effect, replaced by the name to
	which they point which is then treated with the case insensitivity		which they point, which is then treated with the case insensitivity
	rules in this document.		rules in this document.
	3.2 Extended Label Type Case Insensitivity Considerations		3.2. Extended Label Type Case Insensitivity Considerations
	DNS was extended by [RFC 2671] to have additional label type numbers		DNS was extended by [RFC2671] so that additional label type numbers
	available. (The only such type defined so far is the BINARY type [RFC		would be available. (The only such type defined so far is the BINARY
	2673] which is now Experimental [RFC 3363].)		type [RFC2673], which is now Experimental [RFC3363].)
	The ASCII case insensitivity conventions only apply to ASCII labels,		The ASCII case insensitivity conventions only apply to ASCII labels;
	that is to say, label type 0x0, whether appearing directly or invoked		that is to say, label type 0x0, whether appearing directly or invoked
	by indirect labels.		by indirect labels.
	3.3 CLASS Case Insensitivity Considerations		3.3. CLASS Case Insensitivity Considerations
	As described in [STD 13] and [RFC 2929], DNS has an additional axis		As described in [STD13] and [RFC2929], DNS has an additional axis for
	for data location called CLASS. The only CLASS in global use at this		data location called CLASS. The only CLASS in global use at this
	time is the "IN" or Internet CLASS.		time is the "IN" (Internet) CLASS.
	The handling of DNS label case is not CLASS dependent. With the		The handling of DNS label case is not CLASS dependent. With the
	original design of DNS, it was intended that a recursive DNS resolver		original design of DNS, it was intended that a recursive DNS resolver
	INTERNET-DRAFT DNS Case Insensitivity
	be able to handle new CLASSes that were unknown at the time of its		be able to handle new CLASSes that were unknown at the time of its
	implementation. This requires uniform handling of label case		implementation. This requires uniform handling of label case
	insensitivity. Should it become desireable, for example, to allocate		insensitivity. Should it become desirable, for example, to allocate
	a CLASS with "case sensitive ASCII labels" for example, it would be		a CLASS with "case sensitive ASCII labels", it would be necessary to
	necessary to allocate a new label type for these labels.		allocate a new label type for these labels.
	4. Case on Input and Output		4. Case on Input and Output
	While ASCII label comparisons are case insensitive, [STD 13] says		While ASCII label comparisons are case insensitive, [STD13] says case
	case MUST be preserved on output, and preserved when convenient on		MUST be preserved on output and preserved when convenient on input.
	input. However, this means less than it would appear since the		However, this means less than it would appear, since the preservation
	preservation of case on output is NOT required when output is		of case on output is NOT required when output is optimized by the use
	optimized by the use of indirect labels, as explained below.		of indirect labels, as explained below.
	4.1 DNS Output Case Preservation		4.1. DNS Output Case Preservation
	[STD 13] views the DNS namespace as a node tree. ASCII output is as		[STD 13] views the DNS namespace as a node tree. ASCII output is as
	if a name was marshaled by taking the label on the node whose name is		if a name were marshaled by taking the label on the node whose name
	to be output, converting it to a typographically encoded ASCII		is to be output, converting it to a typographically encoded ASCII
	string, walking up the tree outputting each label encountered, and		string, walking up the tree outputting each label encountered, and
	preceding all labels but the first with a period ("."). Wire output		preceding all labels but the first with a period ("."). Wire output
	follows the same sequence but each label is wire encoded and no		follows the same sequence, but each label is wire encoded, and no
	periods inserted. No "case conversion" or "case folding" is done		periods are inserted. No "case conversion" or "case folding" is done
	during such output operations, thus "preserving" case. However, to		during such output operations, thus "preserving" case. However, to
	optimize output, indirect labels may be used to point to names		optimize output, indirect labels may be used to point to names
	elsewhere in the DNS answer. In determining whether the name to be		elsewhere in the DNS answer. In determining whether the name to be
	pointed to, for example the QNAME, is the "same" as the remainder of		pointed to (for example, the QNAME) is the "same" as the remainder of
	the name being optimized, the case insensitive comparison specified		the name being optimized, the case insensitive comparison specified
	above is done. Thus such optimization may easily destroy the output		above is done. Thus, such optimization may easily destroy the output
	preservation of case. This type of optimization is commonly called		preservation of case. This type of optimization is commonly called
	"name compression".		"name compression".
	4.2 DNS Input Case Preservation		4.2. DNS Input Case Preservation
	Originally, DNS data came from an ASCII Master File as defined in		Originally, DNS data came from an ASCII Master File as defined in
	[STD 13] or a zone transfer. DNS Dynamic update and incremental zone		[STD 13] or a zone transfer. DNS Dynamic update and incremental zone
	transfers [RFC 1995] have been added as a source of DNS data [RFC		transfers [RFC1995] have been added as a source of DNS data [RFC2136,
	2136, 3007]. When a node in the DNS name tree is created by any of		RFC3007]. When a node in the DNS name tree is created by any of such
	such inputs, no case conversion is done. Thus the case of ASCII		inputs, no case conversion is done. Thus, the case of ASCII labels
	labels is preserved if they are for nodes being created. However,		is preserved if they are for nodes being created. However, when a
	when a name label is input for a node that already exist in DNS data		name label is input for a node that already exists in DNS data being
	being held, the situation is more complex. Implementations are free		held, the situation is more complex. Implementations are free to
	to retain the case first loaded for such a label or allow new input		retain the case first loaded for such a label, to allow new input to
	to override the old case or even maintain separate copies preserving		override the old case, or even to maintain separate copies preserving
	INTERNET-DRAFT DNS Case Insensitivity
	the input case.		the input case.
	For example, if data with owner name "foo.bar.example" is loaded and		For example, if data with owner name "foo.bar.example" [RFC3092] is
	then later data with owner name "xyz.BAR.example" is input, the name		loaded and then later data with owner name "xyz.BAR.example" is
	of the label on the "bar.example" node, i.e. "bar", might or might		input, the name of the label on the "bar.example" node (i.e., "bar")
	not be changed to "BAR" in the DNS stored data or the actual input		might or might not be changed to "BAR" in the DNS stored data. Thus,
	case could be preserved. Thus later retrieval of data stored under		later retrieval of data stored under "xyz.bar.example" in this case
	"xyz.bar.example" in this case can return all data with		can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
	"xyz.BAR.example" or all data with "xyz.bar.example" or even, when		in all returned data, or even, when more than one RR is being
	more than one RR is being returned, a mixture of these two cases.		returned, use a mixture of these two capitalizations. This last case
	This last case is unlikely because optimization of answer length		is unlikely, as optimization of answer length through indirect labels
	through indirect labels tends to cause only copy of the name tail		tends to cause only one copy of the name tail ("bar.example" or
	("bar.example" or "BAR.example") to be used for all returned RRs.		"BAR.example") to be used for all returned RRs. Note that none of
	Note that none of this has any effect on the number of completeness		this has any effect on the number or completeness of the RR set
	of the RR set returned, only on the case of the names in the RR set		returned, only on the case of the names in the RR set returned.
	returned.
	The same considerations apply when inputting multiple data records		The same considerations apply when inputting multiple data records
	with owner names differing only in case. For example, if an "A"		with owner names differing only in case. For example, if an "A"
	record is the first resourced record stored under owner name		record is the first resource record stored under owner name
	"xyz.BAR.example" and then a second "A" record is stored under		"xyz.BAR.example" and then a second "A" record is stored under
	"XYZ.BAR.example", the second MAY be stored with the first (lower		"XYZ.BAR.example", the second MAY be stored with the first (lower
	case initial label) name or the second MAY override the first so that		case initial label) name, the second MAY override the first so that
	only an upper case initial label is retained or both capitalizations		only an uppercase initial label is retained, or both capitalizations
	MAY be kept in the DNS stored data. In any case, a retrieval with		MAY be kept in the DNS stored data. In any case, a retrieval with
	either capitalization will retrieve all RRs with either		either capitalization will retrieve all RRs with either
	capitalization.		capitalization.
	Note that the order of insertion into a server database of the DNS		Note that the order of insertion into a server database of the DNS
	name tree nodes that appear in a Master File is not defined so that		name tree nodes that appear in a Master File is not defined so that
	the results of inconsistent capitalization in a Master File are		the results of inconsistent capitalization in a Master File are
	unpredictable output capitalization.		unpredictable output capitalization.
	5. Internationalized Domain Names		5. Internationalized Domain Names
	A scheme has been adopted for "internationalized domain names" and		A scheme has been adopted for "internationalized domain names" and
	"internationalized labels" as described in [RFC 3490, 3454, 3491, and		"internationalized labels" as described in [RFC3490, RFC3454,
	3492]. It makes most of [UNICODE] available through a separate		RFC3491, and RFC3492]. It makes most of [UNICODE] available through
	application level transformation from internationalized domain name		a separate application level transformation from internationalized
	to DNS domain name and from DNS domain name to internationalized		domain name to DNS domain name and from DNS domain name to
	domain name. Any case insensitivity that internationalized domain		internationalized domain name. Any case insensitivity that
	names and labels have varies depending on the script and is handled		internationalized domain names and labels have varies depending on
	entirely as part of the transformation described in [RFC 3454] and		the script and is handled entirely as part of the transformation
	[RFC 3491] which should be seen for further details. This is not a		described in [RFC3454] and [RFC3491], which should be seen for
	part of the DNS as standardized in STD 13.		further details. This is not a part of the DNS as standardized in
			STD 13.
	INTERNET-DRAFT DNS Case Insensitivity
	6. Security Considerations		6. Security Considerations
	The equivalence of certain DNS label types with case differences, as		The equivalence of certain DNS label types with case differences, as
	clarified in this document, can lead to security problems. For		clarified in this document, can lead to security problems. For
	example, a user could be confused by believing two domain names		example, a user could be confused by believing that two domain names
	differing only in case were actually different names.		differing only in case were actually different names.
	Furthermore, a domain name may be used in contexts other than the		Furthermore, a domain name may be used in contexts other than the
	DNS. It could be used as a case sensitive index into some data base		DNS. It could be used as a case sensitive index into some data base
	or file system. Or it could be interpreted as binary data by some		or file system. Or it could be interpreted as binary data by some
	integrity or authentication code system. These problems can usually		integrity or authentication code system. These problems can usually
	be handled by using a standardized or "canonical" form of the DNS		be handled by using a standardized or "canonical" form of the DNS
	ASCII type labels, that is, always mapping the ASCII letter value		ASCII type labels; that is, always mapping the ASCII letter value
	octets in ASCII labels to some specific pre-chosen case, either upper		octets in ASCII labels to some specific pre-chosen case, either
	case or lower case. An example of a canonical form for domain names		uppercase or lower case. An example of a canonical form for domain
	(and also a canonical ordering for them) appears in Section 6 of [RFC		names (and also a canonical ordering for them) appears in Section 6
	4034]. See also [RFC 3597].		of [RFC4034]. See also [RFC3597].
	Finally, a non-DNS name may be stored into DNS with the false		Finally, a non-DNS name may be stored into DNS with the false
	expectation that case will always be preserved. For example, although		expectation that case will always be preserved. For example,
	this would be quite rare, on a system with case sensitive email		although this would be quite rare, on a system with case sensitive
	address local parts, an attempt to store two "RP" records that		email address local parts, an attempt to store two Responsible Person
	differed only in case would probably produce unexpected results that		(RP) [RFC1183] records that differed only in case would probably
	might have security implications. That is because the entire email		produce unexpected results that might have security implications.
	address, including the possibly case sensitive local or left hand		That is because the entire email address, including the possibly case
	part, is encoded into a DNS name in a readable fashion where the case		sensitive local or left-hand part, is encoded into a DNS name in a
	of some letters might be changed on output as described above.		readable fashion where the case of some letters might be changed on
			output as described above.
	INTERNET-DRAFT DNS Case Insensitivity
	Copyright and Disclaimer
	Copyright (C) The Internet Society (2005). This document is subject		7. Acknowledgements
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		The contributions to this document by Rob Austein, Olafur
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		are gratefully acknowledged.
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Normative References		Normative References
	[ASCII] - ANSI, "USA Standard Code for Information Interchange",		[ASCII] ANSI, "USA Standard Code for Information Interchange",
	X3.4, American National Standards Institute: New York, 1968.		X3.4, American National Standards Institute: New York,
			1968.
	[RFC 1034, 1035] - See [STD 13].		[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
			August 1996.
	[RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	1996.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate		[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
	Requirement Levels", March 1997.		"Dynamic Updates in the Domain Name System (DNS
			UPDATE)", RFC 2136, April 1997.
	[RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,		[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
	"Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.		Specification", RFC 2181, July 1997.
	[RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic		[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
	Update", November 2000.		Update", RFC 3007, November 2000.
	[RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",		[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
	draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.		(RR) Types", RFC 3597, September 2003.
	[RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions", RFC 4034,		Rose, "Resource Records for the DNS Security
	March 2005.		Extensions", RFC 4034, March 2005.
	[STD 13]		[STD13] Mockapetris, P., "Domain names - concepts and
	- P. Mockapetris, "Domain names - concepts and facilities", RFC		facilities", STD 13, RFC 1034, November 1987.
	1034, November 1987.
	- P. Mockapetris, "Domain names - implementation and
	specification", RFC 1035, November 1987.
	INTERNET-DRAFT DNS Case Insensitivity		Mockapetris, P., "Domain names - implementation and
			specification", STD 13, RFC 1035, November 1987.
	Informative References		Informative References
	[ISO 8859-1] - International Standards Organization, Standard for		[ISO-8859-1] International Standards Organization, Standard for
	Character Encodings, Latin-1.		Character Encodings, Latin-1.
	[ISO 8859-2] - International Standards Organization, Standard for		[ISO-8859-2] International Standards Organization, Standard for
	Character Encodings, Latin-2.		Character Encodings, Latin-2.
	[RFC 1591] - J. Postel, "Domain Name System Structure and		[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
	Delegation", March 1994.		Mockapetris, "New DNS RR Definitions", RFC 1183, October
			1990.
	[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
	June 1999.
	[RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
	Name System (DNS) IANA Considerations", September 2000.
	[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
	1999.
	[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
	August 1999.
	[RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
	Foo", 1 April 2001.
	[RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
	Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
	the Domain Name System (DNS)", RFC 3363, August 2002.
	[RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
	Internationalized String ("stringprep")", December 2002.
	[RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
	"Internationalizing Domain Names in Applications (IDNA)", March 2003.
	[RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
	for Internationalized Domain Names (IDN)", March 2003.
	[RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
	for Internationalized Domain Names in Applications (IDNA)", March
	2003.
	[UNICODE] - The Unicode Consortium, "The Unicode Standard",
	<http://www.unicode.org/unicode/standard/standard.html>.
	INTERNET-DRAFT DNS Case Insensitivity
	Changes Between Draft Version
	RFC Editor: The following summaries of changes between draft versions
	are to be removed before publication.
	-02 to -03 Changes
	The following changes were made between draft version -02 and -03:
	1. Add internationalized domain name section and references.
	2. Change to indicate that later input of a label for an existing DNS
	name tree node may or may not be normalized to the earlier input or
	override it or both may be preserved.
	3. Numerous minor wording changes.
	-03 to -04 Changes
	The following changes were made between draft versions -03 and -04:
	1. Change to conform to the new IPR, Copyright, etc., notice		[RFC1591] Postel, J., "Domain Name System Structure and
	requirements.		Delegation", RFC 1591, March 1994.
	2. Change in some section headers for clarity.		[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
			Names", BCP 32, RFC 2606, June 1999.
	3. Drop section on wildcards.		[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
			"Domain Name System (DNS) IANA Considerations", BCP 42,
			RFC 2929, September 2000.
	4. Add emphasis on loss of case preservation due to name compression.		[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
			2671, August 1999.
	5. Add references to RFCs 1995 and 3092.		[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
			RFC 2673, August 1999.
	-04 to -05 Changes		[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
			of "Foo"", RFC 3092, 1 April 2001.
	The following changes were made between draft versions -04 and -05:		[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
			Hain, "Representing Internet Protocol version 6 (IPv6)
			Addresses in the Domain Name System (DNS)", RFC 3363,
			August 2002.
	1. More clearly state that this draft updates RFCs 1034, 1035 [STD		[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
	13].		Internationalized Strings ("stringprep")", RFC 3454,
			December 2002.
	2. Add informative references to ISO 8859-1 and ISO 8859-2.		[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
			"Internationalizing Domain Names in Applications
			(IDNA)", RFC 3490, March 2003.
	3. Fix hyphenation and capitalization nits.		[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
			Profile for Internationalized Domain Names (IDN)", RFC
			3491, March 2003.
	INTERNET-DRAFT DNS Case Insensitivity		[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
			Unicode for Internationalized Domain Names in
			Applications (IDNA)", RFC 3492, March 2003.
	-05 to -06 Changes		[UNICODE] The Unicode Consortium, "The Unicode Standard",
			<http://www.unicode.org/unicode/standard/standard.html>.
	The following changes were made between draft version -05 and -06.		Author's Address
	1. Add notation to the RFC Editor that the draft version change		Donald E. Eastlake 3rd
	summaries are to be removed before RFC publication.		Motorola Laboratories
			155 Beaver Street
			Milford, MA 01757 USA
	2. Additional text explaining why labe case insensitivity is CLASS		Phone: +1 508-786-7554 (w)
	independent.		EMail: Donald.Eastlake@motorola.com
	3. Changes and additional text clarifying that the fact that		Full Copyright Statement
	inconsistent case in data loaded into DNS may result in
	unpredicatable or inconsistent case in DNS storage but has no effect
	on the completeness of RR sets retrieved.
	4. Add reference to [RFC 3363] and update reference to [RFC 2535] to		Copyright (C) The Internet Society (2006).
	be to [RFC 4034].
	INTERNET-DRAFT DNS Case Insensitivity		This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
	Author's Address		This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Donald E. Eastlake 3rd		Intellectual Property
	Motorola Laboratories
	155 Beaver Street
	Milford, MA 01757 USA
	Telephone: +1 508-786-7554 (w)		The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
	EMail: Donald.Eastlake@motorola.com		Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	Expiration and File Name		The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
	This draft expires January 2006.		Acknowledgement
	Its file name is draft-ietf-dnsext-insensitive-06.txt.		Funding for the RFC Editor function is provided by the IETF
			Administrative Support Activity (IASA).
End of changes. 86 change blocks.
	354 lines changed or deleted		263 lines changed or added
This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/