moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

slight text tweaks

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@629 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-02-28 21:03:06 +00:00
parent 3fab347f0c
commit cf64cd2f8f
2 changed files with 25 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
xep-0124.xml
View File

@ -2,20 +2,18 @@
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY server "server">
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Bidirectional-streams Over Synchronous HTTP (BOSH)</title>
<abstract>This document defines a transport protocol (formerly known as HTTP Binding) that emulates bi-directional connections efficiently using multiple synchronous HTTP request/response pairs (i.e. without polling or asynchronous chunking).</abstract>
<abstract>This document defines a transport protocol (formerly known as HTTP Binding) that emulates bidirectional connections efficiently using multiple synchronous HTTP request/response pairs (i.e. without polling or asynchronous chunking).</abstract>
&LEGALNOTICE;
<number>0124</number>
<status>Draft</status>
<type>Standards Track</type>
<jig>Standards</jig>
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 1945</spec>
<spec>RFC 2616</spec>
<spec>RFC 3174</spec>
@ -133,17 +131,17 @@
</revision>
</header>
<section1 topic="Introduction" anchor='intro'>
<p>Applications, restricted either by their runtime environments or by firewalls that permit only Web browsing, often find that arbitrary TCP connections (see &rfc0793;) cannot be established. BOSH, the protocol described in this document, may be used as a "drop-in" alternative to a bi-directional TCP connection. It is a mature fully-featured protocol that has been in use for many years with many open source and commercial implementations. It overcomes common communication constraints by employing fully-compliant "cookie-free" <note>Enabling communications via &rfc2965; is sub-optimal since several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers.</note> HTTP 1.0 or HTTP 1.1 as a transport (see &rfc1945; and &rfc2616;).</p>
<p>BOSH can transport any data efficiently and with minimal latency in both directions. For applications that require both "push" and "pull" communications, BOSH is significantly more bandwidth-efficient and responsive than most other bi-directional HTTP-based transport protocols (e.g. &xep0025;) and techniques now commonly known as AJAX.</p>
<p>Certain applications often find that arbitrary TCP connections (see &rfc0793;) cannot be established (e.g., applications that are restricted either by their runtime environments or by firewalls permitting only Web browsing). BOSH, the protocol described in this document, may be used as a "drop-in" alternative to a bidirectional TCP connection. It is a mature, fully-featured protocol that has been in use for many years with many open source and commercial implementations. It overcomes common communication constraints by employing fully-compliant "cookie-free" <note>Enabling communications via &rfc2965; is sub-optimal since several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers.</note> HTTP 1.0 or HTTP 1.1 as a transport (see &rfc1945; and &rfc2616;).</p>
<p>BOSH can transport any data efficiently and with minimal latency in both directions. For applications that require both "push" and "pull" communications, BOSH is significantly more bandwidth-efficient and responsive than most other bidirectional HTTP-based transport protocols (e.g. &xep0025;) and techniques now commonly known as AJAX.</p>
<p>BOSH achieves this efficiency and low-latency by avoiding polling without resorting to chunked HTTP responses (i.e. without using the technique which is now commonly known as "Comet"). The protocol employs multiple synchronous HTTP request/response pairs. This technique allows it to pass through even those proxies that buffer partial HTTP responses before forwarding the full responses only once they are available.</p>
<p>Note: Although the XML being transported in the examples herein is XMPP, this transport is not part of XMPP. In fact, from its conception the intention of the primary author was that it could be used to implement any bidirectional XML stream transporting a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary since some connection managers may not support <link url="#multi">Multiple Streams</link> and constrained clients often have no access to HTTP Pipelining (which limits them to one BOSH session at a time). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML stanza is qualified by the correct namespace. &xep0206; documents some XMPP-specific extensions of this protocol that were formerly included in this document.</p>
<p>Note: Although the XML being transported in the examples herein is XMPP (see &rfc3920;), this transport is not part of XMPP. In fact, from its conception the intention of the primary author was that it could be used to implement any bidirectional XML stream transporting a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary since some connection managers may not support <link url="#multi">Multiple Streams</link> and constrained clients often have no access to HTTP Pipelining (which limits them to one BOSH session at a time). BOSH connection managers are generally not required to understand anything about the XML content that they transport beyond perhaps ensuring that each XML stanza is qualified by the correct namespace. &xep0206; documents some XMPP-specific extensions of this protocol that were formerly included in this document.</p>
<p>Note: This document inherits terminology regarding the Hypertext Transport Protocol from <cite>RFC 1945</cite> and <cite>RFC 2616</cite>.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The following design requirements reflect the need to offer performance as close as possible to a standard TCP connection.</p>
<ol>
<li>Compatible with constrained runtime environments** (e.g., mobile and browser-based clients).</li>
<li>Enable browser-based clients to make bi-directional cross-domain connections.*</li>
<li>Enable browser-based clients to make bidirectional cross-domain connections.*</li>
<li>Compatible with proxies that buffer partial HTTP responses.*</li>
<li>Efficient through proxies that limit the duration of HTTP responses.*</li>
<li>Fully-compatible with HTTP/1.0.*</li>
@ -167,7 +165,7 @@
</ol>
</section1>
<section1 topic="Architectural Assumptions" anchor='arch'>
<p>This document assumes that most implementations will utilize a specialized "connection manager" to handle HTTP connections rather than the usual TCP connections. Effectively, such a connection manager will be a specialized HTTP server that translates between the HTTP requests and responses defined herein and the data streams (or API) implemented by the &server; or &server;s with which it communicates, thus enabling an HTTP client to connect to a &server;. We can illustrate this graphically as follows:</p>
<p>This document assumes that most implementations will utilize a specialized "connection manager" to handle HTTP connections rather than the usual TCP connections. Effectively, such a connection manager will be a specialized HTTP server that translates between the HTTP requests and responses defined herein and the data streams (or API) implemented by the server or servers with which it communicates, thus enabling an HTTP client to connect to a server. We can illustrate this graphically as follows:</p>
<code><![CDATA[
Server
|
@ -179,7 +177,7 @@ Connection Manager
|
HTTP Client
]]></code>
<p>BOSH addresses communications between an HTTP client and the connection manager only. It does not address communications between the connection manager and the &server;, since such communications are implementation-specific (e.g., the &server; may natively support this HTTP binding, in which case the connection manager will be a logical entity rather than a physical entity; alternatively the connection manager may be an independant translating proxy such that the &server; may believe it is talking directly to the client over TCP; or the connection manager and the &server; may use a component protocol or an API defined by the &server; implementation).</p>
<p>BOSH addresses communications between an HTTP client and the connection manager only. It does not address communications between the connection manager and the server, since such communications are implementation-specific (e.g., the server may natively support this HTTP binding, in which case the connection manager will be a logical entity rather than a physical entity; alternatively the connection manager may be an independant translating proxy such that the server may believe it is talking directly to the client over TCP; or the connection manager and the server may use a component protocol or an API defined by the server implementation).</p>
<p>Furthermore, no aspect of this protocol limits its use to client-to-server communications. It could be used for server-to-server or component-to-server communications as well. However, this document focuses exclusively on use of the transport by clients that cannot maintain arbitrary persistent TCP connections with a server. We assume that servers and components are under no such restrictions and thus would use TCP.</p>
</section1>
<section1 topic="The BOSH Technique" anchor='technique'>
@ -193,7 +191,7 @@ Connection Manager
</section1>
<section1 topic="HTTP Overview" anchor='overview'>
<p>All information is encoded in the body of standard HTTP POST requests and responses. Each HTTP body contains a single &lt;body/&gt; wrapper which encapsulates the XML elements being transferred (see <link url="#wrapper">&lt;body/&gt; Wrapper Element</link>).</p>
<p>Clients SHOULD send all HTTP requests over a single persistent HTTP/1.1 connection using HTTP Pipelining. However, a client MAY deliver its POST requests in any way permited by <cite>RFC 1945</cite> or <cite>RFC 2616</cite>. For examples, constrained clients can be expected to open more than one persistent connection instead of using Pipelining, or in some cases to open a new HTTP/1.0 connection to send each request. However, clients and connection managers SHOULD NOT use Chunked Transfer Coding, since intermediaries may buffer each partial HTTP request or response and only forward the full request or reponse once it is available.</p>
<p>Clients SHOULD send all HTTP requests over a single persistent HTTP/1.1 connection using HTTP Pipelining. However, a client MAY deliver its POST requests in any way permited by <cite>RFC 1945</cite> or <cite>RFC 2616</cite>. For example, constrained clients can be expected to open more than one persistent connection instead of using Pipelining, or in some cases to open a new HTTP/1.0 connection to send each request. However, clients and connection managers SHOULD NOT use Chunked Transfer Coding, since intermediaries may buffer each partial HTTP request or response and only forward the full request or reponse once it is available.</p>
<p>Clients MAY include an HTTP Accept-Encoding header in any request. If the connection manager receives a request with an Accept-Encoding header, it MAY include an HTTP Content-Encoding header in the response (indicating one of the encodings specified in the request) and compress the response body accordingly.</p>
<p>Requests and responses MAY include HTTP headers not specified herein. The receiver SHOULD ignore any such headers.</p>
<p>Each BOSH session MAY share the HTTP connection(s) it uses with other HTTP traffic, including other BOSH sessions and HTTP requests and responses completely unrelated to this protocol (e.g., web page downloads). However, the responses to requests that are not part of the session sent over the same connection using HTTP pipelining (or queued to be sent over the same connection) may be delayed if they were sent while a request that is part of the session is being held (since the connection manager MUST send its responses in the same order that the requests were received, and the connection manager typically delays its responses).</p>
@ -224,10 +222,10 @@ Connection Manager
<li><strong>'hold'</strong> -- This attribute specifies the maximum number of requests the connection manager is allowed to keep waiting at any one time during the session. If the client is not able to use HTTP Pipelining then this SHOULD be set to "1".</li>
</ul>
<p>Note: Clients that only support <link url="#poll">Polling Sessions</link> MAY prevent the connection manager from waiting by setting 'wait' or 'hold' to "0". However, polling is NOT RECOMMENDED since the associated increase in bandwidth consumption and the decrease in responsiveness are both typically one or two orders of magnitude!</p>
<p>A connection manager MAY be configured to enable sessions with more than one &server; in different domains. When requesting a session with such a 'proxy' connection manager, a client SHOULD include a <strong>'route'</strong> attribute that specifies the protocol, hostname, and port of the &server; with which it wants to communicate, formatted as "proto:host:port" (e.g., "xmpp:jabber.org:9999"). <note>Although the syntax of the 'route' attribute bears a superficial resemblance to a URI or IRI, it is not a URI/IRI and MUST NOT be processed in accordance with the rules specified in <cite>RFC 3986</cite>, <cite>RFC 3987</cite>, or <cite>draft-saintandre-xmpp-iri</cite>.</note> A connection manager that is configured to work only with a single &server; (or only with a defined list of domains and the associated list of hostnames and ports that are serving those domains) MAY ignore the 'route' attribute. (Note that the 'to' attribute specifies the domain being served, not the hostame of the machine that is serving the domain.)</p>
<p>A client MAY include a <strong>'from'</strong> attribute to enable the connection manager to forward its identity to the &server;.</p>
<p>A connection manager MAY be configured to enable sessions with more than one server in different domains. When requesting a session with such a 'proxy' connection manager, a client SHOULD include a <strong>'route'</strong> attribute that specifies the protocol, hostname, and port of the server with which it wants to communicate, formatted as "proto:host:port" (e.g., "xmpp:jabber.org:9999"). <note>Although the syntax of the 'route' attribute bears a superficial resemblance to a URI or IRI, it is not a URI/IRI and MUST NOT be processed in accordance with the rules specified in <cite>RFC 3986</cite>, <cite>RFC 3987</cite>, or <cite>draft-saintandre-xmpp-iri</cite>.</note> A connection manager that is configured to work only with a single server (or only with a defined list of domains and the associated list of hostnames and ports that are serving those domains) MAY ignore the 'route' attribute. (Note that the 'to' attribute specifies the domain being served, not the hostame of the machine that is serving the domain.)</p>
<p>A client MAY include a <strong>'from'</strong> attribute to enable the connection manager to forward its identity to the server.</p>
<p>A client MAY include an <strong>'ack'</strong> attribute (set to "1") to indicate that it will be using acknowledgements throughout the session and that the absence of an 'ack' attribute in any request is meaningful (see <link url="#ack">Acknowledgements</link>).</p>
<p>A client MAY include a <strong>'secure'</strong> attribute to specify that communications between the connection manager and the &server; must be "secure". (Note: The 'secure' attribute is of type xs:boolean (see &w3xmlschema2;) and the default value is "false". &BOOLEANNOTE;) If a connection manager receives a session request with the 'secure' attribute set to "true" or "1", then it MUST respond to the client with a <link url="#errorstatus-terminal">remote-connection-failed</link> error as soon as it determines that it cannot communicate in a secure way with the &server;. A connection manager SHOULD consider communications with the &server; to be "secure" if they are encrypted using SSL or TLS with verified certificates, or if it is running on the same physical machine as the &server;. A connection manager MAY consider communications over a "private" network to be secure, even without SSL or TLS; however, a network SHOULD be considered "private" only if the administrator of the connection manager is sure that unknown individuals or processes do not have access to the network (i.e., individuals or processes who do not have access to either the connection manager or the &server;). The connection manager SHOULD try to establish a secure connection with the &server; even if the client does not specifically require it.</p>
<p>A client MAY include a <strong>'secure'</strong> attribute to specify that communications between the connection manager and the server must be "secure". (Note: The 'secure' attribute is of type xs:boolean (see &w3xmlschema2;) and the default value is "false". &BOOLEANNOTE;) If a connection manager receives a session request with the 'secure' attribute set to "true" or "1", then it MUST respond to the client with a <link url="#errorstatus-terminal">remote-connection-failed</link> error as soon as it determines that it cannot communicate in a secure way with the server. A connection manager SHOULD consider communications with the server to be "secure" if they are encrypted using SSL or TLS with verified certificates, or if it is running on the same physical machine as the server. A connection manager MAY consider communications over a "private" network to be secure, even without SSL or TLS; however, a network SHOULD be considered "private" only if the administrator of the connection manager is sure that unknown individuals or processes do not have access to the network (i.e., individuals or processes who do not have access to either the connection manager or the server). The connection manager SHOULD try to establish a secure connection with the server even if the client does not specifically require it.</p>
<p>Some clients are constrained to only accept HTTP responses with specific Content-Types (e.g., "text/html"). The &lt;body/&gt; element of the first request MAY possess a <strong>'content'</strong> attribute. This specifies the value of the HTTP Content-Type header that MUST appear in all the connection manager's responses during the session. If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be "text/xml; charset=utf-8".</p>
<example caption="Requesting a BOSH session">
<![CDATA[POST /webclient HTTP/1.1
@ -267,7 +265,7 @@ Content-Length: 104
<p>A connection manager MAY include an <strong>'ack'</strong> attribute (set to the value of the 'rid' attribute of the session creation request) to indicate that it will be using acknowledgements throughout the session and that the absence of an 'ack' attribute in any response is meaningful (see <link url="#ack">Acknowledgements</link>).</p>
<p>If the connection manager supports session pausing (see <link url="#inactive">Inactivity</link>) then it SHOULD advertise that to the client by including a <strong>'maxpause'</strong> attribute in the session creation response element. The value of the attribute indicates the maximum length of a temporary session pause (in seconds) that a client MAY request.</p>
<p>For both requests and responses, the &lt;body/&gt; element and its content SHOULD be UTF-8 encoded. If the HTTP Content-Type header of a request/response specifies a character encoding other than UTF-8, then the connection manager MAY convert between UTF-8 and the other character encoding. However, even in this case, it is OPTIONAL for the connection manager to convert between encodings. The connection manager MAY inform the client which encodings it can convert by setting the optional <strong>'charsets'</strong> attribute in the session creation response element to a space-separated list of encodings. <note>Each character set name (or character encoding name -- we use the terms interchangeably) SHOULD be of type NMTOKEN, where the names are separated by the white space character #x20, resulting in a tokenized attribute type of NMTOKENS (see Section 3.3.1 of &w3xml;). Strictly speaking, the Character Sets registry maintained by the Internet Assigned Numbers Authority (see &lt;<link url='http://www.iana.org/assignments/character-sets'>http://www.iana.org/assignments/character-sets</link>&gt;) allows a character set name to contain any printable US-ASCII character, which might include characters not allowed by the NMTOKEN construction of XML 1.0; however, the only existing character set name which includes such a character is "NF_Z_62-010_(1973)".</note></p>
<p>As soon as the connection manager has established a connection to the &server; and discovered its identity, it MAY forward the identity to the client by including a <strong>'from'</strong> attribute in a response, either in its session creation response, or (if it has not received the identity from the &server; by that time) in any subsequent response to the client. If it established a secure connection to the &server; (as defined in <link url='#session'>Initiating a BOSH Session</link>), then in the same response the connection manager SHOULD also include the <strong>'secure'</strong> attribute set to "true" or "1".</p>
<p>As soon as the connection manager has established a connection to the server and discovered its identity, it MAY forward the identity to the client by including a <strong>'from'</strong> attribute in a response, either in its session creation response, or (if it has not received the identity from the server by that time) in any subsequent response to the client. If it established a secure connection to the server (as defined in <link url='#session'>Initiating a BOSH Session</link>), then in the same response the connection manager SHOULD also include the <strong>'secure'</strong> attribute set to "true" or "1".</p>
<example caption="Session creation response">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
@ -320,9 +318,9 @@ Content-Length: 188
<body>I said "Hi!"</body>
</message>
</body>]]></example>
<p>Upon receipt of a request, the connection manager SHOULD forward the content of the &lt;body/&gt; element to the &server; as soon as possible. In any case it MUST forward the content from different requests in the order specified by their 'rid' attributes.</p>
<p>The connection manager MUST also return an HTTP 200 OK response with a &lt;body/&gt; element to the client. Note: This does not indicate that the stanzas have been successfully delivered to the &server;.</p>
<p>It is RECOMMENDED that the connection manager not return an HTTP result until a stanza has arrived from the &server; for delivery to the client. However, the connection manager SHOULD NOT wait longer than the time specified by the client in the 'wait' attribute of its <link url="#session-request">Session Creation Request</link>, and it SHOULD NOT keep more HTTP requests waiting at a time than the number specified in the 'hold' attribute of the session creation request. In any case it MUST respond to requests in the order specified by their 'rid' attributes.</p>
<p>Upon receipt of a request, the connection manager SHOULD forward the content of the &lt;body/&gt; element to the server as soon as possible. In any case it MUST forward the content from different requests in the order specified by their 'rid' attributes.</p>
<p>The connection manager MUST also return an HTTP 200 OK response with a &lt;body/&gt; element to the client. Note: This does not indicate that the stanzas have been successfully delivered to the server.</p>
<p>It is RECOMMENDED that the connection manager not return an HTTP result until a stanza has arrived from the server for delivery to the client. However, the connection manager SHOULD NOT wait longer than the time specified by the client in the 'wait' attribute of its <link url="#session-request">Session Creation Request</link>, and it SHOULD NOT keep more HTTP requests waiting at a time than the number specified in the 'hold' attribute of the session creation request. In any case it MUST respond to requests in the order specified by their 'rid' attributes.</p>
<p>If there are no stanzas waiting or ready to be delivered within the waiting period, then the connection manager SHOULD include an empty &lt;body/&gt; element in the HTTP result:</p>
<example caption="Empty response">
<![CDATA[HTTP/1.1 200 OK
@ -330,7 +328,7 @@ Content-Type: text/xml; charset=utf-8
Content-Length: 64
<body xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
<p>If the connection manager has received one or more stanzas from the &server; for delivery to the client, then it SHOULD return the stanzas in the body of its response as soon as possible after receiving them from the &server;. The example below includes stanzas qualified by different namespaces:</p>
<p>If the connection manager has received one or more stanzas from the server for delivery to the client, then it SHOULD return the stanzas in the body of its response as soon as possible after receiving them from the server. The example below includes stanzas qualified by different namespaces:</p>
<example caption="Response with queued stanza">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
@ -483,7 +481,7 @@ Content-Length: 68
<p>Note: If the connection manager did not specify a 'polling' attribute in the session creation response, then it MUST allow the client to poll as frequently as it chooses.</p>
</section1>
<section1 topic='Terminating the HTTP Session' anchor='terminate'>
<p>At any time, the client MAY gracefully terminate the session by sending a &lt;body/&gt; element with a 'type' attribute set to "terminate". The termination request MAY include one or more stanzas that the connection manager MUST forward to the &server; to ensure graceful logoff.</p>
<p>At any time, the client MAY gracefully terminate the session by sending a &lt;body/&gt; element with a 'type' attribute set to "terminate". The termination request MAY include one or more stanzas that the connection manager MUST forward to the server to ensure graceful logoff.</p>
<example caption="Session termination by client">
<![CDATA[POST /webclient HTTP/1.1
Host: httpcm.jabber.org
@ -505,7 +503,7 @@ Content-Length: 153
<p>The client MUST generate a large, random, positive integer for the initial 'rid' (see <link url="#security">Security Considerations</link>, this also prevents non-compliant proxies from caching <link url="#script">Script Syntax</link> responses) and then increment that value by one for each subsequent request. The client MUST take care to choose an initial 'rid' that will never be incremented above 9007199254740991 <note>9007199254740991 is 2<span class='super'>53</span>-1. Some weakly typed languages use IEEE Standard 754 Doubles to represent all numbers. These Doubles cannot represent integers above 2<span class='super'>53</span> accurately.</note> within the session. In practice, a session would have to be extraordinarily long (or involve the exchange of an extraordinary number of packets) to exceed the defined limit.</p>
</section2>
<section2 topic='In-Order Message Forwarding' anchor='rids-order'>
<p>When a client makes simultaneous requests, the connection manager may receive them out of order. The connection manager MUST forward the stanzas to the &server; and respond to the client requests in the order specified by the 'rid' attributes. The client MUST process responses received from the connection manager in the order the requests were made.</p>
<p>When a client makes simultaneous requests, the connection manager may receive them out of order. The connection manager MUST forward the stanzas to the server and respond to the client requests in the order specified by the 'rid' attributes. The client MUST process responses received from the connection manager in the order the requests were made.</p>
<p>The connection manager SHOULD expect the 'rid' attribute to be within a window of values greater than the 'rid' of the previous request. The size of the window is equal to the maximum number of simultaneous requests allowed by the connection manager. If it receives a request with a 'rid' greater than the values in the window, then the connection manager MUST terminate the session with an error:</p>
<example caption="Unexpected rid error">
<![CDATA[HTTP/1.1 200 OK
@ -660,7 +658,7 @@ Content-Length: 104
secure='true'
xml:lang='en'
xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
<p>If the connection manager did not indicate its support for multiple streams at the start of the session then it MUST ignore the extra attributes and treat the request as a normal empty request for stanzas (see <link url="#stanzas">Sending and Receiving XML Stanzas</link>). <note>This helps to ensure backwards-compatibility with older implementations.</note> Otherwise it MUST open a new stream with the specified &server; (see <link url="#session-create">Session Creation Response</link>), generate a new stream name and respond to the client with the name. The response MAY also include 'from' and 'secure' attributes, but it SHOULD NOT include 'sid', 'requests', 'polling', 'hold', 'inactivity', 'maxpause', 'accept', 'charsets', 'ver' or 'wait' attributes.</p>
<p>If the connection manager did not indicate its support for multiple streams at the start of the session then it MUST ignore the extra attributes and treat the request as a normal empty request for stanzas (see <link url="#stanzas">Sending and Receiving XML Stanzas</link>). <note>This helps to ensure backwards-compatibility with older implementations.</note> Otherwise it MUST open a new stream with the specified server (see <link url="#session-create">Session Creation Response</link>), generate a new stream name and respond to the client with the name. The response MAY also include 'from' and 'secure' attributes, but it SHOULD NOT include 'sid', 'requests', 'polling', 'hold', 'inactivity', 'maxpause', 'accept', 'charsets', 'ver' or 'wait' attributes.</p>
<example caption="Add stream response">
<![CDATA[HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
@ -761,7 +759,7 @@ Content-Length: 68
<table caption='Error Condition Types'>
<tr><th>Condition Type</th><th>Description</th></tr>
<tr><td><strong>HTTP Conditions</strong>&#32;<em>(Deprecated)</em></td><td>The connection manager responds to an invalid request from a <em>legacy</em> client with a standard HTTP error. These are used for binding syntax errors, possible attacks, etc. Note that constrained clients are unable to differentiate between HTTP errors.</td></tr>
<tr><td><strong>Terminal Binding Conditions</strong></td><td>These error conditions may be read by constrained clients. They are used for connection manager problems, abstracting stream errors, communication problems between the connection manager and the &server;, and invalid client requests (binding syntax errors, possible attacks, etc.)</td></tr>
<tr><td><strong>Terminal Binding Conditions</strong></td><td>These error conditions may be read by constrained clients. They are used for connection manager problems, abstracting stream errors, communication problems between the connection manager and the server, and invalid client requests (binding syntax errors, possible attacks, etc.)</td></tr>
<tr><td><strong>Recoverable Binding Conditions</strong></td><td>These report communication problems between the connection manager and the client. They do not terminate the session. Clients recover from these errors by resending all the preceding &lt;body/&gt; wrappers that have not received responses.</td></tr>
<tr><td><strong>Transported Protocol Conditions</strong></td><td>Errors relating to the XML stanzas <em>within</em> &lt;body/&gt; wrappers are, in general, defined in the documentation of the protocol being transported. They do not terminate the session.</td></tr>
</table>
@ -858,7 +856,7 @@ Content-Length: 68
</tr>
<tr>
<td>remote-connection-failed</td>
<td>The connection manager was unable to connect to, or unable to connect securely to, or has lost its connection to, the &server;.</td>
<td>The connection manager was unable to connect to, or unable to connect securely to, or has lost its connection to, the server.</td>
</tr>
<tr>
<td>remote-stream-error</td>
@ -1035,7 +1033,7 @@ _BOSH_("<body rid='1249243562' sid='SomeSID'
<li>If the connection manager refuses to establish an encrypted connection or offers a different certificate, then the client SHOULD close the connection and terminate the session without sending any more requests.</li>
<li>If the client sends a wrapper element that is part of a 'secure session' over a connection that either is not encrypted or uses a different certificate then the connection manager SHOULD simply close the connection. The connection manager SHOULD NOT terminate the session since that would facilitate denial of service attacks.</li>
</ul>
<p>In cases where the connection manager acts as a 'translating proxy' independent of the &server;, it creates another security vulnerability in addition to those on the &server;s. It is RECOMMENDED that clients ensure the security of stanzas sent through the connection manager (and &server;s) in both directions by encrypting them end-to-end (e.g., by establishing &xep0116;).</p>
<p>In cases where the connection manager acts as a 'translating proxy' independent of the server, it creates another security vulnerability in addition to those on the servers. It is RECOMMENDED that clients ensure the security of stanzas sent through the connection manager (and servers) in both directions by encrypting them end-to-end (e.g., by establishing &xep0116;).</p>
</section2>
<section2 topic='Unpredictable SID and RID' anchor='security-sidrid'>
<p>The session identifier (SID) and initial request identifier (RID) are security-critical and therefore MUST be both unpredictable and nonrepeating (see &rfc1750; for recommendations regarding randomness of SIDs and initial RIDs for security purposes).</p>

3
xep-0206.xml
View File

@ -21,6 +21,9 @@
<supersedes/>
<supersededby/>
<shortname>xbosh</shortname>
<schemaloc>
<url>http://www.xmpp.org/schemas/xbosh.xsd</url>
</schemaloc>
&ianpaterson;
<revision>
<version>1.0</version>