moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

1.4rc1

This commit is contained in:
Peter Saint-Andre 2013-11-08 14:31:48 -08:00
parent 96926cfa55
commit 2060b5be96
1 changed files with 12 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
xep-0206.xml
View File

@ -26,6 +26,13 @@
</schemaloc>
&ianpaterson;
&stpeter;
&lance;
<revision>
<version>1.4rc1</version>
<date>2013-11-08</date>
<initials>ls</initials>
<remark><p>Incorporated patches from community review.</p></remark>
</revision>
<revision>
<version>1.3</version>
<date>2010-07-02</date>
@ -69,7 +76,7 @@
</section1>
<section1 topic="Session Creation Request" anchor='initiate'>
<p>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 &lt;stream:stream/&gt; element as defined in <cite>RFC 3920</cite> and &rfc6120;. The connection manager SHOULD forward the value to the XMPP server accordingly.</p>
<p>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 &lt;stream:stream/&gt; element as defined in &rfc6120;. The connection manager SHOULD forward the value to the XMPP server accordingly.</p>
<example caption="Requesting a session with a version attribute">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.jabber.org
@ -146,12 +153,12 @@ Content-Length: 483
</body>
]]></example>
<p>Note: The client SHOULD ignore any Transport Layer Security (TLS) feature since BOSH channel encryption SHOULD be negotiated at the HTTP layer.</p>
<p>TLS compression (as defined in <cite>RFC 3920</cite>) 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.</p>
<p>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.</p>
<p>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.</p>
</section1>
<section1 topic="Authentication and Resource Binding" anchor='preconditions-sasl'>
<p>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 <cite>RFC 3920</cite> and draft-ietf-xmpp-3920bis.</p>
<p>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;</p>
<example caption="SASL authentication step 1">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.example.com
@ -307,7 +314,7 @@ Content-Length: 68
</section1>
<section1 topic='recipient-unavailable' anchor='recipient-unavailable'>
<p>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 <cite>RFC 3921</cite>:</p>
<p>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;</p>
<ol>
<li>If the delivered stanza was &PRESENCE;, silently drop the stanza and do not return an error to the sender.</li>
<li>If the delivered stanza was &IQ;, return a &unavailable; error to the sender.</li>
@ -365,6 +372,7 @@ Content-Length: 68
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Dave Cridland, Steffen Larsen, Matt Miller, Jack Moffitt, Stefan Strigler, Mike Taylor, Winfried Tilanus, Ashley Ward, and Matthew Wild for their feedback.</p>
<p>Thanks to Kevin Winters for his assistance with the schema.</p>
</section1>