draft-ietf-dnsext-insensitive-03.txt		draft-ietf-dnsext-insensitive-04.txt
	INTERNET-DRAFT Donald E. Eastlake 3rd		INTERNET-DRAFT Donald E. Eastlake 3rd
	Clarifies STD0013 Motorola Laboratories		Clarifies STD0013 Motorola Laboratories
	Expires September 2003 April 2003		Expires December 2004 July 2004
	Domain Name System (DNS) Case Insensitivity Clarification		Domain Name System (DNS) Case Insensitivity Clarification
	------ ---- ------ ----- ---- ------------- -------------		------ ---- ------ ----- ---- ------------- -------------
	<draft-ietf-dnsext-insensitive-03.txt>		<draft-ietf-dnsext-insensitive-04.txt>
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Status of This Document		Status of This Document
			By submitting this Internet-Draft, I certify that any applicable
			patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	Distribution of this document is unlimited. Comments should be sent		Distribution of this document is unlimited. Comments should be sent
	to the DNSEXT working group at namedroppers@ops.ietf.org.		to the DNSEXT working group at namedroppers@ops.ietf.org.
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026. Internet-Drafts are		all provisions of Section 10 of RFC 2026. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
			Draft Shadow Directories can be accessed at
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	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 should not have any interoperability		of the rules. This clarification should not have any interoperability
	consequences.		consequences.
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
	skipping to change at page 2, line 26		skipping to change at page 2, line 26
	Status of This Document....................................1		Status of This Document....................................1
	Abstract...................................................1		Abstract...................................................1
	Acknowledgements...........................................2		Acknowledgements...........................................2
	Table of Contents..........................................2		Table of Contents..........................................2
	1. Introduction............................................3		1. Introduction............................................3
	2. Case Insensitivity of DNS Labels........................3		2. Case Insensitivity of DNS Labels........................3
	2.1 Escaping Unusual DNS Label Octets......................3		2.1 Escaping Unusual DNS Label Octets......................3
	2.2 Example Labels with Escapes............................4		2.2 Example Labels with Escapes............................4
	2.3 Name Lookup Case Insensitivity.........................4		3. Name Lookup, Label Types, and CLASS.....................4
	2.4 Original DNS Label Types...............................5		3.1 Original DNS Label Types...............................5
	3. Additional DNS Case Insensitivity Considerations........5
	3.1 CLASS Case Insensitivity Considerations................5
	3.2 Extended Label Type Case Insensitivity Considerations..5		3.2 Extended Label Type Case Insensitivity Considerations..5
			3.3 CLASS Case Insensitivity Considerations................5
	4. Case on Input and Output................................6		4. Case on Input and Output................................6
	4.1 DNS Output Case Preservation...........................6		4.1 DNS Output Case Preservation...........................6
	4.2 DNS Input Case Preservation............................6		4.2 DNS Input Case Preservation............................6
	4.3 Wildcard Matching......................................7
	5. Internationalized Domain Names..........................7		5. Internationalized Domain Names..........................7
	6. Security Considerations.................................7		6. Security Considerations.................................7
			Copyright and Disclaimer...................................9
	Normative References.......................................9		Normative References.......................................9
	Informative References.....................................9		Informative References....................................10
	-02 to -03 Changes........................................10		-02 to -03 Changes........................................10
	Author's Address..........................................10		-03 to -04 Changes........................................11
	Expiration and File Name..................................10		Author's Address..........................................11
			Expiration and File Name..................................11
	INTERNET-DRAFT DNS Case Insensitivity		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 of
	zero or more labels [STD 13][RFC 1591, 2606] that are treated in a		zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
	case insensitive fashion. This document clarifies the meaning of		case insensitive fashion. This document clarifies the meaning of
	skipping to change at page 3, line 39		skipping to change at page 3, line 39
	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 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.
	The individual octets of which DNS names consist are not limited to		However, the individual octets of which DNS names consist are not
	valid ASCII character codes. They are as 8-bit bytes and all values		limited to valid ASCII character codes. They are 8-bit bytes and all
	are allowed. Many applications, however, interprete them as ASCII		values are allowed. Many applications, however, interpret them as
	characters.		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 [STD 13] 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 of 0x21
	to 0x7E ("~"). That is to say, 0x2E and all octet values in the two		("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
	inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.		the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
	One typographic convention for octets that do not correspond to an		One typographic convention for octets that do not correspond to an
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
	ASCII printing graphic is to use a back-slash followed by the value of		ASCII printing graphic is to use a back-slash followed by the value
	the octet as an unsigned integer represented by exactly three decimal		of the octet as an unsigned integer represented by exactly three
	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 and the special		back-slash character used in this convention itself which can be
	label separator period (".") which can be expressed as \092 and \046		expressed as \092 or \\ and the special label separator period (".")
	respectively. It is advisable to avoid using a backslash to quote an		which can be expressed as and \046 or \. respectively. It is
	immediately following non-printing ASCII character code to avoid		advisable to avoid using a backslash to quote an immediately
	implementation difficulties.		following non-printing ASCII character code to avoid implementation
			difficulties.
	A back-slash followed by only one or two decimal digits is		A back-slash followed by only one or two decimal digits is undefined.
	undefined. A back-slash followed by four decimal digits produces two		A back-slash followed by four decimal digits produces two octets, the
	octets, the first octet having the value of the first three digits		first octet having the value of the first three digits considered as
	considered as a decimal number and the second octet being the		a decimal number and the second octet being the character code for
	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 show a 5 octet label where the second
	octet has all bits zero, the third is a backslahs,		octet has all bits zero, the third is a backslash, and the fourth
	and the fourth octet has all bits one.		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.
	2.3 Name Lookup Case Insensitivity		3. Name Lookup, Label Types, and CLASS
	The design decision was made that comparisons on name lookup for DNS		The design decision was made that comparisons on name lookup for DNS
	queries should be case insensitive [STD 13]. That is to say, a lookup		queries should be case insensitive [STD 13]. That is to say, a lookup
	string octet with a value in the inclusive range of 0x41 to 0x5A, the		string octet with a value in the inclusive range of 0x41 to 0x5A, the
	upper case ASCII letters, MUST match the identical value and also		upper case ASCII letters, MUST match the identical value and also
	match the corresponding value in the inclusive range 0x61 to 0x7A,		match the corresponding value in the inclusive range 0x61 to 0x7A,
	the lower case ASCII letters. And a lookup string octet with a lower		the lower case ASCII letters. And a lookup string octet with a lower
	case ASCII letter value MUST similarly match the identical value and		case ASCII letter value MUST similarly match the identical value and
	also match the corresponding value in the upper case ASCII letter		also match the corresponding value in the upper case ASCII letter
	range.		range.
	skipping to change at page 5, line 17		skipping to change at page 5, line 17
	One way to implement this rule would be, when comparing octets, to		One way to implement this rule would be, when comparing octets, to
	subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A		subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
	before the comparison. Such an operation is commonly known as "case		before the comparison. Such an operation is commonly known as "case
	folding" but implementation via case folding is not required. Note		folding" but implementation via case folding is not required. Note
	that the DNS case insensitivity does NOT correspond to the case		that the DNS case insensitivity does NOT correspond to the case
	folding specified in iso-8859-1 or iso-8859-2. For example, the		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		octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
	contexts, where they are interpreted as the upper and lower case		contexts, where they are interpreted as the upper and lower case
	version of "Y" with an acute accent, they might.		version of "Y" with an acute accent, they might.
	2.4 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 [RFC 1035] had only two types. ASCII
	labels, with a length of from zero to 63 octets and indirect labels		labels, with a length of from zero to 63 octets, and indirect labels
	which consist of an offset pointer to a name location elsewhere in		which consist of an offset pointer to a name location elsewhere in
	the wire encoding on a DNS message. (The ASCII label of length zero		the wire encoding on a DNS message. (The ASCII label of length zero
	is reserved for use as the name of the root node of the name tree.)		is reserved for use as the name of the root node of the name tree.)
	ASCII labels follow the ASCII case conventions described above.		ASCII labels follow the ASCII case conventions described herein and,
	Indirect labels are, in effect, replaced by the name to which they		as stated above, can actually contain arbitrary byte values. Indirect
	point which is then treated with the case insensitivity rules in this		labels are, in effect, replaced by the name to which they point which
	document.		is then treated with the case insensitivity rules in this document.
	3. Additional DNS Case Insensitivity Considerations		3.2 Extended Label Type Case Insensitivity Considerations
	This section clarifies the effect of DNS CLASS and extended Label		DNS was extended by [RFC 2671] to have additional label type numbers
	Type on case insensitivity.		available. (The only such type defined so far is the BINARY type [RFC
			2673].)
	3.1 CLASS Case Insensitivity Considerations		The ASCII case insensitivity conventions only apply to ASCII labels,
			that is to say, label type 0x0, whether appearing directly or invoked
			by indirect labels.
			3.3 CLASS Case Insensitivity Considerations
	As described in [STD 13] and [RFC 2929], DNS has an additional axis		As described in [STD 13] and [RFC 2929], DNS has an additional axis
	for data location called CLASS. The only CLASS in global use at this		for data location called CLASS. The only CLASS in global use at this
	time is the "IN" or Internet CLASS.		time is the "IN" or Internet CLASS.
	The handling of DNS label case is not CLASS dependent.		The handling of DNS label case is not CLASS dependent.
	3.2 Extended Label Type Case Insensitivity Considerations
	DNS was extended by [RFC 2671] to have additional label type numbers
	available. (The only such type defined so far is the BINARY type [RFC
	2673].)
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
	The ASCII case insensitivity conventions, or case folding, only apply
	to ASCII labels, that is to say, label type 0x0, whether appearing
	directly or invoked by indirect labels.
	4. Case on Input and Output		4. Case on Input and Output
	While ASCII label comparisons are case insensitive, case MUST be		While ASCII label comparisons are case insensitive, [STD 13] says
	preserved on output, except when output is optimized by the use of		case MUST be preserved on output, and preserved when convenient on
	indirect labels, and preserved when convenient on input.		input. However, this means less than it would appear since the
			preservation of case on output is NOT required when output is
			optimized by the use 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 marshalled by taking the label on the node whose name		if a name was marshaled by taking the label on the node whose name is
	is to be output, converting it to a typographically encoded ASCII		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 inserted. No "case conversion" or "case folding" is done
	during such output operations. However, to optimize output, indirect		during such output operations, thus "preserving" case. However, to
	labels may be used to point to names elsewhere in the DNS answer. In		optimize output, indirect labels may be used to point to names
	determining whether the name to be pointed to is the "same" as the		elsewhere in the DNS answer. In determining whether the name to be
	remainder of the name being optimized, the case insensitive		pointed to, for example the QNAME, is the "same" as the remainder of
	comparison specified above is done. Thus such optimization MAY		the name being optimized, the case insensitive comparison specified
	destroy the output preservation of case. This type of optimization is		above is done. Thus such optimization MAY easily destroy the output
	commonly called "name compression".		preservation of case. This type of optimization is commonly called
			"name compression".
	4.2 DNS Input Case Preservation		4.2 DNS Input Case Preservation
	Originally, DNS input came from an ASCII Master File as defined in		Originally, DNS input came from an ASCII Master File as defined in
	[STD 13]. DNS Dynamic update has been added as a source of DNS data		[STD 13] or a zone transfer. DNS Dynamic update and incremental zone
	[RFC 2136, 3007]. When a node in the DNS name tree is created by such		transfers [RFC 1995] have been added as a source of DNS data [RFC
	input, no case conversion is done and the case of ASCII labels is		2136, 3007]. When a node in the DNS name tree is created by any of
	preserved if they are for nodes being created. However, when a name		such inputs, no case conversion is done. Thus the case of ASCII
	label is input for a node that already exist in DNS data being		labels is preserved if they are for nodes being created. However,
	augmented or updated, the situation is more complex. Implemenations		when a name label is input for a node that already exist in DNS data
	may retain the case first input for such a label or allow new input		being held, the situation is more complex. Implementations may retain
	to override the old case or maintain separate copies preserving the		the case first input for such a label or allow new input to override
	input case.		the old case or even maintain separate copies preserving the input
			case.
	For example, if data with owner name "foo.bar.example" is input and		For example, if data with owner name "foo.bar.example" is input and
	then later data with owner name "xyz.BAR.example" is input, the name		then later data with owner name "xyz.BAR.example" is input, the name
	of the label on the "bar.example" node, i.e. "bar", might or might		of the label on the "bar.example" node, i.e. "bar", might or might
	not be changed to "BAR" or the actual input case could be preserved.		not be changed to "BAR" or the actual input case could be preserved.
			Thus later retrieval of data stored under "xyz.bar.example" in this
			case can easily return data with "xyz.BAR.example". The same
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
	Thus later retrieval of data stored under "xyz.bar.example" in this		considerations apply when inputting multiple data records with owner
	case can easily result is obtaining data with "xyz.BAR.example". The		names differing only in case. For example, if an "A" record is stored
	same considerations apply when inputting multiple data records with		as the first resourced record under owner name "xyz.BAR.example" and
	owner names differing only in case. From the example above, if an "A"		then a second "A" record is stored under "XYZ.BAR.example", the
	record is stored under owner name "xyz.BAR.example" and then a second		second MAY be stored with the first (lower case initial label) name
	"A" record under "XYZ.BAR.example", the second MAY be stored with the		or the second MAY override the first so that only an upper case
	first (lower case initial label) name.		initial label is retained or both capitalizations MAY be kept.
	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
	unpredicatable output capitalization.		unpredictable output capitalization.
	4.3 Wildcard Matching
	There is one additional instance of note, which reflects the general
	rules that output case reflects input case unless there is
	conflicting capitalization in the DNS database or the output case is
	hidden by name compression. This is when a query matches a wildcard
	in the DNS database at a server. In that case, the answer SHOULD
	reflect the input case of the label or labels that matched the
	wildcard unless they are replaced by an indirect label which MAY
	point to a name with different 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 [RFC 3490, 3454, 3491, and
	3492]. It makes most of [UNICODE] available through a separate		3492]. It makes most of [UNICODE] available through a separate
	application level transformation from internationalized domain name		application level transformation from internationalized domain name
	to DNS domain name and from DNS domain name to internationalized		to DNS domain name and from DNS domain name to internationalized
	domain name. Any case insensitivity that internationalized domain		domain name. Any case insensitivity that internationalized domain
	names and labels have varies depending on the script and is handled		names and labels have varies depending on the script and is handled
	skipping to change at page 8, line 5		skipping to change at page 7, line 40
	[RFC 3491] which should be seen for further details. This is not a		[RFC 3491] which should be seen for further details. This is not a
	part of the DNS as standardized in STD 13.		part of the DNS as standardized in STD 13.
	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 two domain names
	differing only in case were actually different names.		differing only in case were actually different names.
	INTERNET-DRAFT DNS Case Insensitivity
	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
	system. Or it could be interpreted as binary data by some integrity		system. Or it could be interpreted as binary data by some integrity
	or authentication code system. These problems can usually be handled		or authentication code system. These problems can usually be handled
	by using a standardized or "canonical" form of the DNS ASCII type		by using a standardized or "canonical" form of the DNS ASCII type
	labels, that is, always map the ASCII letter value octets in ASCII		labels, that is, always mapping the ASCII letter value octets in
	labels to some specific pre-chosen case, either upper case or lower		ASCII labels to some specific pre-chosen case, either upper case or
	case. An example of a canonical form for domain names (and also a		lower case. An example of a canonical form for domain names (and also
	canonical ordering for them) appears in Section 8 of [RFC 2535]. See		a canonical ordering for them) appears in Section 8 of [RFC 2535].
	also [UNKRR].		See also [RFC 3597].
	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, although
			INTERNET-DRAFT DNS Case Insensitivity
	this would be quite rare, on a system with case sensitive email		this would be quite rare, on a system with case sensitive email
	address local parts, an attempt to store two "RP" records that		address local parts, an attempt to store two "RP" records that
	differed only in case would probably produce unexpected results that		differed only in case would probably produce unexpected results that
	might have security implications. That is because the entire email		might have security implications. That is because the entire email
	address, including the possibly case sensitive local or left hand		address, including the possibly case sensitive local or left hand
	part, is encoded into a DNS name in a readable fashion where the case		part, is encoded into a DNS name in a readable fashion where the case
	of some letters might be changed on output as described above.		of some letters might be changed on output as described above.
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
			Copyright and Disclaimer
			Copyright (C) The Internet Society 2004. 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.
			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.
	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].		[RFC 1034, 1035] - See [STD 13].
	[RFC 2119] - "Key words for use in RFCs to Indicate Requirement		[RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
	Levels", S. Bradner, March 1997.		1996.
			[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
			Requirement Levels", March 1997.
	[RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,		[RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
	"Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.		"Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
	[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",		[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
	March 1999.		March 1999.
	[RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic		[RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
	Update", November 2000.		Update", November 2000.
			[RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
			draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
	[STD 13]		[STD 13]
	- P. Mockapetris, "Domain names - concepts and facilities", RFC		- P. Mockapetris, "Domain names - concepts and facilities", RFC
	1034, November 1987.		1034, November 1987.
	- P. Mockapetris, "Domain names - implementation and		- P. Mockapetris, "Domain names - implementation and
	specification", RFC 1035, November 1987.		specification", RFC 1035, November 1987.
	[UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",		INTERNET-DRAFT DNS Case Insensitivity
	draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
	Informative References		Informative References
	[RFC 1591] - J. Postel, "Domain Name System Structure and		[RFC 1591] - J. Postel, "Domain Name System Structure and
	Delegation", March 1994.		Delegation", March 1994.
	[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",		[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
	June 1999.		June 1999.
	[RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain		[RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
	Name System (DNS) IANA Considerations", September 2000.		Name System (DNS) IANA Considerations", September 2000.
	[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August		[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
	1999.		1999.
	[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",		[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
	August 1999.		August 1999.
			[RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
			Foo", 1 April 2001.
	[RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of		[RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
	Internationalized String ("stringprep")", December 2002.		Internationalized String ("stringprep")", December 2002.
	INTERNET-DRAFT DNS Case Insensitivity
	[RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,		[RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
	"Internationalizing Domain Names in Applications (IDNA)", March 2003.		"Internationalizing Domain Names in Applications (IDNA)", March 2003.
	[RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile		[RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
	for Internationalized Domain Names (IDN)", March 2003.		for Internationalized Domain Names (IDN)", March 2003.
	[RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode		[RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
	for Internationalized Domain Names in Applications (IDNA)", March		for Internationalized Domain Names in Applications (IDNA)", March
	2003.		2003.
	skipping to change at page 10, line 32		skipping to change at page 11, line 5
	The following changes were made between draft version -02 and -03:		The following changes were made between draft version -02 and -03:
	1. Add internationalized domain name section and references.		1. Add internationalized domain name section and references.
	2. Change to indicate that later input of a label for an existing DNS		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		name tree node may or may not be normalized to the earlier input or
	override it or both may be preserved.		override it or both may be preserved.
	3. Numerous minor wording changes.		3. Numerous minor wording changes.
			INTERNET-DRAFT DNS Case Insensitivity
			-03 to -04 Changes
			The following changes were made between draft version -03 and -04:
			1. Change to conform to the new IPR, Copyright, etc., notice
			requirements.
			2. Change in some section headers for clarity.
			3. Drop section on wildcards.
			4. Add emphasis on loss of case preservation due to name compression.
			5. Add references to RFCs 1995 and 3092.
	Author's Address		Author's Address
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Motorola Laboratories		Motorola Laboratories
	155 Beaver Street		155 Beaver Street
	Milford, MA 01757 USA		Milford, MA 01757 USA
	Telephone: +1 508-851-8280 (w)		Telephone: +1 508-786-7554 (w)
	+1 508-634-2066 (h)		+1 508-634-2066 (h)
	EMail: Donald.Eastlake@motorola.com		EMail: Donald.Eastlake@motorola.com
	Expiration and File Name		Expiration and File Name
	This draft expires September 2003.		This draft expires December 2004.
	Its file name is draft-ietf-dnsext-insensitive-03.txt.		Its file name is draft-ietf-dnsext-insensitive-04.txt.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/