< draft-faltstrom-unicode11-00.txt		draft-faltstrom-unicode11-01.txt >
	Network Working Group P. Faltstrom		Network Working Group P. Faltstrom
	Internet-Draft Netnod		Internet-Draft Netnod
	Intended status: Informational June 17, 2018		Intended status: Informational July 2, 2018
	Expires: December 19, 2018		Expires: January 3, 2019
	IDNA2008 and Unicode 11.0.0		IDNA2008 and Unicode 11.0.0
	draft-faltstrom-unicode11-00		draft-faltstrom-unicode11-01
	Abstract		Abstract
	This document describes changes between Unicode 6.3.0 and Unicode		This document describes changes between Unicode 6.3.0 and Unicode
	11.0.0 in the context of IDNA2008. It further suggests for the IETF		11.0.0 in the context of IDNA2008. It further suggests for the IETF
	a path forward regarding ensuring IDNA2008 follows the evolution of		a path forward regarding ensuring IDNA2008 follows the evolution of
	the Unicode Standard.		the Unicode Standard.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on December 19, 2018.		This Internet-Draft will expire on January 3, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Keywords for Requirement Levels . . . . . . . . . . . . . . . 3
	2.1. IDNA2008 Documents . . . . . . . . . . . . . . . . . . . 3		3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. IDNA2008 Documents . . . . . . . . . . . . . . . . . . . 3
	3. Notable changes between Unicode 6.3.0 and 11.0.0 . . . . . . 5		3.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Changes to Unicode 7.0.0 . . . . . . . . . . . . . . . . 5		4. Notable changes between Unicode 6.3.0 and 11.0.0 . . . . . . 5
	3.2. Changes to Unicode 11.0.0 . . . . . . . . . . . . . . . . 6		4.1. Changes to Unicode 7.0.0 . . . . . . . . . . . . . . . . 5
	4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Changes to Unicode 11.0.0 . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.2. Non-normative references . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Appendix A. Changes from Unicode 6.3.0 to Unicode 7.0.0 . . . . 10		9.2. Non-normative references . . . . . . . . . . . . . . . . 9
	Appendix B. Changes from Unicode 7.0.0 to Unicode 8.0.0 . . . . 13		Appendix A. Changes from Unicode 6.3.0 to Unicode 7.0.0 . . . . 11
			Appendix B. Changes from Unicode 7.0.0 to Unicode 8.0.0 . . . . 14
	Appendix C. Changes from Unicode 8.0.0 to Unicode 9.0.0 . . . . 15		Appendix C. Changes from Unicode 8.0.0 to Unicode 9.0.0 . . . . 15
	Appendix D. Changes from Unicode 9.0.0 to Unicode 10.0.0 . . . . 16		Appendix D. Changes from Unicode 9.0.0 to Unicode 10.0.0 . . . . 16
	Appendix E. Changes from Unicode 10.0.0 to Unicode 11.0.0 . . . 17		Appendix E. Changes from Unicode 10.0.0 to Unicode 11.0.0 . . . 17
	Appendix F. Code points in Unicode Character Database (UCD)		Appendix F. Code points in Unicode Character Database (UCD)
	format for Unicode 11.0.0 . . . . . . . . . . . . . 19		format for Unicode 11.0.0 . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 78		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 78
	1. Introduction		1. Introduction
	The current version of Internationalized Domain Names for		The current version of Internationalized Domain Names for
	Applications (IDNA) was largely completed in 2008, known within the		Applications (IDNA) was largely completed in 2008, known within the
	series and elsewhere as "IDNA2008" and is specified in a series of		series and elsewhere as "IDNA2008" and is specified in a series of
	documents (see Section Section 2.1). The standard include an		documents (see Section Section 3.1). The standard include an
	algorithm by which a derived property value is calculated based on		algorithm by which a derived property value is calculated based on
	the properties defined in the Unicode Standard.		the properties defined in the Unicode Standard.
	When the Unicode Standard is updated code points are assigned that		When the Unicode Standard is updated code points are assigned that
	earlier was not and property values changes for already assigned code		earlier was not and property values changes for already assigned code
	points.		points.
	Assigning code points might create problems if the newly assigned		Assigning code points might create problems if the newly assigned
	code points are compositions of code points so that it either changes		code points are compositions of code points so that it either changes
	or would have changed the normalization functions. This because it		or would have changed the normalization functions. This because it
	changes the matching algorithms used which in turn might create		changes the matching algorithms used which in turn might create
	problems looking up already stored strings in for example DNS.		problems looking up already stored strings in for example DNS.
	Changing properties to already assigned code points might create		Changing properties to already assigned code points might create
	problems if the change do result in the derived property value		problems if the change do result in the derived property value
	changes. This might make an earlier allowed code point (derived		changes. This might make an earlier allowed code point (derived
	property value PVALID) not be allowed anymore (derived property value		property value PVALID) not be allowed anymore (derived property value
	DISALLOWED).		DISALLOWED).
	Historically the IETF have accepted all implications on changes in		Historically the IETF has accepted all implications of changes in the
	the Unicode Standard even though the changes have resulted in		Unicode Standard even though the changes have resulted in problematic
	problematic changes in the derived property value. Main reason have		changes in the derived property value. The primary reason for that
	been that staying with the Unicode Standard have been viewed as		is that staying with the Unicode Standard has been viewed as
	important given the diversity in implications already existing in the		important given the diversity in implementations already existing in
	wild.		the wild.
	The Internet Architecture Board did issue a statement [IAB] which		The Internet Architecture Board did issue a statement [IAB] which
	requested IETF to resolve the issues related to the in Unicode 7.0.0		requested IETF to resolve the issues related to the code point ARABIC
	[Unicode-7.0.0] introduced code point ARABIC LETTER BEH WITH HAMZA		LETTER BEH WITH HAMZA ABOVE (U+08A1), introduced in Unicode 7.0.0
	ABOVE (U+08A1). This document resolves this issue and suggests		[Unicode-7.0.0]. This document resolves this issue and suggests
	IDNA2008 standard is to follow the Unicode Standard and not update		IDNA2008 standard is to follow the Unicode Standard and not update
	RFC 5892 [RFC5892] and others.		RFC 5892 [RFC5892] or any other IDNA2008 RFCs.
	2. Background		2. Keywords for Requirement Levels
	2.1. IDNA2008 Documents		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC2119].
			3. Background
			3.1. IDNA2008 Documents
	IDNA2008 consists of the following documents:		IDNA2008 consists of the following documents:
	o A document, RFC 5890 [RFC5890], containing definitions and other		o A document, RFC 5890 [RFC5890], containing definitions and other
	material that are needed for understanding other documents in the		material that are needed for understanding other documents in the
	set. It is referred to informally in other documents in the set		set. It is referred to informally in other documents in the set
	as "Defs" or "Definitions".		as "Defs" or "Definitions".
	o A document, RFC 5891 [RFC5891], that describes the core IDNA2008		o A document, RFC 5891 [RFC5891], that describes the core IDNA2008
	protocol and its operations. It is to be interpreted in		protocol and its operations. It is to be interpreted in
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 32 ¶
	required part of IDNA.		required part of IDNA.
	o A document, RFC 6452 [RFC6452], that looks at some changes made to		o A document, RFC 6452 [RFC6452], that looks at some changes made to
	Unicode 6.0.0 [Unicode-6.0.0] that resulted in the derived		Unicode 6.0.0 [Unicode-6.0.0] that resulted in the derived
	property value change for the code points U+0CF1, U+0CF2 and		property value change for the code points U+0CF1, U+0CF2 and
	U+19DA. The first two changed from DISALLOWED to PVALID, the last		U+19DA. The first two changed from DISALLOWED to PVALID, the last
	from PVALID to DISSALOWED. IETF came to the conclusion the		from PVALID to DISSALOWED. IETF came to the conclusion the
	changes where acceptable and RFC 5892 [RFC5892] was not updated to		changes where acceptable and RFC 5892 [RFC5892] was not updated to
	make the derived property value not change for these code points.		make the derived property value not change for these code points.
	2.2. Deployment		3.2. Deployment
	The deployment of IDNA2008 is unfortunately quite diverse.		The deployment of IDNA2008 is unfortunately quite diverse. The
	Implementations exists doing at least the following:		following lists some of the strategies that existing implementations
			are known to implement:
	o IDNA2003 as specified in RFC 3490 [RFC3490] and RFC 3491 [RFC3491]		o IDNA2003 as specified in RFC 3490 [RFC3490] and RFC 3491 [RFC3491]
	which implies using a table within which it is said whether code		which implies using a table within which it is said whether code
	points are allowed to be used or not, and this after doing the in		points are allowed to be used or not, and this after doing the in
	IDNA2003 included normalization.		IDNA2003 included normalization.
	o A mix between IDNA2003 and IDNA2008 where code points assigned to		o A mix between IDNA2003 and IDNA2008 where code points assigned to
	Unicode after Unicode 3.2.0 [Unicode-3.2.0] have derived property		Unicode after Unicode 3.2.0 [Unicode-3.2.0] have derived property
	value calculated according to the algorithm specified in IDNA2008.		value calculated according to the algorithm specified in IDNA2008.
	o Strict IDNA2008 following IANA which implies stayed at Unicode		o Strict IDNA2008 following IANA which implies stayed at Unicode
	6.3.0 [Unicode-6.3.0] and treating later assigned code points as		6.3.0 [Unicode-6.3.0] and treating later assigned code points as
	UNASSIGNED.		UNASSIGNED.
	o IDNA2008 algorithm applied to whatever version of Unicode Standard		o The IDNA2008 algorithm applied to whatever version of Unicode
	exists in the operating system and/or libraries used, regardless		Standard exists in the operating system and/or libraries used,
	of whether the version is later than Unicode version 6.3.0 or not.		regardless of whether the version is later than Unicode version
			6.3.0 or not.
	o A mix between IDNA2003 and IDNA2008 according to local		o A mix between IDNA2003 and IDNA2008 according to local
	interpretation of the Unicode Technical Standard #46 [UTS-46].		interpretation of the Unicode Technical Standard #46 [UTS-46].
	It is further complicated by having a very diverse implementation of		The issue is further complicated by having a very diverse
	the requirements in RFC 5894 [RFC5894] that registry operators to		implementations of the requirements in RFC 5894 [RFC5894] that
	based on the IDNA2008 specification create additional rules for what		registry operators to based on the IDNA2008 specification create
	code points are allowed to be used for registration.		additional rules for what code points are allowed to be used for
			registration.
	In practice, Unicode Consortium set a maximum set of code points by		In practice, the Unicode Consortium set a maximum set of code points
	assiging code points in the Unicode Standard. The IDNA2008 rules		by assigning code points in the Unicode Standard. The IDNA2008 rules
	based on the Unicode Standard create a subset of these by assiging		based on the Unicode Standard create a subset of these by assigning
	PVALID derived property value to them. The registries (and others		the PVALID derived property value to them. Registries (and others
	dealing with Internationalized Domain Names) should then create an		dealing with Internationalized Domain Names) are supposed to create
	even smaller subset that ultimately is the set of code points that		an even smaller subset that ultimately is the set of code points that
	can be used.		can be used in a particular registry.
	It is also the case that when these subsets are calculated it is		There is further recommendation to be conservative when these subsets
	recommended to be conservative and use the inclusion principle, as		are calculated and to use the inclusion principle; this is explained
	explained in SAC-084 [SAC-084] and RFC 6912 [RFC6912].		in SAC-084 [SAC-084] and RFC 6912 [RFC6912].
	The complicated situation with deployment of IDNA2008 is discussed		The complicated situation with deployment of IDNA2008 is discussed
	further in draft-klensin-idna-rfc5891bis		further in draft-klensin-idna-rfc5891bis
	[I-D.klensin-idna-rfc5891bis] and draft-freytag-troublesome-		[I-D.klensin-idna-rfc5891bis] and draft-freytag-troublesome-
	characters [I-D.freytag-troublesome-characters].		characters [I-D.freytag-troublesome-characters].
	3. Notable changes between Unicode 6.3.0 and 11.0.0		4. Notable changes between Unicode 6.3.0 and 11.0.0
	3.1. Changes to Unicode 7.0.0		4.1. Changes to Unicode 7.0.0
	The character ARABIC LETTER BEH WITH HAMZA ABOVE U+08A1 was		The character ARABIC LETTER BEH WITH HAMZA ABOVE U+08A1 was
	introduced in Unicode 7.0.0. This was discussed in the IETF		introduced in Unicode 7.0.0. This was discussed in the IETF
	extensively and IAB in their statement [IAB] requesting the IETF to		extensively and IAB in their statement [IAB] requesting the IETF to
	investigate the issue and specifically IAB stated:		investigate the issue and specifically IAB stated:
	On the same precautionary principle, the IAB recommends that the		On the same precautionary principle, the IAB recommends that the
	Internationalized Domain Names for Applications (IDNA) Parameters		Internationalized Domain Names for Applications (IDNA) Parameters
	registry (http://www.iana.org/assignments/idna-tables/) not be		registry (http://www.iana.org/assignments/idna-tables/) not be
	updated to Unicode 7.0.0 until the IETF has consensus on a		updated to Unicode 7.0.0 until the IETF has consensus on a
	solution to this problem.		solution to this problem.
	The discussion in the IETF concluded that although it is possible to		The discussion in the IETF concluded that although it is possible to
	create "the same" character in multiple ways, the issue with U+08A1		create "the same" character in multiple ways, the issue with U+08A1
	is not unique. In the case of U+08A1, it can be represented with the		is not unique. In the case of U+08A1, it can be represented with the
	sequence ARABIC LETTER BEH (U+0628) and ARABIC HAMZA ABOVE (U+0654).		sequence ARABIC LETTER BEH (U+0628) and ARABIC HAMZA ABOVE (U+0654).
	Just like LATIN SMALL LETTER A WITH DIAERESIS (U+00E4) can be		Just like LATIN SMALL LETTER A WITH DIAERESIS (U+00E4) can be
	represented via the sequence LATIN SMALL LETTER A (U+0061), and		represented via the sequence LATIN SMALL LETTER A (U+0061), and
	COMBINING DIAERESIS (U+0308). One difference between these		COMBINING DIAERESIS (U+0308). One difference between these sequences
	sequencues is how it is treated in the normalization forms specified		is how they are treated in the normalization forms specified by the
	by the Unicode Consoritum.		Unicode Consortium.
	As specified in in draft-freytag-troublesome-characters		As U+08A1 is discussed in draft-freytag-troublesome-characters
	[I-D.freytag-troublesome-characters] it is not recommended to accept		[I-D.freytag-troublesome-characters] and elsewhere, regardless of
	U+08A1 in the repertoir of characters permissable for registration		whether that discussion end in recommending including the code point
	and because of this it is accepted to allow the code point to have a		in the repertoire of characters permissable for registration or not,
	derived property value of PVALID.		it is acceptable to allow the code point to have a derived property
			value of PVALID.
	3.2. Changes to Unicode 11.0.0		4.2. Changes to Unicode 11.0.0
	In version 11.0.0 of the Unicode Standard have included a number of		The Unicode Standard Version 11.0.0 [Unicode-11.0.0] have included a
	changes [Changes-11.0.0], specifically to UnicodeData.txt:		number of changes [Changes-11.0.0] from version 10.0.0, specifically
			to UnicodeData.txt:
	o Entries were added for the 684 new characters, including letters,		o Entries were added for the 684 new characters, including letters,
	combining marks, digits, symbols, and punctuation marks.		combining marks, digits, symbols, and punctuation marks.
	o Georgian letters in the ranges U+10D0..U+10FA, U+10FD..U+10FF were		o Georgian letters in the ranges U+10D0..U+10FA, U+10FD..U+10FF were
	changed from Lo to Ll, to reflect their status as the lowercase of		changed from Lo to Ll, to reflect their status as the lowercase of
	new Georgian case pairs. Case mappings were also added.		new Georgian case pairs. Case mappings were also added.
	o U+111C9 SHARADA SANDHI MARK was changed from Po to Mn, and from		o U+111C9 SHARADA SANDHI MARK was changed from Po to Mn, and from
	bc=L to bc=NSM.		bc=L to bc=NSM.
	skipping to change at page 6, line 34 ¶		skipping to change at page 6, line 47 ¶
	o U+29A1 SPHERICAL ANGLE OPENING UP was changed to Bidi_M=N.		o U+29A1 SPHERICAL ANGLE OPENING UP was changed to Bidi_M=N.
	These changes to the Unicode Standard have the following implications		These changes to the Unicode Standard have the following implications
	for these code points:		for these code points:
	o The newly assigned 684 characters are to have a derived property		o The newly assigned 684 characters are to have a derived property
	value as of a result of applying the IDNA2008 algorithm.		value as of a result of applying the IDNA2008 algorithm.
	o The Georgian letters in the ranges U+10D0..U+10FA and		o The Georgian letters in the ranges U+10D0..U+10FA and
	U+10FD..U+10FF earlier had derived property value PVALID and		U+10FD..U+10FF have existed since before IDNA2008 was created.
	continues to have so even if some properties changed.		Applying the IDNA2008 algorithm to the code points did assign the
			derived property value PVALID and that value is unchanged even if
			the underlying Unicode properties have changed.
	o The U+111C9 SHARADA SANDHI MARK was added to the Unicode 8.0.0		o The U+111C9 SHARADA SANDHI MARK was added to Unicode 8.0.0
	[Unicode-8.0.0]. Applying the IDNA2008 algorithm to the code		[Unicode-8.0.0]. Applying the IDNA2008 algorithm to the code
	point did assign the derived property value DISALLOWED. The		point did assign the derived property value DISALLOWED. The
	changes in properties in the Unicode Standard in version 11.0.0		changes in the underlying properties in the Unicode Standard
	make the derived property value change to PVALID which according		Version 11.0.0 [Unicode-11.0.0] make the derived property value
	to discussions in IETF is acceptable.		change to PVALID which is an acceptable change.
	o The characters U+11A07 ZANABAZAR SQUARE VOWEL SIGN AI and U+11A08		o The characters U+11A07 ZANABAZAR SQUARE VOWEL SIGN AI and U+11A08
	ZANABZAR SQUARE VOWEL SIGN AU were added to Unicode 10.0.0		ZANABZAR SQUARE VOWEL SIGN AU were added to Unicode 10.0.0
	[Unicode-10.0.0] and applying IDNA2008 algorith to their		[Unicode-10.0.0]. Applying the IDNA2008 algorithm to the code
	properties gave derived property value PVALID. This does not		points did assign the derived property value PVALID and that value
	change even if some properties changes in the Unicode Standard for		is unchanged even if the underlying Unicode properties have
	the code points in question for Unicode version 11.0.0.		changed.
	o U+29A1 SPHERICAL ANGLE OPENING UP have existed since before		o U+29A1 SPHERICAL ANGLE OPENING UP have existed since before
	IDNA2008 was created. It have always had the derived property		IDNA2008 was created. Applying the IDNA2008 algorithm to the code
	value be DISALLOWED and it stays the same although the properties		point did assign the derived property value PVALID and that value
	changes in Unicode 11.0.0.		is unchanged even if the underlying Unicode properties have
			changed.
	4. Conclusion		5. Conclusion
	Given the changes laid out in Section 3 the derived property values		Given the changes laid out in Section 4 the derived property values
	MUST be calculated according to the IDNA2008 specification for		MUST be calculated according to the IDNA2008 specification for
	Unicode Version 11.0.0. The changes in code points, implications to		Unicode Version 11.0.0 [Unicode-11.0.0]. The changes in code points,
	normalization and changes in derived property values are acceptable.		implications to normalization and changes in derived property values
			are acceptable.
	All registries and others SHOULD calculate a repertoir as explained		All registries and others SHOULD calculate a repertoir as explained
	in draft-freytag-troublesome-characters		in draft-freytag-troublesome-characters
	[I-D.freytag-troublesome-characters] and draft-klensin-idna-		[I-D.freytag-troublesome-characters] and draft-klensin-idna-
	rfc5891bis [I-D.klensin-idna-rfc5891bis] using the conservatism and		rfc5891bis [I-D.klensin-idna-rfc5891bis] using the conservatism and
	inclusive principles as laid out in SAC-084 [SAC-084].		inclusive principles as laid out in SAC-084 [SAC-084].
	5. IANA Considerations		6. IANA Considerations
	IANA is requested to update the registry of derived property values		IANA is requested to update the registry of derived property values
	after validation with the Appointed Expert that the derived values		after validation with the Appointed Expert that the derived values
	are calculated correctly.		are calculated correctly.
	6. Security Considerations		7. Security Considerations
	Not following the recommendations regarding explicitly deciding what		Not following the recommendations regarding explicitly deciding what
	subset of the by IDNA2008 algorith applied to current Unicode version		subset of the by IDNA2008 algorith applied to current Unicode version
	should be permissable can lead to various security issues related to		should be permissable can lead to various security issues related to
	specifically confusability, and that way various phishing attacks.		specifically confusability, and that way various phishing attacks.
	7. Acknowledgements		8. Acknowledgements
	Thanks to John Klensin, Asmus Freytag, Andrew Sullivan and Michel		Thanks to John Klensin, Asmus Freytag, Andrew Sullivan and Michel
	Suignard for input to this document.		Suignard for input to this document.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[IAB] Internet Architecture Board, "IAB Statement on Identifiers		[IAB] Internet Architecture Board, "IAB Statement on Identifiers
	and Unicode 7.0.0", IAB Statement on Identifiers and		and Unicode 7.0.0", IAB Statement on Identifiers and
	Unicode 7.0.0		Unicode 7.0.0
	https://www.iab.org/documents/correspondence-reports-		https://www.iab.org/documents/correspondence-reports-
	documents/2015-2/iab-statement-on-identifiers-and-unicode-		documents/2015-2/iab-statement-on-identifiers-and-unicode-
	7-0-0/, January 2015.		7-0-0/, January 2015.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	skipping to change at page 8, line 40 ¶		skipping to change at page 9, line 10 ¶
	[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts		[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
	for Internationalized Domain Names for Applications		for Internationalized Domain Names for Applications
	(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,		(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
	<https://www.rfc-editor.org/info/rfc5893>.		<https://www.rfc-editor.org/info/rfc5893>.
	[RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code		[RFC6452] Faltstrom, P., Ed. and P. Hoffman, Ed., "The Unicode Code
	Points and Internationalized Domain Names for Applications		Points and Internationalized Domain Names for Applications
	(IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452,		(IDNA) - Unicode 6.0", RFC 6452, DOI 10.17487/RFC6452,
	November 2011, <https://www.rfc-editor.org/info/rfc6452>.		November 2011, <https://www.rfc-editor.org/info/rfc6452>.
	8.2. Non-normative references		9.2. Non-normative references
	[Changes-11.0.0]		[Changes-11.0.0]
	The Unicode Consortium, "Unicode Standard Annex #44",		The Unicode Consortium, "Unicode Standard Annex #44",
	Unicode Standard Annex #44, UNICODE CHARACTER DATABASE,		Unicode Standard Annex #44, UNICODE CHARACTER DATABASE,
	Change History https://www.unicode.org/reports/tr44/		Change History https://www.unicode.org/reports/tr44/
	tr44-21d4.html#Change_History, May 2018.		tr44-21d4.html#Change_History, May 2018.
	[I-D.freytag-troublesome-characters]		[I-D.freytag-troublesome-characters]
	Freytag, A., Klensin, J., and A. Sullivan, "Those		Freytag, A., Klensin, J., and A. Sullivan, "Those
	Troublesome Characters: A Registry of Unicode Code Points		Troublesome Characters: A Registry of Unicode Code Points
End of changes. 36 change blocks.
	88 lines changed or deleted		104 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/