< draft-ietf-idnabis-rationale-12.txt		draft-ietf-idnabis-rationale-13.txt >
	Network Working Group J. Klensin		Network Working Group J. Klensin
	Internet-Draft September 10, 2009		Internet-Draft September 13, 2009
	Intended status: Informational		Intended status: Informational
	Expires: March 14, 2010		Expires: March 17, 2010
	Internationalized Domain Names for Applications (IDNA): Background,		Internationalized Domain Names for Applications (IDNA): Background,
	Explanation, and Rationale		Explanation, and Rationale
	draft-ietf-idnabis-rationale-12.txt		draft-ietf-idnabis-rationale-13.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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.
	This Internet-Draft will expire on March 14, 2010.		This Internet-Draft will expire on March 17, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 50 ¶		skipping to change at page 3, line 50 ¶
	A.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 43		A.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 43
	A.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 44		A.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 44
	A.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 44		A.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 44
	A.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 45		A.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 45
	A.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 45		A.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 45
	A.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 45		A.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 45
	A.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 46		A.9. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 46
	A.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 46		A.10. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 46
	A.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 46		A.11. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 46
	A.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 47		A.12. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 47
			A.13. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 47
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47
	1. Introduction		1. Introduction
	1.1. Context and Overview		1.1. Context and Overview
	Internationalized Domain Names in Applications (IDNA) is a collection		Internationalized Domain Names in Applications (IDNA) is a collection
	of standards that allow client applications to convert some Unicode		of standards that allow client applications to convert some Unicode
	mnemonics to an ASCII-compatible encoding form ("ACE") which is a		mnemonics to an ASCII-compatible encoding form ("ACE") which is a
	valid DNS label containing only letters, digits, and hyphens. The		valid DNS label containing only letters, digits, and hyphens. The
	skipping to change at page 12, line 32 ¶		skipping to change at page 12, line 32 ¶
	the previous and subsequent characters have the DFG property".		the previous and subsequent characters have the DFG property".
	Because it is easier to identify these characters than to know that		Because it is easier to identify these characters than to know that
	they are actually needed in IDNs or how to establish exactly the		they are actually needed in IDNs or how to establish exactly the
	right rules for each one, a rule may have a null value in a given		right rules for each one, a rule may have a null value in a given
	version of the tables. Characters associated with null rules are not		version of the tables. Characters associated with null rules are not
	permitted to appear in putative labels for either registration or		permitted to appear in putative labels for either registration or
	lookup. Of course, a later version of the tables might contain a		lookup. Of course, a later version of the tables might contain a
	non-null rule.		non-null rule.
	The actual rules and their descriptions are in [IDNA2008-Tables].		The actual rules and their descriptions are in Sections 2 and 3 of
	[[anchor9: ??? Section number would be good here.]] That document		[IDNA2008-Tables]. That document also specifies the creation of a
	also specifies the creation of a registry for future rules.		registry for future rules.
	3.1.3. DISALLOWED		3.1.3. DISALLOWED
	Some characters are inappropriate for use in IDNs and are thus		Some characters are inappropriate for use in IDNs and are thus
	excluded for both registration and lookup (i.e., IDNA-conforming		excluded for both registration and lookup (i.e., IDNA-conforming
	applications performing name lookup should verify that these		applications performing name lookup should verify that these
	characters are absent; if they are present, the label strings should		characters are absent; if they are present, the label strings should
	be rejected rather than converted to A-labels and looked up. Some of		be rejected rather than converted to A-labels and looked up. Some of
	these characters are problematic for use in IDNs (such as the		these characters are problematic for use in IDNs (such as the
	FRACTION SLASH character, U+2044), while some of them (such as the		FRACTION SLASH character, U+2044), while some of them (such as the
	skipping to change at page 14, line 30 ¶		skipping to change at page 14, line 30 ¶
	from scripts that are well-understood by the registry or its		from scripts that are well-understood by the registry or its
	advisers. If a registry decides to reduce opportunities for		advisers. If a registry decides to reduce opportunities for
	confusion by constructing policies that disallow characters used in		confusion by constructing policies that disallow characters used in
	historic writing systems or characters whose use is restricted to		historic writing systems or characters whose use is restricted to
	specialized, highly technical contexts, some relevant information may		specialized, highly technical contexts, some relevant information may
	be found in Section 2.4 "Specific Character Adjustments", Table 4		be found in Section 2.4 "Specific Character Adjustments", Table 4
	"Candidate Characters for Exclusion from Identifiers" of		"Candidate Characters for Exclusion from Identifiers" of
	[Unicode-UAX31] and Section 3.1. "General Security Profile for		[Unicode-UAX31] and Section 3.1. "General Security Profile for
	Identifiers" in [Unicode-Security].		Identifiers" in [Unicode-Security].
	The requirement (in [IDNA2008-Protocol] [[anchor10: ?? Section		The requirement (in Section 4.1 of [IDNA2008-Protocol]) that
	number]]) that registration procedures use only U-labels and/or		registration procedures use only U-labels and/or A-labels is intended
	A-labels is intended to ensure that registrants are fully aware of		to ensure that registrants are fully aware of exactly what is being
	exactly what is being registered as well as encouraging use of those		registered as well as encouraging use of those canonical forms. That
	canonical forms. That provision should not be interpreted as		provision should not be interpreted as requiring that registrant need
	requiring that registrant need to provide characters in a particular		to provide characters in a particular code sequence. Registrant
	code sequence. Registrant input conventions and management are part		input conventions and management are part of registrant-registrar
	of registrant-registrar interactions and relationships between		interactions and relationships between registries and registrars and
	registries and registrars and are outside the scope of these		are outside the scope of these standards.
	standards.
	It is worth stressing that these principles of policy development and		It is worth stressing that these principles of policy development and
	application apply at all levels of the DNS, not only, e.g., TLD or		application apply at all levels of the DNS, not only, e.g., TLD or
	SLD registrations and that even a trivial, "anything is permitted		SLD registrations. Even a trivial, "anything is permitted that is
	that is valid under the protocol" policy is helpful in that it helps		valid under the protocol" policy is helpful in that it helps users
	users and application developers know what to expect.		and application developers know what to expect.
	3.3. Layered Restrictions: Tables, Context, Registration, Applications		3.3. Layered Restrictions: Tables, Context, Registration, Applications
	The character rules in IDNA2008 are based on the realization that		The character rules in IDNA2008 are based on the realization that
	there is no single magic bullet for any of the security,		there is no single magic bullet for any of the security,
	confusability, or other issues associated with IDNs. Instead, the		confusability, or other issues associated with IDNs. Instead, the
	specifications define a variety of approaches. The character tables		specifications define a variety of approaches. The character tables
	are the first mechanism, protocol rules about how those characters		are the first mechanism, protocol rules about how those characters
	are applied or restricted in context are the second, and those two in		are applied or restricted in context are the second, and those two in
	combination constitute the limits of what can be done in the		combination constitute the limits of what can be done in the
	skipping to change at page 47, line 36 ¶		skipping to change at page 47, line 36 ¶
	concept was needed, the text now says "valid under IDNA" or		concept was needed, the text now says "valid under IDNA" or
	equivalent.		equivalent.
	o Adjusted Acknowledgments to remove Mark Davis's name, per his		o Adjusted Acknowledgments to remove Mark Davis's name, per his
	request and advice from IETF Trust Counsel.		request and advice from IETF Trust Counsel.
	o Incorporated other changes from WG Last Call.		o Incorporated other changes from WG Last Call.
	o Small typographical and editorial corrections.		o Small typographical and editorial corrections.
			A.13. Version -13
			o Substituted in Section numbers to references to other IDNA2008
			documents.
	Author's Address		Author's Address
	John C Klensin		John C Klensin
	1770 Massachusetts Ave, Ste 322		1770 Massachusetts Ave, Ste 322
	Cambridge, MA 02140		Cambridge, MA 02140
	USA		USA
	Phone: +1 617 245 1457		Phone: +1 617 245 1457
	Email: john+ietf@jck.com		Email: john+ietf@jck.com
End of changes. 9 change blocks.
	20 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/