mirror of https://github.com/moparisthebest/xeps
1.16 RC5 typos and a couple of Requirements
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@584 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Ian Paterson
parent
69f85683dc
commit
68c13efb9c
17
xep-0124.xml
17
xep-0124.xml
|
|
@ -48,7 +48,7 @@
|
|||
<version>1.5</version>
|
||||
<date>2006-04-28</date>
|
||||
<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 <any/> and <anyAttribute/> 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 <any/> and <anyAttribute/> 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>
|
||||
<version>1.4</version>
|
||||
|
|
@ -151,9 +151,11 @@
|
|||
<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>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 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>Extensible.</li>
|
||||
<li>Consume significantly less bandwidth than polling-based protocols.</li>
|
||||
|
|
@ -164,7 +166,8 @@
|
|||
<li>Protect against denial of service attacks.</li>
|
||||
<li>Multiplexing of data streams</li>
|
||||
</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>
|
||||
<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>
|
||||
|
|
@ -723,7 +726,7 @@ Content-Length: 68
|
|||
<p>There are four types of error and status reporting in HTTP responses:</p>
|
||||
<table caption='Error Condition Types'>
|
||||
<tr><th>Condition Type</th><th>Description</th></tr>
|
||||
<tr><td><strong>HTTP Conditions</strong> <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> <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>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 <body/> 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> <body/> 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 <body/> wrapper.</td>
|
||||
</tr>
|
||||
</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> <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> <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>
|
||||
<example caption="See other URI error">
|
||||
<![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>Include extra HTTP headers to prevent caching or storage by any intermediary.</p></li>
|
||||
</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">
|
||||
<![CDATA[HTTP/1.1 200 OK
|
||||
Content-Type: text/javascript; charset=utf-8
|
||||
|
|
|
|||
Loading…
Reference in New Issue