From 2060b5be966296a24d70b1afbdb4364c73f679e4 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 8 Nov 2013 14:31:48 -0800 Subject: [PATCH] 1.4rc1 --- xep-0206.xml | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/xep-0206.xml b/xep-0206.xml index 595109b7..8b5e09b2 100644 --- a/xep-0206.xml +++ b/xep-0206.xml @@ -26,6 +26,13 @@ &ianpaterson; &stpeter; + &lance; + + 1.4rc1 + 2013-11-08 + ls +

Incorporated patches from community review.

 + 1.3 2010-07-02 @@ -69,7 +76,7 @@ -

The client SHOULD include a 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace in its session creation request. This attribute corresponds to the 'version' attribute of the XMPP <stream:stream/> element as defined in RFC 3920 and &rfc6120;. The connection manager SHOULD forward the value to the XMPP server accordingly.

+

The client SHOULD include a 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace in its session creation request. This attribute corresponds to the 'version' attribute of the XMPP <stream:stream/> element as defined in &rfc6120;. The connection manager SHOULD forward the value to the XMPP server accordingly.

]]>

Note: The client SHOULD ignore any Transport Layer Security (TLS) feature since BOSH channel encryption SHOULD be negotiated at the HTTP layer.

-

TLS compression (as defined in RFC 3920) and Stream Compression (as defined in &xep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer using the 'accept' attribute of the BOSH session creation response. TLS compression and Stream Compression SHOULD NOT be used at the same time as HTTP content encoding.

+

TLS compression (as defined in &rfc6120;) and Stream Compression (as defined in &xep0138;) are NOT RECOMMENDED since compression SHOULD be negotiated at the HTTP layer using the 'accept' attribute of the BOSH session creation response. TLS compression and Stream Compression SHOULD NOT be used at the same time as HTTP content encoding.

Note: The 'version' attribute qualified by the 'urn:xmpp:xbosh' namespace SHOULD also be included on the request and response when adding new streams to a session.

 -

A success case for authentication and resource binding using the XMPP protocols is shown below. For detailed specification of these protocols (including error cases), refer to RFC 3920 and draft-ietf-xmpp-3920bis.

+

A success case for authentication and resource binding using the XMPP protocols is shown below. For detailed specification of these protocols (including error cases), refer to &rfc6120;

-

It is possible that a connection manager will receive a stanza for delivery to a client even though the client connection is no longer active (e.g., before the connection manager is able to inform the XMPP server that the connection has died). In this case, the connection manager would return an error to the XMPP server; it is RECOMMENDED that the connection manager proceed as follows, since the situation is similar to that addressed by point #2 of Section 11.1 of RFC 3921:

+

It is possible that a connection manager will receive a stanza for delivery to a client even though the client connection is no longer active (e.g., before the connection manager is able to inform the XMPP server that the connection has died). In this case, the connection manager would return an error to the XMPP server; it is RECOMMENDED that the connection manager proceed as follows, since the situation is similar to that addressed by point #2 of Section 11.1 of &rfc6121;

  1. If the delivered stanza was &PRESENCE;, silently drop the stanza and do not return an error to the sender.
  2. If the delivered stanza was &IQ;, return a &unavailable; error to the sender.
    3. @@ -365,6 +372,7 @@ Content-Length: 68 +

    Thanks to Dave Cridland, Steffen Larsen, Matt Miller, Jack Moffitt, Stefan Strigler, Mike Taylor, Winfried Tilanus, Ashley Ward, and Matthew Wild for their feedback.

    Thanks to Kevin Winters for his assistance with the schema.