[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                        D. Cridland
Internet-Draft                                          Surevine Limited
Intended status: Standards Track                           June 10, 2014
Expires: December 12, 2014


  Here Lies Extensible Messaging and Presence Protocol (XMPP) Session
                             Establishment
                     draft-cridland-xmpp-session-01

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 12, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Cridland                Expires December 12, 2014               [Page 1]


Internet-Draft                XMPP Session                     June 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The Session Establishment Tombstone . . . . . . . . . . . . .   3
     2.1.  Feature Advertisement . . . . . . . . . . . . . . . . . .   3
     2.2.  Session Establishment Request . . . . . . . . . . . . . .   4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  XML Namespace Name for Session Data . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Within this specification, we refer to "Old" clients and servers
   meaning those conforming to the [RFC3921] 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 [RFC6121] 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.








Cridland                Expires December 12, 2014               [Page 2]


Internet-Draft                XMPP Session                     June 2014


2.  The Session Establishment Tombstone

   This specification formalizes the <optional/> marker and explicitly
   defines the Session Establishment request itself as a no-op.

2.1.  Feature Advertisement

   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.

   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
   <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.

   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.








Cridland                Expires December 12, 2014               [Page 3]


Internet-Draft                XMPP Session                     June 2014


2.2.  Session Establishment Request

   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:

   Step 1: Client requests session with server:

   <iq to='example.com' type='set' id=sess_1'>
     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
   </iq>


   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:

   Step 2: Server informs client of success:

   <iq from='example.com' type='result' id='sess_1'/>


   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.

3.  Security Considerations

   This document defines, in effect, a no-op, and therefore it is
   thought not to have any security impact.

4.  IANA Considerations

   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:

4.1.  XML Namespace Name for Session Data

   A URN sub-namespace for session-related data in the Extensible
   Messaging and Presence Protocol (XMPP) is defined as follows.  (This




Cridland                Expires December 12, 2014               [Page 4]


Internet-Draft                XMPP Session                     June 2014


   namespace name aheres to the format defined in The IETF XML Registry
   [RFC3688].)

      URI: urn:ietf:params:xml:ns:xmpp-session
      Specification: This document
      Description: Here lies the XML namespace name for session-related
         data in the Extensible Messaging and Presence Protocol (XMPP),
         as defined in "this document".
      Registrant Contact: IETF, XMPP Working Group, <xmpp@ietf.org>

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
   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.

6.  References

6.1.  Normative References

   [RFC6121]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence", RFC
              6121, March 2011.

6.2.  Informative References

   [RFC3921]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence", RFC
              3921, October 2004.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

Author's Address








Cridland                Expires December 12, 2014               [Page 5]


Internet-Draft                XMPP Session                     June 2014


   Dave Cridland
   Surevine Limited
   PO Box 1136
   Guildford, Surrey  GU1 9ND
   UK

   Email: dave.cridland@surevine.com












































Cridland                Expires December 12, 2014               [Page 6]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/