XEP-0386: Bind 2.0

3.1 Discovering support¶

A client doesIf a server supports Bind 2, it MUST advertise this within the SASL2 <inline/> element in the stream features, with a feature named 'bind' in the namespace 'urn:xmpp:bind:0'.

Clients do not advertise support for bindBind 2.0

Bind 2 supports inline negotiation of certain features specific to a session. If aThe features supported by the server supportsfor such inline negotiation MUST be included in an <inline/> child element within the bind 2feature element.0, it MUST advertise this in the stream features with a Each feature named 'bind' in theis listed as a <feature/> child element with a 'var' attribute indicating the extension's defined service discovery feature name or namespace 'urn:xmpp:bind2:0'.

<stream:features>
  <authentication xmlns='urn:xmpp:sasl:2'>
    <mechanism>SCRAM-SHA-1</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <inline>
      <bind xmlns='urn:xmpp:bind2:0''urn:xmpp:bind:0'>
        <inline>
          <feature var="urn:xmpp:carbons:2" />
          <bind xmlnsfeature var='urn:ietf:params:xml:ns:xmpp-bind'"urn:xmpp:csi:0" />
  
          <feature var="urn:xmpp:sm:3" />
        </inline>
      </bind>
      <sm xmlns='urn:xmpp:sm:3'/>
    </inline>
  </authentication>
</stream:features>

Bind 2 is never supported without SASL2, and so servers without support for SASL2 MUST NOT advertise the feature. Servers supporting SASL2 and Bind 2 may continue to offer legacy resource binding to clients.

3.2 Performing the bind¶

After authenticationTo request resource binding, athe client performs a MUST include a <bind 2/> element, qualified by the 'urn:xmpp:bind:0' namespace, in its SASL2 <authenticate/> request.0 by sending an

The <bind/> element 'bind' in the samespace 'urn:xmpp:bind2:0'MAY contain the following child elements:

• <tag/>: This element contains a short text string that typically identifies the software the user is using, mostly useful for diagnostic purposes for users, operators and developers. This tag may be visible to other entities on the XMPP network (Note: this gets rid of manual resource binding altogethersee Security Considerations). For discussion on standards@)

Additionally, the <bind/> element MAY contain one or more child elements in other namespaces, representing features that the client requests to be automatically enabled for its new session.

<authenticate xmlns='urn:xmpp:sasl:2' mechanism='SCRAM-SHA-1'>
  <initial-response>[base64 encoded SASL data]</initial-response>
  <bind xmlns='urn:xmpp:bind2:0'/'urn:xmpp:bind:0'>
    <tag>AwesomeXMPP</tag>
  </bind>
</authenticate>

<authenticate xmlns='urn:xmpp:sasl:2' mechanism='SCRAM-SHA-1'>
  <initial-response>[base64 encoded SASL data]</initial-response>
  <bind xmlns='urn:xmpp:bind:0'>
    <tag>AwesomeXMPP</tag>
    <enable xmlns='urn:xmpp:carbons:2'/>
    <enable xmlns='urn:xmpp:sm:3'/>
    <inactive xmlns='urn:xmpp:csi:0'/>
  </bind>
</authenticate>

If the client included a <bind/> element in its SASL2 <authenticate/> then the server MUST process the bind request after authentication is successful (including any necessary subsequent SASL2 tasks), but before sending the <success/> response. Following the usual rules of SASL2, the bind request MUST NOT be processed (i.e. it should be ignored) if the authentication is not successful.

Note: If the client included a <resume/> element in its SASL2 negotiation, that MUST be processed first by the server. If that resumption is successful, the server MUST skip resource binding (a resumed session already has a resource bound) and MUST entirely ignore the <bind/> request. If resumption of the previous stream fails, the server MUST include the XEP-0198 failure in the response, and then MUST proceed to process the bind request to establish a new session for the client.

Upon processing the bind request, the server MUST perform several operations, including:

• Clear the offline messages for this user, if any, without sending them (as they will be provided by MAM).
• Generate a resource identifier (per the rules below) and bind it to the current stream
• Get the archive id of the newest stanza in the user's MAM archive
• Enable any additional features requested by the client for this session

Upon successful binding of a resource, the server SHOULD terminate any earlier sessions from the same client (identified by the <user-agent> 'id' attribute in its SASL2 authentication request).

After processing the bind request as described above, the server MUST respond with the SASL <success/> element, including the client's full JID in the <authorization-identity/> element, and a <bound xmlns='urn:xmpp:bind2:0'/> element qualified by the 'urn:xmpp:bind:0' namespace, as in the following example:

<jidsuccess xmlns='urn:xmpp:sasl:2'>nurse@shakespeare
  <authorization-identity>user@example.litcom/abtet29a9fuAwesomeXMPP.4232f4d4</jidauthorization-identity>
  <latest-idbound xmlns='urn:xmpp:bind:0'>balisoseb
    <metadata xmlns='urn:xmpp:mam:2'>
      <start id='YWxwaGEg' timestamp='2008-08-22T21:09:04Z' />
      <end id='b21lZ2Eg' timestamp='2020-04-20T14:34:21Z' />
    </latest-idmetadata>
  <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>

    Servers SHOULD support the <unreads/success> feature, but if they do not then the

The server SHOULD include a <unreadsmetadata/> element MUST be elidedas defined by XEP-0313, to distinguish between an empty element (no unreaddescribing the state of the user's message archive at the precise time of resource binding. This helps the client determine what queries it may need to perform to synchronise messages) and a missing feature.

Interactions with certain other extensions are hereby defined in this document:

• If the client included a XEP-0198 <enable/> element in the requested features, Stream Management should be enabled at this point.3 Pipelining¶ The <bound/> response MUST contain the resulting XEP-0198 <enabled/> (or <failed/>) element. For full business rules, syntax and examples, see XEP-0198.
• If the client included a XEP-0280 <enable/> element in the requested features, Message Carbons MUST be enabled at this point. As this operation MUST succeed, no response is necessary.
• If the client included a XEP-0352 <active/> or <inactive/> element, the session must begin in that state.

A server supportingThe <bound/> response MUST also contain any defined responses to other enabled features, if any, though details of these are beyond the scope of this specification MUST allow the following initial commands to be pipelined: Initial client stream header SASL Authentication* Post-authentication stream header Bind 2.0 [ * 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] 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.

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

1. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.

2. XEP-0388: Extensible SASL Profile <https://xmpp.org/extensions/xep-0388.html>.

3. XEP-0280: Message Carbons <https://xmpp.org/extensions/xep-0280.html>.

4. XEP-0313: Message Archive Management <https://xmpp.org/extensions/xep-0313.html>.

5. XEP-0198: Stream Management <https://xmpp.org/extensions/xep-0198.html>.