From 68c13efb9c5fc44bc9e0496f76cd702029716db5 Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Thu, 15 Feb 2007 22:39:50 +0000 Subject: [PATCH] 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 --- xep-0124.xml | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/xep-0124.xml b/xep-0124.xml index b1fc8d90..87f0bca1 100644 --- a/xep-0124.xml +++ b/xep-0124.xml @@ -48,7 +48,7 @@ 1.5 2006-04-28 ip/psa - 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. + 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. 1.4 @@ -151,9 +151,11 @@

The following design requirements reflect the need to offer performance as close as possible to a standard TCP connection.

    -
  1. Compatible with constrained runtime environments* (e.g., mobile and browser-based clients).
    2. +
  2. Compatible with constrained runtime environments** (e.g., mobile and browser-based clients).
    3. +
  3. Enable browser-based clients to make cross-domain connections.*
    4. +
  4. Compatible with proxies that buffer partial HTTP responses.*
    5. +
  5. Compatible with HTTP/1.0.
  6. Compatible with restricted network connections (e.g., firewalls, proxies, and gateways).
    7. -
  7. Compatible with proxies that buffer partial HTTP responses.
  8. Fault tolerant (e.g., session recovers after an underlying TCP connection breaks at any stage during an HTTP request).
  9. Extensible.
  10. Consume significantly less bandwidth than polling-based protocols.
    11. @@ -164,7 +166,8 @@
  11. Protect against denial of service attacks.
  12. Multiplexing of data streams
-

*Compatibility with constrained runtime environments implies the following restrictions:

+

*Not possible to fulfill these requirements with the Comet technique.

+

**Compatibility with constrained runtime environments implies the following restrictions:

  1. Clients should not be required to have programmatic access to the headers of each HTTP request and response (e.g., cookies or status codes).
  2. The body of each HTTP request and response may be parsable XML with a single root element.
    3. @@ -723,7 +726,7 @@ Content-Length: 68

    There are four types of error and status reporting in HTTP responses:

    - + @@ -840,7 +843,7 @@ Content-Length: 68
    Condition TypeDescription
    HTTP Conditions (Depricated)The connection manager responds to an invalid request from a legacy 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.
    HTTP Conditions (Deprecated)The connection manager responds to an invalid request from a legacy 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.
    Terminal Binding ConditionsThese 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.)
    Recoverable Binding ConditionsThese 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.
    Transported Protocol ConditionsErrors relating to the XML stanzas within <body/> wrappers are, in general, defined in the documentation of the protocol being transported. They do not terminate the session.
    The error is not one of those defined herein; the connection manager SHOULD include application-specific information in the content of the <body/> wrapper.
    -

    * If the client did not include a 'ver' attribute in its session creation request then the connection manager SHOULD send a depricated HTTP Error Condition 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 depricated HTTP Error Condition instead of this terminal binding condition.

    +

    * If the client did not include a 'ver' attribute in its session creation request then the connection manager SHOULD send a deprecated HTTP Error Condition 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 deprecated HTTP Error Condition instead of this terminal binding condition.

    The following is an example of a "see-other-uri" condition:

  3. 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".

  4. Include extra HTTP headers to prevent caching or storage by any intermediary.

-

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.

+

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.