< draft-ietf-xmpp-6122bis-19.txt		draft-ietf-xmpp-6122bis-20.txt >
	XMPP P. Saint-Andre		XMPP P. Saint-Andre
	Internet-Draft &yet		Internet-Draft &yet
	Obsoletes: 6122 (if approved) March 9, 2015		Obsoletes: 6122 (if approved) March 23, 2015
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 10, 2015		Expires: September 24, 2015
	Extensible Messaging and Presence Protocol (XMPP): Address Format		Extensible Messaging and Presence Protocol (XMPP): Address Format
	draft-ietf-xmpp-6122bis-19		draft-ietf-xmpp-6122bis-20
	Abstract		Abstract
	This document defines the address format for the Extensible Messaging		This document defines the address format for the Extensible Messaging
	and Presence Protocol (XMPP), including support for code points		and Presence Protocol (XMPP), including support for code points
	outside the ASCII range. This document obsoletes RFC 6122.		outside the ASCII range. This document obsoletes RFC 6122.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 September 10, 2015.		This Internet-Draft will expire on September 24, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 7, line 40 ¶		skipping to change at page 7, line 40 ¶
	The localpart of a JID is an instance of the UsernameCaseMapped		The localpart of a JID is an instance of the UsernameCaseMapped
	profile of the PRECIS IdentifierClass, which is specified in		profile of the PRECIS IdentifierClass, which is specified in
	[I-D.ietf-precis-saslprepbis]. The rules and considerations provided		[I-D.ietf-precis-saslprepbis]. The rules and considerations provided
	in that specification MUST be applied to XMPP localparts.		in that specification MUST be applied to XMPP localparts.
	Implementation Note: XMPP uses the Simple Authentication and		Implementation Note: XMPP uses the Simple Authentication and
	Security Layer (SASL) [RFC4422] for authentication. At the time		Security Layer (SASL) [RFC4422] for authentication. At the time
	of this writing, some SASL mechanisms use SASLprep [RFC4013] for		of this writing, some SASL mechanisms use SASLprep [RFC4013] for
	handling of usernames and passwords; in the future these SASL		handling of usernames and passwords; in the future these SASL
	mechanisms will likely transition to the use of PRECIS-based		mechanisms will likely transition to the use of PRECIS-based
	handling rules as specified in [I-D.ietf-precis-saslprepbis].		handling rules as specified in [I-D.ietf-precis-saslprepbis]. For
			a detailed discussion about the implications of that transition
			(including the potential need to modify or remove certain
			characters in the underlying account database), see both
			Section 6.1 and Appendix A of [I-D.ietf-precis-saslprepbis].
	3.3.1. Further Excluded Characters		3.3.1. Further Excluded Characters
	In XMPP, the following characters are explicitly disallowed in XMPP		In XMPP, the following characters are explicitly disallowed in XMPP
	localparts even though they are allowed by the IdentifierClass base		localparts even though they are allowed by the IdentifierClass base
	class and the UsernameCaseMapped profile:		class and the UsernameCaseMapped profile:
	U+0022 (QUOTATION MARK), i.e., "		U+0022 (QUOTATION MARK), i.e., "
	U+0026 (AMPERSAND), i.e., &		U+0026 (AMPERSAND), i.e., &
	U+0027 (APOSTROPHE), i.e., '		U+0027 (APOSTROPHE), i.e., '
	U+002F (SOLIDUS), i.e., /		U+002F (SOLIDUS), i.e., /
	U+003A (COLON), i.e., :		U+003A (COLON), i.e., :
	U+003C (LESS-THAN SIGN), i.e., <		U+003C (LESS-THAN SIGN), i.e., <
	U+003E (GREATER-THAN SIGN), i.e., >		U+003E (GREATER-THAN SIGN), i.e., >
	U+0040 (COMMERCIAL AT), i.e., @		U+0040 (COMMERCIAL AT), i.e., @
	skipping to change at page 14, line 17 ¶		skipping to change at page 14, line 17 ¶
	A server is not responsible for enforcing the rules when the protocol		A server is not responsible for enforcing the rules when the protocol
	elements are intended for communication among other entities,		elements are intended for communication among other entities,
	typically within the payload of a stanza that the server is merely		typically within the payload of a stanza that the server is merely
	routing to another domain or delivering to a local entity. Two		routing to another domain or delivering to a local entity. Two
	examples are the 'initiator' attribute in the Jingle extension		examples are the 'initiator' attribute in the Jingle extension
	[XEP-0166] (which is a JID slot used for client-to-client		[XEP-0166] (which is a JID slot used for client-to-client
	coordination of multimedia sessions) and the 'nick' attribute in the		coordination of multimedia sessions) and the 'nick' attribute in the
	Multi-User Chat extension [XEP-0045] (which is a resourcepart slot		Multi-User Chat extension [XEP-0045] (which is a resourcepart slot
	used for administrative purposes in the context of XMPP chatrooms).		used for administrative purposes in the context of XMPP chatrooms).
	In such cases, clients SHOULD enforce the rules themselves and not		In such cases, the entities involved SHOULD enforce the rules
	depend on the server to do so, and client implementers need to		themselves and not depend on the server to do so, and client
	understand that not enforcing the rules can lead to a degraded user		implementers need to understand that not enforcing the rules can lead
	experience or to security vulnerabilities. However, when an add-on		to a degraded user experience or to security vulnerabilities.
	service (e.g., a multi-user chat service) handles a stanza directly,		However, when an add-on service (e.g., a multi-user chat service)
	it ought to enforce the rules as well, as defined in the relevant		handles a stanza directly, it ought to enforce the rules as well, as
	specification for that type of service.		defined in the relevant specification for that type of service.
	This document does not provide an exhaustive list of JID slots,		This document does not provide an exhaustive list of JID slots,
	localpart slots, or resourcepart slots. However, implementers of		localpart slots, or resourcepart slots. However, implementers of
	core XMPP servers are advised to consider as JID slots at least the		core XMPP servers are advised to consider as JID slots at least the
	following elements and attributes when they are handled directly or		following elements and attributes when they are handled directly or
	used for purposes of routing to another domain or delivering to a		used for purposes of routing to another domain or delivering to a
	local entity:		local entity:
	o The 'from' and 'to' stream attributes and the 'from' and 'to'		o The 'from' and 'to' stream attributes and the 'from' and 'to'
	stanza attributes [RFC6120].		stanza attributes [RFC6120].
	skipping to change at page 18, line 31 ¶		skipping to change at page 18, line 31 ¶
	implement consistent policies regarding the registration, storage,		implement consistent policies regarding the registration, storage,
	and presentation of visually similar characters in XMPP systems. In		and presentation of visually similar characters in XMPP systems. In
	particular, service providers and software implementers are strongly		particular, service providers and software implementers are strongly
	encouraged to apply the policies recommended in		encouraged to apply the policies recommended in
	[I-D.ietf-precis-framework].		[I-D.ietf-precis-framework].
	8. Conformance Requirements		8. Conformance Requirements
	This section describes a protocol feature set that summarizes the		This section describes a protocol feature set that summarizes the
	conformance requirements of this specification (similar feature sets		conformance requirements of this specification (similar feature sets
	are provided for XMPP in [RFC6120] and [RFC6121]). This feature set		are provided for XMPP in [RFC6120] and [RFC6121]). The summary is
			purely informational and the conformance keywords of [RFC2119] as
			used here are intended only to briefly describe the referenced
			normative text from the body of this specification. This feature set
	is appropriate for use in software certification, interoperability		is appropriate for use in software certification, interoperability
	testing, and implementation reports. For each feature, this section		testing, and implementation reports. For each feature, this section
	provides the following information:		provides the following information:
	o A human-readable name		o A human-readable name
	o An informational description		o An informational description
	o A reference to the particular section of this document that		o A reference to the particular section of this document that
	normatively defines the feature		normatively defines the feature
	skipping to change at page 25, line 13 ¶		skipping to change at page 25, line 13 ¶
	use of NFKC).		use of NFKC).
	o Specified the use of Unicode Normalization Form C (instead of		o Specified the use of Unicode Normalization Form C (instead of
	Unicode Normalization Form KC as specified in the Nodeprep and		Unicode Normalization Form KC as specified in the Nodeprep and
	Resourceprep profiles of Stringprep).		Resourceprep profiles of Stringprep).
	o Specified that servers must enforce the address formatting rules.		o Specified that servers must enforce the address formatting rules.
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	Thanks to Dave Cridland, Miguel Garcia, Joe Hildebrand, Jonathan		Thanks to Ben Campbell, Dave Cridland, Miguel Garcia, Joe Hildebrand,
	Lennox, Matt Miller, and Florian Zeitz for their feedback.		Jonathan Lennox, Matt Miller, and Florian Zeitz for their feedback.
	Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for		Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
	employing him during his work on earlier versions of this document.		employing him during his work on earlier versions of this document.
	Author's Address		Author's Address
	Peter Saint-Andre		Peter Saint-Andre
	&yet		&yet
	Email: peter@andyet.com		Email: peter@andyet.com
End of changes. 10 change blocks.
	16 lines changed or deleted		23 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/