Here Lies Extensible Messaging and Presence Protocol (XMPP) Session EstablishmentSurevine LimitedPO Box 1136GuildfordSurreyGU1 9NDUKdave.cridland@surevine.com
Applications
The Extensible Messaging and Presence Protocol (XMPP) historically had a Session
Establishment request defined in RFC 3921 which clients were required to perform at the beginning of a session. RFC 6121 dropped this entirely. This specification reinstates it as an optional no-op to aid backwards compability, matching commonly deployed workarounds.
Within this specification, we refer to "Old" clients and servers meaning those conforming to the particularly with respect to its Section 3 (Session Establishment). We refer to "New" clients and servers meaning those conforming to the newer definition of Session Establishment within this document.While removed Session Establishment entirely from XMPP, there exist deployed clients which expect the feature to be advertised, and will refuse to proceed if it is not. Similarly, where the feature is advertised, clients were advised to use it, as deployed Old servers may require it.This has led to a situation where although deprecated by RFC 6121, the status quo is unchanged.A number of servers advertise it with a discussed (but not standardized) <optional/> subelement to the feature, which clients can use as a hint that they may elide Session Establishment without penalty.This document formalizes this and acts as the tombstone for Session Establishment, deprecating it in a manner where one can see where it used to be.This specification formalizes the <optional/> marker and explicitly defines the Session Establishment request itself as a no-op.Session Establishment SHALL be advertised within the Stream Features element as an element of local name "session", qualified by the "urn:ietf:params:xml:ns:xmpp-session" XML namespace. This element MUST contain a child element within the same namespace with local name "optional", known as the "<optional/> marker". Clients MAY ignore such advertisements, and are encouraged to do so.If a client sees an advertisement which does not contain the <optional/> marker, however, this indicates an Old server, and it MUST perform Session Establishment as detailed in the next section.Also, note that Old Clients will also perform the protocol despite the existence of the <optional/> marker.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.A Old client connecting to a New server, or a New client against a Old server, issues a Session Establishment request. This consists of an IQ stanza of type "set" containing an empty <session/> child element qualified by the "urn:ietf:params:xml:ns:xmpp-session" namespace:A New server MUST treat this as a no-op; that is, it MUST NOT perform any special processing which has any effect on the session. The only behaviour allowed and required by this specification is the empty result:Note that this specification does not allow any error to be generated 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.This document defines, in effect, a no-op, and therefore it is thought not to have any security impact.This document supercedes the original definition of the XML namespace defined in RFC 3921, therefore the IANA is requested to update the registry as follows:A URN sub-namespace for session-related data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name aheres to the format defined in The IETF XML Registry .)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 Saint-Andre. The optional marker itself was proposed during the 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.