1.8rc1: removed secure attribute, added security consideration

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2910 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0124.xml

@@ -27,6 +27,13 @@
     &ianpaterson;
     &dizzyd;
     &stpeter;
+    &metajack;
+    <revision>
+      <version>1.8rc1</version>
+      <date>in progress, last updated 2009-03-19</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>
+    </revision>
     <revision>
       <version>1.7</version>
       <date>2008-10-29</date>
@@ -140,7 +147,7 @@
     <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 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 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>
   </section1>
   <section1 topic='Requirements' anchor='reqs'>
@@ -210,7 +217,7 @@
       <li><p>Internal or external DTD subsets</p></li>
       <li><p>Internal or external entity references (with the exception of predefined entities)</p></li>
     </ul>
-    <p>The &lt;body/&gt; wrapper MUST NOT contain any XML character data, although its child elements MAY contain character data. The &lt;body/&gt; wrapper MUST contain zero or more complete XML immediate child elements (called "stanzas" in this document, e.g., XMPP stanzas, or elements containing XML character data that represents objects using the JSON data interchange format -- see &rfc4627;). Each &lt;body/&gt; wrapper MAY contain stanzas qualified under a wide variety of different namespaces.</p>
+    <p>The &lt;body/&gt; wrapper MUST NOT contain any XML character data, although its child elements MAY contain character data. The &lt;body/&gt; wrapper MUST contain zero or more complete XML immediate child elements (called "payloads" in this document, e.g., XMPP stanzas as defined in <cite>RFC 3920</cite> or elements containing XML character data that represents objects using the JSON data interchange format as defined in &rfc4627;). Each &lt;body/&gt; wrapper MAY contain payloads qualified under a wide variety of different namespaces.</p>
     <p>The &lt;body/&gt; element of every client request MUST possess a sequential request ID encapsulated via the 'rid' attribute; for details, refer to the <link url="#rids">Request IDs</link> section of this document.</p>
   </section1>
   <section1 topic="Initiating a BOSH Session" anchor='session'>
@@ -228,7 +235,6 @@
       <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 (for XMPP) <cite>RFC 5122</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>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
@@ -300,9 +306,9 @@ Content-Length: 128
       xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
     </section2>
   </section1>
-  <section1 topic="Sending and Receiving XML Stanzas" anchor='stanzas'>
+  <section1 topic="Sending and Receiving XML Payloads" anchor='payloads'>
-    <p>After the client has successfully completed all required preconditions, it can send and receive XML stanzas via the HTTP binding.</p>
+    <p>After the client has successfully completed all required preconditions, it can send and receive XML payloads via the HTTP binding.</p>
-    <example caption="Transmitting stanzas">
+    <example caption="Transmitting payloads">
 <![CDATA[POST /webclient HTTP/1.1
 Host: httpcm.jabber.org
 Accept-Encoding: gzip, deflate
@@ -322,16 +328,16 @@ Content-Length: 188
   </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>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 payloads have been successfully delivered to the application 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>It is RECOMMENDED that the connection manager not return an HTTP result until a payload has arrived from the application 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>
+    <p>If there are no payloads 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
 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 payloads from the application server for delivery to the client, then it SHOULD return the payloads in the body of its response as soon as possible after receiving them from the server. The example below includes payloads qualified by different namespaces:</p>
     <example caption="Response with queued stanza">
 <![CDATA[HTTP/1.1 200 OK
 Content-Type: text/xml; charset=utf-8
@@ -374,8 +380,8 @@ Content-Length: 185
   ]
   </json:json>
 </body>]]></example>
-    <p>The client MAY poll the connection manager for incoming stanzas by sending an empty &lt;body/&gt; element.</p>
+    <p>The client MAY poll the connection manager for incoming payloads by sending an empty &lt;body/&gt; element.</p>
-    <example caption="Requesting XML Stanzas">
+    <example caption="Requesting XML Payloads">
 <![CDATA[POST /webclient HTTP/1.1
 Host: httpcm.jabber.org
 Accept-Encoding: gzip, deflate
@@ -385,7 +391,7 @@ Content-Length: 88
 <body rid='1249243563'
       sid='SomeSID'
       xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
-    <p>The connection manager MUST wait and respond in the same way as it does after receiving stanzas from the client.</p>
+    <p>The connection manager MUST wait and respond in the same way as it does after receiving payloads from the client.</p>
   </section1>
   <section1 topic='Acknowledgements' anchor='acks'>
     <section2 topic='Request Acknowledgements' anchor='ack-request'>
@@ -413,7 +419,7 @@ Content-Length: 88
       sid='SomeSID'
       ack='1249243564'
       xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
-      <p>After receiving a request with an 'ack' value less than the 'rid' of the last request that it has already responded to, the connection manager MAY inform the client of the situation by sending its next response immediately instead of waiting until it has stanzas to send to the client (e.g., if some time has passed since it responded). In this case it SHOULD include a 'report' attribute set to one greater than the 'ack' attribute it received from the client, and a 'time' attribute set to the number of milliseconds since it sent the response associated with the 'report' attribute.</p>
+      <p>After receiving a request with an 'ack' value less than the 'rid' of the last request that it has already responded to, the connection manager MAY inform the client of the situation by sending its next response immediately instead of waiting until it has payloads to send to the client (e.g., if some time has passed since it responded). In this case it SHOULD include a 'report' attribute set to one greater than the 'ack' attribute it received from the client, and a 'time' attribute set to the number of milliseconds since it sent the response associated with the 'report' attribute.</p>
       <example caption="Response with report">
 <![CDATA[HTTP/1.1 200 OK
 Content-Type: text/xml; charset=utf-8
@@ -442,7 +448,7 @@ Content-Length: 98
       sid='SomeSID'
       pause='60'
       xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
-    <p>Upon reception of a session pause request, if the requested period is not greater than the maximum permitted time, then the connection manager SHOULD respond immediately to all pending requests (including the pause request) and <em>temporarily</em> increase the maximum inactivity period to the requested time. Note: The response to the pause request MUST NOT contain any stanzas.</p>
+    <p>Upon reception of a session pause request, if the requested period is not greater than the maximum permitted time, then the connection manager SHOULD respond immediately to all pending requests (including the pause request) and <em>temporarily</em> increase the maximum inactivity period to the requested time. Note: The response to the pause request MUST NOT contain any payloads.</p>
     <p>Note: If the client simply wants the connection manager to return all the requests it is holding then it MAY set the value of the 'pause' attribute to be the value of the 'inactivity' attribute in the connection manager's session creation response. (If the client believes it is in danger of becoming disconnected indefinitely then it MAY even request a temporary reduction of the maximum inactivity period by specifying a 'pause' value less than the 'inactivity' value, thus enabling the connection manager to discover any subsequent disconnection more quickly.)</p>
     <p>The connection manager SHOULD set the maximum inactivity period back to normal upon reception of the next request from the client (assuming the connection manager has not already terminated the session).</p>
   </section1>
@@ -470,9 +476,9 @@ 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 send requests as frequently as it chooses.</p>
   </section1>
   <section1 topic='Polling Sessions' anchor='poll'>
-    <p>It is not always possible for a constrained client to either use HTTP Pipelining or open more than one HTTP connection with the connection manager at a time. In this case the client SHOULD inform the connection manager by setting the values of the 'wait' and/or 'hold' attributes in its session creation request to "0", and then "poll" the connection manager at regular intervals throughout the session for stanzas it might have received from the server. Note: Even if the client does not request a polling session, the connection manager MAY require a client to use polling by setting the 'requests' attribute (which specifies the number of simultaneous requests the client can make) of its <link url="#session-create">Session Creation Response</link> to "1", however this is NOT RECOMMENDED.</p>
+    <p>It is not always possible for a constrained client to either use HTTP Pipelining or open more than one HTTP connection with the connection manager at a time. In this case the client SHOULD inform the connection manager by setting the values of the 'wait' and/or 'hold' attributes in its session creation request to "0", and then "poll" the connection manager at regular intervals throughout the session for payloads it might have received from the server. Note: Even if the client does not request a polling session, the connection manager MAY require a client to use polling by setting the 'requests' attribute (which specifies the number of simultaneous requests the client can make) of its <link url="#session-create">Session Creation Response</link> to "1", however this is NOT RECOMMENDED.</p>
     <p>If a session will use polling, the connection manager SHOULD specify a higher than normal value for the 'inactivity' attribute (see <link url="#inactive">Inactivity</link>) in its session creation response. The increase SHOULD be greater than the value it specifies for the 'polling' attribute.</p>
-    <p>If the client sends two consecutive empty new requests (i.e. requests with incremented rid attributes, not repeat requests) within a period shorter than the number of seconds specified by the 'polling' attribute (the shortest allowable polling interval) in the session creation response, and if the connection manager's response to the first request contained no stanzas, then upon reception of the second request the connection manager SHOULD terminate the HTTP session and return a 'policy-violation' terminal binding error to the client.</p>
+    <p>If the client sends two consecutive empty new requests (i.e. requests with incremented rid attributes, not repeat requests) within a period shorter than the number of seconds specified by the 'polling' attribute (the shortest allowable polling interval) in the session creation response, and if the connection manager's response to the first request contained no payloads, then upon reception of the second request the connection manager SHOULD terminate the HTTP session and return a 'policy-violation' terminal binding error to the client.</p>
     <example caption="Too frequent polling response">
 <![CDATA[HTTP/1.1 200 OK
 Content-Type: text/xml; charset=utf-8
@@ -484,7 +490,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 payloads 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
@@ -514,7 +520,7 @@ Content-Length: 72
       <p>The client MUST generate a large, random, positive integer for the initial 'rid' (see <link url="#security">Security Considerations</link>) 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 might 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 might receive them out of order. The connection manager MUST forward the payloads 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
@@ -527,7 +533,7 @@ Content-Length: 68
     </section2>
     <section2 topic='Broken Connections' anchor='rids-broken'>
       <p>Unreliable network communications or client constraints can result in broken connections. The connection manager SHOULD remember the 'rid' and the associated HTTP response body of the client's most recent requests which were not session pause requests (see <link url="#inactive">Inactivity</link>) and which did not result in an HTTP or binding error. The number of responses to non-pause requests kept in the buffer SHOULD be either the same as the maximum number of simultaneous requests allowed by the connection manager or, if <link url="#ack">Acknowledgements</link> are being used, the number of responses that have not yet been acknowledged.</p>
-      <p>If the network connection is broken or closed before the client receives a response to a request from the connection manager, then the client MAY resend an exact copy of the original request. Whenever the connection manager receives a request with a 'rid' that it has already received, it SHOULD return an HTTP 200 (OK) response that includes the buffered copy of the original XML response to the client (i.e., a &lt;body/&gt; wrapper possessing appropriate attributes and optionally containing one or more XML stanzas or other allowable XML elements). If the original response is not available (e.g., it is no longer in the buffer), then the connection manager MUST return an 'item-not-found' terminal binding error:</p>
+      <p>If the network connection is broken or closed before the client receives a response to a request from the connection manager, then the client MAY resend an exact copy of the original request. Whenever the connection manager receives a request with a 'rid' that it has already received, it SHOULD return an HTTP 200 (OK) response that includes the buffered copy of the original XML response to the client (i.e., a &lt;body/&gt; wrapper possessing appropriate attributes and optionally containing one or more XML payloads). If the original response is not available (e.g., it is no longer in the buffer), then the connection manager MUST return an 'item-not-found' terminal binding error:</p>
       <example caption="Response not in buffer error">
 <![CDATA[HTTP/1.1 200 OK
 Content-Type: text/xml; charset=utf-8
@@ -669,7 +675,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 payloads (see <link url="#payloads">Sending and Receiving XML Payloads</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
@@ -681,11 +687,11 @@ Content-Length: 128
       xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
       <p>Note: If the response did not include either 'from' or 'secure' attributes then they MAY be sent in a subsequent response instead (see <link url="#session-create">Session Creation Response</link>). In that case the 'stream' attribute MUST also be specified.</p>
     </section2>
-    <section2 topic="Transmitting Stanzas" anchor='multi-transmit'>
+    <section2 topic="Transmitting Payloads" anchor='multi-transmit'>
-      <p>If more than one stream has been opened within a session, then all non-empty &lt;body/&gt; elements sent by the connection manager MUST include a 'stream' attribute that specifies which stream <em>all</em> the stanzas it contains belong to. The client SHOULD include a 'stream' attribute for the same purpose. The client MAY omit the 'stream' attribute if it wants the connection manager to broadcast the stanzas over all open streams. Note: A &lt;body/&gt; element MUST NOT contain different stanzas for different streams.</p>
+      <p>If more than one stream has been opened within a session, then all non-empty &lt;body/&gt; elements sent by the connection manager MUST include a 'stream' attribute that specifies which stream <em>all</em> the payloads it contains belong to. The client SHOULD include a 'stream' attribute for the same purpose. The client MAY omit the 'stream' attribute if it wants the connection manager to broadcast the payloads over all open streams. Note: A &lt;body/&gt; element MUST NOT contain different payloads for different streams.</p>
-      <p>If a stream name does not correspond to one of the session's open streams, then the receiving connection manager SHOULD return an 'item-not-found' terminal binding error, or the receiving client SHOULD terminate the session. However, if the receiving entity has only just closed the stream (and the sender might not have been aware of that when it sent the stanzas), then it MAY instead simply silently ignore any stanzas the &lt;body/&gt; element contains.</p>
+      <p>If a stream name does not correspond to one of the session's open streams, then the receiving connection manager SHOULD return an 'item-not-found' terminal binding error, or the receiving client SHOULD terminate the session. However, if the receiving entity has only just closed the stream (and the sender might not have been aware of that when it sent the payloads), then it MAY instead simply silently ignore any payloads the &lt;body/&gt; element contains.</p>
       <p>Note: Empty &lt;body/&gt; elements that do not include a 'from' or 'secure' attribute SHOULD NOT include a 'stream' attribute (since nothing is being transmitted for any stream). If such a &lt;body/&gt; element does include a 'stream' attribute then the receiving entity SHOULD ignore the attribute.</p>
-    <example caption="Client sends stanza with a stream name">
+    <example caption="Client sends payload with a stream name">
 <![CDATA[POST /webclient HTTP/1.1
 Host: httpcm.jabber.org
 Accept-Encoding: gzip, deflate
@@ -715,9 +721,9 @@ Content-Length: 185
     <body>Hi yourself!</body>
   </message>
 </body>]]></example>
-      <p>If no stream name is specified by the connection manager then the client MUST assume the stanzas are associated with the first stream (even if the first stream has been closed).</p>
+      <p>If no stream name is specified by the connection manager then the client MUST assume the payloads are associated with the first stream (even if the first stream has been closed).</p>
-      <p>If no stream name is specified by the client then the connection manager MUST broadcast the stanzas over all open streams. <note>The broadcast stanzas can be of any type.</note></p>
+      <p>If no stream name is specified by the client then the connection manager MUST broadcast the payloads over all open streams. <note>The broadcast payloads can be of any type.</note></p>
-    <example caption="Client asks for a stanza to be broadcast">
+    <example caption="Client asks for a payload to be broadcast">
 <![CDATA[POST /webclient HTTP/1.1
 Host: httpcm.jabber.org
 Accept-Encoding: gzip, deflate
@@ -733,7 +739,7 @@ Content-Length: 188
 </body>]]></example>
     </section2>
     <section2 topic='Closing a Stream' anchor='multi-close'>
-      <p>If more than one stream is open within a session, the client MAY close one open stream at any time using the procedure described in the section <link url="#terminate">Terminating the HTTP Session</link> above, taking care to specify the stream name with a 'stream' attribute. If the client closes the last stream the connection manager MUST terminate the session. If the client does not specify a stream name then the connection manager MUST close all open streams (sending any stanzas the terminate request contains to all streams), and terminate the session.</p>
+      <p>If more than one stream is open within a session, the client MAY close one open stream at any time using the procedure described in the section <link url="#terminate">Terminating the HTTP Session</link> above, taking care to specify the stream name with a 'stream' attribute. If the client closes the last stream the connection manager MUST terminate the session. If the client does not specify a stream name then the connection manager MUST close all open streams (sending any payloads the terminate request contains to all streams), and terminate the session.</p>
       <example caption="Client closes one stream">
 <![CDATA[POST /webclient HTTP/1.1
 Host: httpcm.jabber.org
@@ -772,7 +778,7 @@ Content-Length: 68
       <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 can 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>
+      <tr><td><strong>Transported Protocol Conditions</strong></td><td>Errors relating to the XML payloads <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>
     <p>Full descriptions are provided below.</p>
     <section2 topic='HTTP Conditions' anchor='errorstatus-http'>
@@ -931,7 +937,7 @@ Content-Length: 68
 <body type='error'
       xmlns='http://jabber.org/protocol/httpbind'/>]]></example>
     </section2>
-    <section2 topic='XML Stanza Conditions' anchor='errorstatus-stanza'>
+    <section2 topic='XML Payload Conditions' anchor='errorstatus-stanza'>
       <p>Application-level error conditions described in the documentation of the protocol being transported are routed to the client through the connection manager. They are transparent to the connection manager, and therefore out of scope for the transport binding defined herein.</p>
     </section2>
   </section1>
@@ -942,14 +948,16 @@ Content-Length: 68
     </section2>
   </section1>
   <section1 topic='Security Considerations' anchor='security'>
-    <section2 topic='Encryption' anchor='security-crypt'>
+    <section2 topic='Connection Between Client and BOSH Service' anchor='security-client'>
-      <p>All communications SHOULD occur over encrypted HTTP connections. Negotiation of encryption between the client and the connection manager SHOULD occur at the transport layer or the HTTP layer, not the application layer; such negotiation SHOULD follow the HTTP/SSL protocol defined in &ssl;, although MAY follow the HTTP/TLS protocol defined in &rfc2818; or the TLS Within HTTP protocol defined in &rfc2817;.</p>
+      <p>All communications between a client and a BOSH service SHOULD occur over encrypted HTTP connections. Negotiation of encryption between the client and the connection manager SHOULD occur at the transport layer or the HTTP layer, not the application layer; such negotiation SHOULD follow the HTTP/SSL protocol defined in &ssl;, although MAY follow the HTTP/TLS protocol defined in &rfc2818; or the TLS Within HTTP protocol defined in &rfc2817;.</p>
       <p>If the HTTP connection used to send the initial session request is encrypted, then all the other HTTP connections used within the session MUST also be encrypted. Furthermore, if authentication certificates are exchanged when establishing the encrypted connection that is used to send the initial session request, then the client and/or connection manager SHOULD ensure that the same authentication certificates are employed for all subsequent connections used by the session. Once such a "secure session" has been established:</p>
       <ul>
         <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 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; methods for doing so are application-specific and therefore are outside the scope of this specification.</p>
+    </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>
     </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>