< draft-cridland-xmpp-session-00.txt		draft-cridland-xmpp-session-01.txt >
	Network Working Group D. Cridland		Network Working Group D. Cridland
	Internet-Draft Surevine Limited		Internet-Draft Surevine Limited
	Intended status: Standards Track June 9, 2014		Intended status: Standards Track June 10, 2014
	Expires: December 11, 2014		Expires: December 12, 2014
	Here Lies Extensible Messaging and Presence Protocol (XMPP) Session		Here Lies Extensible Messaging and Presence Protocol (XMPP) Session
	Establishment		Establishment
	draft-cridland-xmpp-session-00		draft-cridland-xmpp-session-01
	Abstract		Abstract
	The Extensible Messaging and Presence Protocol (XMPP) historically		The Extensible Messaging and Presence Protocol (XMPP) historically
	had a Session Establishment request defined in RFC 3921 which clients		had a Session Establishment request defined in RFC 3921 which clients
	were required to perform at the beginning of a session. RFC 6121		were required to perform at the beginning of a session. RFC 6121
	dropped this entirely. This specification reinstates it as an		dropped this entirely. This specification reinstates it as an
	optional no-op to aid backwards compability, matching commonly		optional no-op to aid backwards compability, matching commonly
	deployed workarounds.		deployed workarounds.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 December 11, 2014.		This Internet-Draft will expire on December 12, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	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. The Session Establishment Tombstone . . . . . . . . . . . . . 3		2. The Session Establishment Tombstone . . . . . . . . . . . . . 3
	2.1. Feature Advertisement . . . . . . . . . . . . . . . . . . 3		2.1. Feature Advertisement . . . . . . . . . . . . . . . . . . 3
	2.2. Session Establishment Request . . . . . . . . . . . . . . 3		2.2. Session Establishment Request . . . . . . . . . . . . . . 4
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 4		3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	4.1. XML Namespace Name for Session Data . . . . . . . . . . . 4		4.1. XML Namespace Name for Session Data . . . . . . . . . . . 4
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6.1. Normative References . . . . . . . . . . . . . . . . . . 4		6.1. Normative References . . . . . . . . . . . . . . . . . . 5
	6.2. Informative References . . . . . . . . . . . . . . . . . 4		6.2. Informative References . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	Within this specification, we refer to "Old" clients and servers		Within this specification, we refer to "Old" clients and servers
	meaning those conforming to the [RFC3921] particularly with respect		meaning those conforming to the [RFC3921] particularly with respect
	to its Section 3 (Session Establishment). We refer to "New" clients		to its Section 3 (Session Establishment). We refer to "New" clients
	and servers meaning those conforming to the newer definition of		and servers meaning those conforming to the newer definition of
	Session Establishment within this document.		Session Establishment within this document.
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	This specification formalizes the <optional/> marker and explicitly		This specification formalizes the <optional/> marker and explicitly
	defines the Session Establishment request itself as a no-op.		defines the Session Establishment request itself as a no-op.
	2.1. Feature Advertisement		2.1. Feature Advertisement
	Session Establishment SHALL be advertised within the Stream Features		Session Establishment SHALL be advertised within the Stream Features
	element as an element of local name "session", qualified by the		element as an element of local name "session", qualified by the
	"urn:ietf:params:xml:ns:xmpp-session" XML namespace. This element		"urn:ietf:params:xml:ns:xmpp-session" XML namespace. This element
	MUST contain a child element within the same namespace with local		MUST contain a child element within the same namespace with local
	name "optional"i, known as the "<optional/> marker. Clients SHALL		name "optional", known as the "<optional/> marker". Clients MAY
	ignore such advertisements.		ignore such advertisements, and are encouraged to do so.
			Advertisement 1: New server
			<stream:features>
			<session xmlns='urn:ietf:params:xml:ns:xmpp-session'>
			<optional/>
			</session>
			</stream:features>
	If a client sees an advertisement which does not contain the		If a client sees an advertisement which does not contain the
	<optional/> marker, however, this indicates an Old server, and it		<optional/> marker, however, this indicates an Old server, and it
	MUST perform Session Establishment as detailed in the next section.		MUST perform Session Establishment as detailed in the next section.
	Also, note that Old Clients will also perform the protocol despite		Also, note that Old Clients will also perform the protocol despite
	the existence of the <optional/> marker.		the existence of the <optional/> marker.
			Advertisement 2: Old server
			<stream:features>
			<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
			</stream:features>
			Note the lack of >optional/> marker, meaning the feature is mandatory
			to negotiate.
			Note that the <optional/> element defined by this specification only
			applies to the Session Establishment feature, and only exists within
			this namespace. It does not form part of a general mechanism.
	2.2. Session Establishment Request		2.2. Session Establishment Request
	A Old client connecting to a New server, or a New client against a		A Old client connecting to a New server, or a New client against a
	Old server, issues a Session Establishment request. This consists of		Old server, issues a Session Establishment request. This consists of
	an IQ stanza od type "set" containing an empty <session/> child		an IQ stanza of type "set" containing an empty <session/> child
	element qualified by the "urn:ietf:params:xml:ns:xmpp-session"		element qualified by the "urn:ietf:params:xml:ns:xmpp-session"
	namespace:		namespace:
	Step 1: Client requests session with server:		Step 1: Client requests session with server:
	<iq to='example.com' type='set' id=sess_1'>		<iq to='example.com' type='set' id=sess_1'>
	<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>		<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
	</iq>		</iq>
	A New server MUST treat this as a no-op; that is, it MUST NOT perform		A New server MUST treat this as a no-op; that is, it MUST NOT perform
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 31 ¶
	behaviour allowed and required by this specification is the empty		behaviour allowed and required by this specification is the empty
	result:		result:
	Step 2: Server informs client of success:		Step 2: Server informs client of success:
	<iq from='example.com' type='result' id='sess_1'/>		<iq from='example.com' type='result' id='sess_1'/>
	Note that this specification does not allow any error to be generated		Note that this specification does not allow any error to be generated
	at this point in response to a syntactically valid request.		at this point in response to a syntactically valid request.
			It is important to note that there is no value in performing this
			request, and New clients are expected to elide the request when the
			<optional/> marker is present.
	3. Security Considerations		3. Security Considerations
	This document defines, in effect, a no-op, and therefore it is		This document defines, in effect, a no-op, and therefore it is
	thought not to have any security impact.		thought not to have any security impact.
	4. IANA Considerations		4. IANA Considerations
	This document supercedes the original definition of the XML namespace		This document supercedes the original definition of the XML namespace
	defined in RFC 3921, therefore the IANA is requested to update the		defined in RFC 3921, therefore the IANA is requested to update the
	registry as follows:		registry as follows:
	4.1. XML Namespace Name for Session Data		4.1. XML Namespace Name for Session Data
	A URN sub-namespace for session-related data in the Extensible		A URN sub-namespace for session-related data in the Extensible
	Messaging and Presence Protocol (XMPP) is defined as follows. (This		Messaging and Presence Protocol (XMPP) is defined as follows. (This
	namespace name aheres to the format defined in The IETF XML Registry		namespace name aheres to the format defined in The IETF XML Registry
	[RFC3688].)		[RFC3688].)
	URI: urn:ietf:params:xml:ns:xmpp-session		URI: urn:ietf:params:xml:ns:xmpp-session
	Specification: This document		Specification: This document
	Description: Here lies the XML namespace name for session-related data		Description: Here lies the XML namespace name for session-related
	in the Extensible Messaging and Presence Protocol (XMPP), as defined		data in the Extensible Messaging and Presence Protocol (XMPP),
	in "this document".		as defined in "this document".
	Registrant Contact: IETF, XMPP Working Group, <xmpp@ietf.org>		Registrant Contact: IETF, XMPP Working Group, <xmpp@ietf.org>
	5. Acknowledgements		5. Acknowledgements
			The impetus for documenting this came from Christian Schudt's
			proposal to remove XMPP Session support from Openfire, which spawned
			a discussion within the XSF about the status quo.
	The examples and some of the text were lifted from RFC 3921 by Peter		The examples and some of the text were lifted from RFC 3921 by Peter
	Saint-Andre. The optional marker was proposed some time ago and was		Saint-Andre. The optional marker itself was proposed during the
	implemented by Curtis King and Waqas Hussein amongst others.		revision of RFC 3921 some time ago, and was implemented by Curtis
			King and Waqas Hussein amongst others.
			Waqas Hussein, Curtis King, Ralph Meijer, Florian Schmaus, Kevin
			Smith, and Lance Stout all gave valuable comments both for and
			against, helping to shape this document.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence		[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
	Protocol (XMPP): Instant Messaging and Presence", RFC		Protocol (XMPP): Instant Messaging and Presence", RFC
	6121, March 2011.		6121, March 2011.
	6.2. Informative References		6.2. Informative References
End of changes. 12 change blocks.
	20 lines changed or deleted		54 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/