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

1.16 RC5 typos and a couple of Requirements

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@584 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Ian Paterson 2007-02-15 22:39:50 +00:00
parent 69f85683dc
commit 68c13efb9c
1 changed files with 10 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
xep-0124.xml
View File

@ -48,7 +48,7 @@
<version>1.5</version> <version>1.5</version>
<date>2006-04-28</date> <date>2006-04-28</date>
<initials>ip/psa</initials> <initials>ip/psa</initials>
<remark>Added optional Multiple Streams section; added security considerations about encrypted HTTP connections; recommended use of SSL rather than HTTP over TLS; specified that request ID values must not exceed 9007199254740991; corrected datatypes of inactivity, polling, rid, and wait attributes in the schema; added &lt;any/&gt; and &lt;anyAttribute/&gt; elements to schema to optionally support non-XMPP XML elements and attributes; depricated HTTP error codes in favor of new terminal binding conditions.</remark> <remark>Added optional Multiple Streams section; added security considerations about encrypted HTTP connections; recommended use of SSL rather than HTTP over TLS; specified that request ID values must not exceed 9007199254740991; corrected datatypes of inactivity, polling, rid, and wait attributes in the schema; added &lt;any/&gt; and &lt;anyAttribute/&gt; elements to schema to optionally support non-XMPP XML elements and attributes; deprecated HTTP error codes in favor of new terminal binding conditions.</remark>
</revision> </revision>
<revision> <revision>
<version>1.4</version> <version>1.4</version>
@ -151,9 +151,11 @@
<section1 topic='Requirements' anchor='reqs'> <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> <p>The following design requirements reflect the need to offer performance as close as possible to a standard TCP connection.</p>
<ol> <ol>
<li>Compatible with constrained runtime environments* (e.g., mobile and browser-based clients).</li> <li>Compatible with constrained runtime environments** (e.g., mobile and browser-based clients).</li>
<li>Enable browser-based clients to make cross-domain connections.*</li>
<li>Compatible with proxies that buffer partial HTTP responses.*</li>
<li>Compatible with HTTP/1.0.</li>
<li>Compatible with restricted network connections (e.g., firewalls, proxies, and gateways).</li> <li>Compatible with restricted network connections (e.g., firewalls, proxies, and gateways).</li>
<li>Compatible with proxies that buffer partial HTTP responses.</li>
<li>Fault tolerant (e.g., session recovers after an underlying TCP connection breaks at any stage during an HTTP request).</li> <li>Fault tolerant (e.g., session recovers after an underlying TCP connection breaks at any stage during an HTTP request).</li>
<li>Extensible.</li> <li>Extensible.</li>
<li>Consume significantly less bandwidth than polling-based protocols.</li> <li>Consume significantly less bandwidth than polling-based protocols.</li>
@ -164,7 +166,8 @@
<li>Protect against denial of service attacks.</li> <li>Protect against denial of service attacks.</li>
<li>Multiplexing of data streams</li> <li>Multiplexing of data streams</li>
</ol> </ol>
<p>*Compatibility with constrained runtime environments implies the following restrictions:</p> <p>*Not possible to fulfill these requirements with the Comet technique.</p>
<p>**Compatibility with constrained runtime environments implies the following restrictions:</p>
<ol> <ol>
<li>Clients should not be required to have programmatic access to the headers of each HTTP request and response (e.g., cookies or status codes).</li> <li>Clients should not be required to have programmatic access to the headers of each HTTP request and response (e.g., cookies or status codes).</li>
<li>The body of each HTTP request and response may be parsable XML with a single root element.</li> <li>The body of each HTTP request and response may be parsable XML with a single root element.</li>
@ -723,7 +726,7 @@ Content-Length: 68
<p>There are four types of error and status reporting in HTTP responses:</p> <p>There are four types of error and status reporting in HTTP responses:</p>
<table caption='Error Condition Types'> <table caption='Error Condition Types'>
<tr><th>Condition Type</th><th>Description</th></tr> <tr><th>Condition Type</th><th>Description</th></tr>
<tr><td><strong>HTTP Conditions</strong>&#32;<em>(Depricated)</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>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>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 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>
@ -840,7 +843,7 @@ Content-Length: 68
<td>The error is not one of those defined herein; the connection manager SHOULD include application-specific information in the content of the &lt;body/&gt; wrapper.</td> <td>The error is not one of those defined herein; the connection manager SHOULD include application-specific information in the content of the &lt;body/&gt; wrapper.</td>
</tr> </tr>
</table> </table>
<p>* If the client did not include a 'ver' attribute in its session creation request then the connection manager SHOULD send a <em>depricated</em>&#32;<link url="#errorstatus-http">HTTP Error Condition</link> instead of this terminal binding condition. If the connection manager did not include a 'ver' attribute in its session creation response then the client SHOULD expect it to send a <em>depricated</em> HTTP Error Condition instead of this terminal binding condition.</p> <p>* If the client did not include a 'ver' attribute in its session creation request then the connection manager SHOULD send a <em>deprecated</em>&#32;<link url="#errorstatus-http">HTTP Error Condition</link> instead of this terminal binding condition. If the connection manager did not include a 'ver' attribute in its session creation response then the client SHOULD expect it to send a <em>deprecated</em> HTTP Error Condition instead of this terminal binding condition.</p>
<p>The following is an example of a "see-other-uri" condition:</p> <p>The following is an example of a "see-other-uri" condition:</p>
<example caption="See other URI error"> <example caption="See other URI error">
<![CDATA[HTTP/1.1 200 OK <![CDATA[HTTP/1.1 200 OK
@ -960,7 +963,7 @@ Content-Length: 0]]></example>
<li><p>If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".</p></li> <li><p>If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".</p></li>
<li><p>Include extra HTTP headers to prevent caching or storage by any intermediary.</p></li> <li><p>Include extra HTTP headers to prevent caching or storage by any intermediary.</p></li>
</ol> </ol>
<p>Note: All line breaks in the bodies of the HTTP responses in the following two examples is included only to improve readability. In practice there MUST be no line breaks.</p> <p>Note: All line breaks in the bodies of the HTTP responses in the following two examples are included only to improve readability. In practice there MUST be no line breaks.</p>
<example caption="Session creation response in Script Syntax"> <example caption="Session creation response in Script Syntax">
<![CDATA[HTTP/1.1 200 OK <![CDATA[HTTP/1.1 200 OK
Content-Type: text/javascript; charset=utf-8 Content-Type: text/javascript; charset=utf-8