xeps/xep-0386.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Bind 2.0</title>
  <abstract>This specification provides a single-request replacement for several activities an XMPP client needs to do at startup.</abstract>
  &LEGALNOTICE;
  <number>0386</number>
  <status>Experimental</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XMPP IM</spec>
    <spec>XEP-0313</spec>
    <spec>XEP-0280</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>bind2</shortname>
  &ksmithisode;
  <revision>
    <version>0.1.0</version>
    <date>2017-02-08</date>
    <initials>XEP Editor: ssw</initials>
    <remark><p>First draft accepted by the XMPP Council.</p></remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='intro'>
  <p>As XMPP has grown more feature-rich over time, more steps have been introduced that clients are likely to perform at startup, e.g. resource binding, archive synchronisation, enabling Carbons. Some of these introduce race conditions - e.g. if a client synchronises the archive before enabling Carbons, it can miss stanzas sent between these events, or if it enables Carbons before synchronising the archive it can receive duplicate messages. It may also cause duplicate messages by combining archive synchronisation and receipt of offline messages, or by receipt of messages addressed to the full JID between resource binding and archive synchronisation. This document provides a mechanism for atomically performing these operations to avoid these race conditions. It also provides information to a client that is generally useful about the state of the archive.</p>
  <p>There have been other (not-yet documented) suggestions of further enhancements to the stream startup process, and it is possible that in the future some protocol here may be reframed in terms of such new facilities, but the core premise of the XEP (that these features are needed, and need enabling together) remains. It may be desirable to make the enabling of features extensible, such that the client can request which features are needed, together, but the current approach should serve as a suitable basis for discussion.</p>
  <p>The returning of unread message state to the client relies on the archive having these data, which is a topic for another specification.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
  <ul>
    <li>Allow MAM synchronisation and Carbons enabling without a race condition leading to missed or duplicated stanzas</li>
    <li>Avoid offline messages being received by clients using the MAM archive for message retrieval</li>
    <li>Allow clients to know which messages are unread in the archive, providing a cross-client alternative to offline messages</li>
    <li>Avoid clients receiving 'live' messages until they have synchronised their state from the server (to avoid double-receipt of messages, one from the archive one live)</li>
  </ul>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
  <section2 topic='Discovering support'>
    <p>A client does not advertise support for bind 2.0. If a server supports bind 2.0, it MUST advertise this in the stream features with an feature named 'bind' in the namespace 'urn:xmpp:bind2:0'.</p>
    <example caption='Server advertises support in stream features'><![CDATA[
<stream:features>
  <bind xmlns='urn:xmpp:bind2:0'/>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
  <sm xmlns='urn:xmpp:sm:3'/>
</stream:features>
]]></example>
  </section2>

  <section2 topic='Performing the bind'>
    <p>After authentication, a client performs a bind 2.0 by sending an element 'bind' in the samespace 'urn:xmpp:bind2:0'. (Note: this gets rid of manual resource binding altogether. For discussion on standards@)</p>
    <example caption='Client initiates a bind 2.0'><![CDATA[
<bind xmlns='urn:xmpp:bind2:0'/>
]]></example>
    <p>When it receives a bind 2.0 on an authenticated not-yet-bound session, the server MUST:</p>
    <ul>
      <li>Clear the offline messages for this user, if any, without sending them (as they will be provided by MAM).</li>
      <li>Perform resource binding to a random resource (see 6120)</li>
      <li>Work out which contacts have unread messages in the user's MAM archive, how many, and what the id of the last read message is</li>
      <li>Get the id of the newest stanza in the user's MAM archive</li>
      <li>Silently enable carbons for this session</li>
    </ul>
    <p>After processing the bind stanza, as above, the server MUST respond with an element of type 'bound' in the namespace 'urn:xmpp:bind2:0', as in the below example</p>
  <example caption='Server responds after processing the bind'><![CDATA[
<bound xmlns='urn:xmpp:bind2:0'>
  <jid>nurse@shakespeare.lit/abtet29a9fu</jid>
  <latest-id>balisoseb</latest-id>
  <unreads>
    <unread jid='romeo@shakespeare.lit' read-id='onuheuhoeu', unread-count='3'/>
    <unread jid='juliet@shakespeare.lit' read-id='koeunhth29', unread-count='43'/>
  </unreads>
</bound>
]]></example>
  </section2>

  <section2 topic='Pipelining'>
    <p>A server supporting this specification MUST allow the following initial commands to be pipelined:</p>
    <ul>
      <li>Initial client stream header</li>
      <li>SASL Authentication*</li>
      <li>Post-authentication stream header</li>
      <li>Bind 2.0</li>
    </ul>
    <p>[ * pipelining will clearly not work for multi-stage SASL mechanisms, but the initial stage MUST be capable of being pipelined after the stream header, and the post-authentication stream header MUST be able to be pipelined after the final authentication element]</p>
    <p>In this way, a client is able to (if using 'xmpps' for avoiding starttls, to be defined elsewhere), on second and subsequent login cache the presence of bind 2.0 in stream features from a previous session, and pipeline the entire stream initialisation process by sending the stream header, followed by auth, followed by a stream header, followed by a bind 2.0 in a single chunk.</p>
    <p>Note: also enable acks? discuss on standards@</p>
  </section2>
</section1>
<!--<section1 topic='Business Rules' anchor='rules'>
  <p>OPTIONAL.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
  <p>OPTIONAL.</p>
</section1>-->
<section1 topic='Security Considerations' anchor='security'>
  <p>This specification is mostly a reworking of existing protocol/features. The additional facility provided here is to provide information on the user's archive; as this facility is provided post-authentication and is only providing the user's data to the user, it doesn't introduce new security considerations.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>None.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>The urn:xmpp:bind2:0 namespace must be registered..</p>
</section1>
<!--<section1 topic='XML Schema' anchor='schema'>
  <p>REQUIRED for protocol specifications.</p>
</section1>-->
</xep>