draft-ietf-xmpp-core-22.txt

开源代码的pwlib的1.10.0版本,使用openh323的1.18.0版本毕备

Internet-Draft                 XMPP Core                      March 2004


   o  id -- The 'id' attribute SHOULD be used only in the XML stream
      header from the receiving entity to the initiating entity.  This
      attribute is a unique identifier created by the receiving entity
      to function as a session key for the initiating entity's streams
      with the receiving entity, and MUST be unique within the receiving
      application (normally a server).  Note well that the stream ID may
      be security-critical and therefore MUST be both unpredictable and
      nonrepeating (see [RANDOM] for recommendations regarding
      randomness for security purposes).  There SHOULD NOT be an 'id'
      attribute on the XML stream header sent from the initiating entity
      to the receiving entity; however, if an 'id' attribute is
      included, it SHOULD be silently ignored by the receiving entity.

   o  xml:lang -- An 'xml:lang' attribute (as defined in Section 2.12 of
      [XML]) SHOULD be included by the initiating entity on the header
      for the initial stream to specify the default language of any
      human-readable XML character data it sends over that stream.  If
      the attribute is included, the receiving entity SHOULD remember
      that value as the default for both the initial stream and the
      response stream; if the attribute is not included, the receiving
      entity SHOULD use a configurable default value for both streams,
      which it MUST communicate in the header for the response stream.
      For all stanzas sent over the initial stream, if the initiating
      entity does not include an 'xml:lang' attribute, the receiving
      entity SHOULD apply the default value; if the initiating entity
      does include an 'xml:lang' attribute, the receiving entity MUST
      NOT modify or delete it (see also xml:lang (Section 9.1.5)).  The
      value of the 'xml:lang' attribute MUST be an NMTOKEN (as defined
      in Section 2.3 of [XML]) and MUST conform to the format defined in
      RFC 3066 [LANGTAGS].

   o  version -- The presence of the version attribute set to a value of
      at least "1.0" signals support for the stream-related protocols
      (including stream features) defined in this specification.
      Detailed rules regarding generation and handling of this attribute
      are defined below.

   We can summarize as follows:

            |  initiating to receiving  |  receiving to initiating
   ---------+---------------------------+-----------------------
   to       |  hostname of receiver     |  silently ignored
   from     |  silently ignored         |  hostname of receiver
   id       |  silently ignored         |  session key
   xml:lang |  default language         |  default language
   version  |  signals XMPP 1.0 support |  signals XMPP 1.0 support





Saint-Andre (ed.)      Expires September 17, 2004              [Page 12]

Internet-Draft                 XMPP Core                      March 2004


4.4.1 Version Support

   The version of XMPP specified herein is "1.0"; in particular, this
   encapsulates the stream-related protocols (Use of TLS (Section 5),
   Use of SASL (Section 6), and Stream Errors (Section 4.7)) as well as
   the semantics of the three defined XML stanza types (<message/>,
   <presence/>, and <iq/>).  The numbering scheme for XMPP versions is
   "<major>.<minor>".  The major and minor numbers MUST be treated as
   separate integers and each number MAY be incremented higher than a
   single digit.  Thus, "XMPP 2.4" would be a lower version than "XMPP
   2.13", which in turn would be lower than "XMPP 12.3".  Leading zeros
   (e.g., "XMPP 6.01") MUST be ignored by recipients and MUST NOT be
   sent.

   The major version number should be incremented only if the stream and
   stanza formats or required actions have changed so dramatically that
   an older version entity would not be able to interoperate with a
   newer version entity if it simply ignored the elements and attributes
   it did not understand and took the actions specified in the older
   specification.  The minor version number indicates new capabilities,
   and MUST be ignored by an entity with a smaller minor version number,
   but used for informational purposes by the entity with the larger
   minor version number.  For example, a minor version number might
   indicate the ability to process a newly defined value of the 'type'
   attribute for message, presence, or IQ stanzas; the entity with the
   larger minor version number would simply note that its correspondent
   would not be able to understand that value of the 'type' attribute
   and therefore would not send it.

   The following rules apply to the generation and handling by
   implementations of the 'version' attribute within stream headers:

   1.  The initiating entity MUST set the value of the 'version'
       attribute on the initial stream header to the highest version
       number it supports (e.g., if the highest version number it
       supports is that defined in this specification, it MUST set the
       value to "1.0").

   2.  The receiving entity MUST set the value of the 'version'
       attribute on the response stream header to either the value
       supplied by the initiating entity or the highest version number
       supported by the receiving entity, whichever is lower.  The
       receiving entity MUST perform a numeric comparison on the major
       and minor version numbers, not a string match on
       "<major>.<minor>".

   3.  If the version number included in the response stream header is
       at least one major version lower than the version number included



Saint-Andre (ed.)      Expires September 17, 2004              [Page 13]

Internet-Draft                 XMPP Core                      March 2004


       in the initial stream header and newer version entities cannot
       interoperate with older version entities as described above, the
       initiating entity SHOULD generate an <unsupported-version/>
       stream error and terminate the XML stream and underlying TCP
       connection.

   4.  If either entity receives a stream header with no 'version'
       attribute, the entity MUST consider the version supported by the
       other entity to be "0.0" and SHOULD NOT include a 'version'
       attribute in the stream header it sends in reply.


4.5 Namespace Declarations

   The stream element MUST possess both a streams namespace declaration
   and a default namespace declaration (as "namespace declaration" is
   defined in the XML namespaces specification [XML-NAMES]).  For
   detailed information regarding the streams namespace and default
   namespace, see Namespace Names and Prefixes (Section 11.2).

4.6 Stream Features

   If the initiating entity includes the 'version' attribute set to a
   value of at least "1.0" in the initial stream header, the receiving
   entity MUST send a <features/> child element (prefixed by the streams
   namespace prefix) to the initiating entity in order to announce any
   stream-level features that can be negotiated (or capabilities that
   otherwise need to be advertised).  Currently this is used only to
   advertise Use of TLS (Section 5), Use of SASL (Section 6), and
   Resource Binding (Section 7) as defined herein, and for Session
   Establishment as defined in [XMPP-IM]; however, the stream features
   functionality could be used to advertise other negotiable features in
   the future.  If an entity does not understand or support some
   features, it SHOULD silently ignore them.

4.7 Stream Errors

   The root stream element MAY contain an <error/> child element that is
   prefixed by the streams namespace prefix.  The error child MUST be
   sent by a compliant entity (usually a server rather than a client) if
   it perceives that a stream-level error has occurred.

4.7.1 Rules

   The following rules apply to stream-level errors:

   o  It is assumed that all stream-level errors are unrecoverable;
      therefore, if an error occurs at the level of the stream, the



Saint-Andre (ed.)      Expires September 17, 2004              [Page 14]

Internet-Draft                 XMPP Core                      March 2004


      entity that detects the error MUST send a stream error to the
      other entity, send a closing </stream> tag, and terminate the
      underlying TCP connection.

   o  If the error occurs while the stream is being set up, the
      receiving entity MUST still send the opening <stream> tag, include
      the <error/> element as a child of the stream element, send the
      closing </stream> tag, and terminate the underlying TCP
      connection.  In this case, if the initiating entity provides an
      unknown host in the 'to' attribute (or provides no 'to' attribute
      at all), the server SHOULD provide the server's authoritative
      hostname in the 'from' attribute of the stream header sent before
      termination.


4.7.2 Syntax

   The syntax for stream errors is as follows:

   <stream:error>
     <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     <text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
       OPTIONAL descriptive text
     </text>
     [OPTIONAL application-specific condition element]
   </stream:error>

   The <error/> element:

   o  MUST contain a child element corresponding to one of the defined
      stanza error conditions defined below; this element MUST be
      qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace

   o  MAY contain a <text/> child containing XML character data that
      describes the error in more detail; this element MUST be qualified
      by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD
      possess an 'xml:lang' attribute specifying the natural language of
      the XML character data

   o  MAY contain a child element for an application-specific error
      condition; this element MUST be qualified by an
      application-defined namespace, and its structure is defined by
      that namespace

   The <text/> element is OPTIONAL.  If included, it SHOULD be used only
   to provide descriptive or diagnostic information that supplements the
   meaning of a defined condition or application-specific condition.  It
   SHOULD NOT be interpreted programmatically by an application.  It



Saint-Andre (ed.)      Expires September 17, 2004              [Page 15]

Internet-Draft                 XMPP Core                      March 2004


   SHOULD NOT be used as the error message presented to a user, but MAY
   be shown in addition to the error message associated with the
   included condition element (or elements).

4.7.3 Defined Conditions

   The following stream-level error conditions are defined:

   o  <bad-format/> -- the entity has sent XML that cannot be processed;
      this error MAY be used rather than more specific XML-related
      errors such as <bad-namespace-prefix/>, <invalid-xml/>,
      <restricted-xml/>, <unsupported-encoding/>, and
      <xml-not-well-formed/>, although the more specific errors are
      preferred.

   o  <bad-namespace-prefix/> -- the entity has sent a namespace prefix
      that is unsupported, or has sent no namespace prefix on an element
      that requires such a prefix (see XML Namespace Names and Prefixes
      (Section 11.2)).

   o  <conflict/> -- the server is closing the active stream for this
      entity because a new stream has been initiated that conflicts with
      the existing stream.

   o  <connection-timeout/> -- the entity has not generated any traffic
      over the stream for some period of time (configurable according to
      a local service policy).

   o  <host-gone/> -- the value of the 'to' attribute provided by the
      initiating entity in the stream header corresponds to a hostname
      that is no longer hosted by the server.

   o  <host-unknown/> -- the value of the 'to' attribute provided by the
      initiating entity in the stream header does not correspond to a
      hostname that is hosted by the server.

   o  <improper-addressing/> -- a stanza sent between two servers lacks
      a 'to' or 'from' attribute (or the attribute has no value).

   o  <internal-server-error/> -- the server has experienced a
      misconfiguration or an otherwise-undefined internal error that
      prevents it from servicing the stream.

   o  <invalid-from/> -- the JID or hostname provided in a 'from'
      address does not match an authorized JID or validated domain
      negotiated between servers via SASL or dialback, or between a
      client and a server via authentication and resource binding.




Saint-Andre (ed.)      Expires September 17, 2004              [Page 16]

Internet-Draft                 XMPP Core                      March 2004


   o  <invalid-id/> -- the stream ID or dialback ID is invalid or does
      not match an ID previously provided.

   o  <invalid-namespace/> -- the streams namespace name is something
      other than "http://etherx.jabber.org/streams" or the dialback
      namespace name is something other than "jabber:server:dialback"
      (see XML Namespace Names and Prefixes (Section 11.2)).

   o  <invalid-xml/> -- the entity has sent invalid XML over the stream
      to a server that performs validation (see Validation (Section
      11.3)).

   o  <not-authorized/> -- the entity has attempted to send data before
      the stream has been authenticated, or otherwise is not authorized
      to perform an action related to stream negotiation; the receiving
      entity MUST NOT process the offending stanza before sending the
      stream error.

   o  <policy-violation/> -- the entity has violated some local service
      policy; the server MAY choose to specify the policy in the <text/>
      element or an application-specific condition element.

   o  <remote-connection-failed/> -- the server is unable to properly
      connect to a remote entity that is required for authentication or
      authorization.