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

1.8rc2 adjusted abstract and intro

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2919 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-03-24 18:24:58 +00:00
parent b40fa26ce9
commit 735da46eda
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
xep-0124.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>Bidirectional-streams Over Synchronous HTTP (BOSH)</title>
<abstract>This specification defines a transport protocol that emulates a bidirectional stream between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of polling or asynchronous chunking.</abstract>
<abstract>This specification defines a transport protocol that emulates the semantics of a long-lived, bidirectional TCP connection between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of frequent polling or chunked responses.</abstract>
&LEGALNOTICE;
<number>0124</number>
<status>Draft</status>
@ -29,10 +29,10 @@
&stpeter;
&metajack;
<revision>
<version>1.8rc1</version>
<date>in progress, last updated 2009-03-19</date>
<version>1.8rc2</version>
<date>in progress, last updated 2009-03-24</date>
<initials>psa/jm</initials>
<remark><p>Removed &apos;secure&apos; attribute; added security consideration regarding link between connection manager and application server; changed &quot;stanza&quot; to &quot;payload&quot; for disambiguation with XMPP.</p></remark>
<remark><p>Removed &apos;secure&apos; attribute; added security consideration regarding link between connection manager and application server; changed &quot;stanza&quot; to &quot;payload&quot; for disambiguation with XMPP; clarified design objectives and relationship to similar technologies.</p></remark>
</revision>
<revision>
<version>1.7</version>
@ -144,11 +144,11 @@
</revision>
</header>
<section1 topic="Introduction" anchor='intro'>
<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, can be used as a "drop-in" alternative to a bidirectional TCP connection. It is a mature, full-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 HTTP 1.0 or HTTP 1.1 as a transport (see &rfc1945; and &rfc2616;) without then need for "cookies" (see &rfc2965;). <note>Requiring cookies is sub-optimal because several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers.</note></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 the techniques now commonly known as "AJAX".</p>
<p>BOSH achieves this efficiency and low latency by avoiding polling without using 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, enabling 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 (see &rfc3920;), this transport is not part of XMPP. In fact, from its conception the intention was that BOSH 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 might 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 payload 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>
<p>The Transmission Control Protocol (TCP; &rfc0793;) is often used to establish a stream-oriented connection between two entities. Such connections can often be long-lived to enable an interactive "session" between the entities. However, sometimes the nature of the device or network can prevent an application from maintaining a long-lived TCP connection to a server or peer. In this case, it is desirable to use an alternative connection method that emulates the behavior of a long-lived TCP connection using a sequenced series of requests and responses that are exchanged over short-lived connections. The appropriate request-response semantics are widely available via the Hypertext Transfer Protocol (HTTP) as specified in &rfc1945; and &rfc2616;.</p>
<p>BOSH, the technology defined in this specification, essentially provides a "drop-in" alternative to a long-lived, bidirectional TCP connection. It is a mature, full-featured technology that has been widely implemented and deployed since 2004. To our knowledge it was the first of many similar technologies, which now include the Comet methodology formalized in the &bayeux; as well as &websocket; and &rhttp;.</p>
<p>BOSH is designed to transport any data efficiently and with minimal latency in both directions. For applications that require both "push" and "pull" semantics, BOSH is significantly more bandwidth-efficient and responsive than most other bidirectional HTTP-based transport protocols and the techniques now commonly known as "Ajax". BOSH achieves this efficiency and low latency by using so-called "long polling" with multiple synchronous HTTP request/response pairs. Furthermore, BOSH can address the needs of constrained clients by employing fully-compliant HTTP 1.0 without the need for "cookies" (see &rfc2965;) <note>Requiring cookies is sub-optimal because several significant computing platforms provide only limited access to underlying HTTP requests/responses; worse, some platforms hide or remove cookie-related headers.</note> or even access to HTTP headers.</p>
<p>BOSH was originally developed in the Jabber/XMPP community as a replacement for an even earlier HTTP-based technology called &xep0025;. Although BOSH assumes that the "payload" of HTTP requests and responses will be XML, the payload formats are not limited to XMPP stanzas (see &rfc3920;) and could contain a mixture of elements qualified by namespaces defined by different protocols (e.g., both XMPP and JSON). This mix is necessary because some connection managers might 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 payload is qualified by the correct namespace.</p>
<p>Note: &xep0206; documents some XMPP-specific extensions of this protocol that were formerly included in this document.</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>
@ -957,7 +957,7 @@ Content-Length: 68
</ul>
</section2>
<section2 topic='Connection Between BOSH Service and Application' anchor='security-app'>
<p>A BOSH service SHOULD encrypt its connection to the backend application using appropriate tecnologies such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), and StartTLS if supported by the backend application. Alternatively, the BOSH service can be considered secure (1) if it is running on the same physical machine as the backend application or (2) if it running on the same private network as the backend application and the administrators are sure that unknown individuals or processes do not have access to that private network. Because there is no way for the client to be sure that the BOSH service encrypts its connection to the application, it is RECOMMENDED for the client encrypt its messages using an application-specific end-to-end encryption technology; methods for doing so are outside the scope of this specification.</p>
<p>A BOSH service SHOULD encrypt its connection to the backend application using appropriate technologies such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), and StartTLS if supported by the backend application. Alternatively, the BOSH service can be considered secure (1) if it is running on the same physical machine as the backend application or (2) if it running on the same private network as the backend application and the administrators are sure that unknown individuals or processes do not have access to that private network. Because there is no way for the client to be sure that the BOSH service encrypts its connection to the application, clients wishing to ensure confidentiality are advised to encrypt their messages using an application-specific end-to-end encryption security; methods for doing so are outside the scope of this specification.</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>