draft-ietf-xmpp-core-22.txt

pwlib源码库

   addressed as <room@service> (where "room" is the name of the chat
   room and "service" is the hostname of the multi-user chat service)
   and a specific occupant of such a room could be addressed as
   <room@service/nick> (where "nick" is the occupant's room nickname).
   Many other JID types are possible (e.g., <domain/resource> could be a
   server-side script or service).

   Each allowable portion of a JID (node identifier, domain identifier,
   and resource identifier) MUST NOT be more than 1023 bytes in length,
   resulting in a maximum total size (including the '@' and '/'
   separators) of 3071 bytes.

3.2 Domain Identifier

   The domain identifier is the primary identifier and is the only
   REQUIRED element of a JID (a mere domain identifier is a valid JID).



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


   It usually represents the network gateway or "primary" server to
   which other entities connect for XML routing and data management
   capabilities.  However, the entity referenced by a domain identifier
   is not always a server, and may be a service that is addressed as a
   subdomain of a server and that provides functionality above and
   beyond the capabilities of a server (e.g., a multi-user chat service,
   a user directory, or a gateway to a foreign messaging system).

   The domain identifier for every server or service that will
   communicate over a network MAY be an IP address but SHOULD be a fully
   qualified domain name (see [DNS]).  A domain identifier MUST be an
   "internationalized domain name" as defined in [IDNA], to which the
   Nameprep [NAMEPREP] profile of stringprep [STRINGPREP] can be applied
   without failing.  Before comparing two domain identifiers, a server
   MUST (and a client SHOULD) first apply the Nameprep profile to the
   labels (as defined in [IDNA]) that make up each identifier.

3.3 Node Identifier

   The node identifier is an optional secondary identifier placed before
   the domain identifier and separated from the latter by the '@'
   character.  It usually represents the entity requesting and using
   network access provided by the server or gateway (i.e., a client),
   although it can also represent other kinds of entities (e.g., a chat
   room associated with a multi-user chat service).  The entity
   represented by a node identifier is addressed within the context of a
   specific domain; within instant messaging and presence applications
   of XMPP this address is called a "bare JID" and is of the form
   <node@domain>.

   A node identifier MUST be formatted such that the Nodeprep (Appendix
   A) profile of [STRINGPREP] can be applied to it without failing.
   Before comparing two node identifiers, a server MUST (and a client
   SHOULD) first apply the Nodeprep profile to each identifier.

3.4 Resource Identifier

   The resource identifier is an optional tertiary identifier placed
   after the domain identifier and separated from the latter by the '/'
   character.  A resource identifier may modify either a <node@domain>
   or mere <domain> address.  It usually represents a specific session,
   connection (e.g., a device or location), or object (e.g., a
   participant in a multi-user chat room) belonging to the entity
   associated with a node identifier.  A resource identifier is opaque
   to both servers and other clients, and is typically defined by a
   client implementation when it provides the information necessary to
   complete Resource Binding (Section 7) (although it may be generated
   by a server on behalf of a client), after which it is referred to as



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


   a "connected resource".  An entity MAY maintain multiple connected
   resources simultaneously, with each connected resource differentiated
   by a distinct resource identifier.

   A resource identifier MUST be formatted such that the Resourceprep
   (Appendix B) profile of [STRINGPREP] can be applied to it without
   failing.  Before comparing two resource identifiers, a server MUST
   (and a client SHOULD) first apply the Resourceprep profile to each
   identifier.

3.5 Determination of Addresses

   After SASL negotiation (Section 6) and, if appropriate, Resource
   Binding (Section 7), the receiving entity for a stream MUST determine
   the initiating entity's JID.

   For server-to-server communications, the initiating entity's JID
   SHOULD be the authorization identity, derived from the authentication
   identity as defined by the Simple Authentication and Security Layer
   (SASL) specification [SASL] if no authorization identity was
   specified during SASL negotiation (Section 6).

   For client-to-server communications, the "bare JID" (<node@domain>)
   SHOULD be the authorization identity, derived from the authentication
   identity as defined in [SASL] if no authorization identity was
   specified during SASL negotiation (Section 6); the resource
   identifier portion of the "full JID" (<node@domain/resource>) SHOULD
   be the resource identifier negotiated by the client and server during
   Resource Binding (Section 7).

   The receiving entity MUST ensure that the resulting JID (including
   node identifier, domain identifier, resource identifier, and
   separator characters) conforms to the rules and formats defined
   earlier in this section; to meet this restriction, the receiving
   entity may need to replace the JID sent by the initiating entity with
   the canonicalized JID as determined by the receiving entity.

4. XML Streams

4.1 Overview

   Two fundamental concepts make possible the rapid, asynchronous
   exchange of relatively small payloads of structured information
   between presence-aware entities: XML streams and XML stanzas.  These
   terms are defined as follows:






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


   Definition of XML Stream: An XML stream is a container for the
      exchange of XML elements between any two entities over a network.
      The start of an XML stream is denoted unambiguously by an opening
      XML <stream> tag (with appropriate attributes and namespace
      declarations), while the end of the XML stream is denoted
      unambiguously by a closing XML </stream> tag.  During the life of
      the stream, the entity that initiated it can send an unbounded
      number of XML elements over the stream, either elements used to
      negotiate the stream (e.g., to negotiate use of TLS (Section 5) or
      use of SASL (Section 6)) or XML stanzas (as defined herein,
      <message/>, <presence/>, or <iq/> elements qualified by the
      default namespace).  The "initial stream" is negotiated from the
      initiating entity (usually a client or server) to the receiving
      entity (usually a server), and can be seen as corresponding to the
      initiating entity's "session" with the receiving entity.  The
      initial stream enables unidirectional communication from the
      initiating entity to the receiving entity; in order to enable
      information exchange from the receiving entity to the initiating
      entity, the receiving entity MUST negotiate a stream in the
      opposite direction (the "response stream").

   Definition of XML Stanza: An XML stanza is a discrete semantic unit
      of structured information that is sent from one entity to another
      over an XML stream.  An XML stanza exists at the direct child
      level of the root <stream/> element and is said to be
      well-balanced if it matches production [43] content of [XML].  The
      start of any XML stanza is denoted unambiguously by the element
      start tag at depth=1 of the XML stream (e.g., <presence>), and the
      end of any XML stanza is denoted unambiguously by the
      corresponding close tag at depth=1 (e.g., </presence>).  An XML
      stanza MAY contain child elements (with accompanying attributes,
      elements, and XML character data) as necessary in order to convey
      the desired information.  The only XML stanzas defined herein are
      the <message/>, <presence/>, and <iq/> elements qualified by the
      default namespace for the stream, as described under XML Stanzas
      (Section 9); an XML element sent for the purpose of Transport
      Layer Security (TLS) negotiation (Section 5), Simple
      Authentication and Security Layer (SASL) negotiation (Section 6),
      or server dialback (Section 8) is not considered to be an XML
      stanza.

   Consider the example of a client's session with a server.  In order
   to connect to a server, a client MUST initiate an XML stream by
   sending an opening <stream> tag to the server, optionally preceded by
   a text declaration specifying the XML version and the character
   encoding supported (see Inclusion of Text Declaration (Section 11.4);
   see also Character Encoding (Section 11.5)).  Subject to local
   policies and service provisioning, the server SHOULD then reply with



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


   a second XML stream back to the client, again optionally preceded by
   a text declaration.  Once the client has completed SASL negotiation
   (Section 6), the client MAY send an unbounded number of XML stanzas
   over the stream to any recipient on the network.  When the client
   desires to close the stream, it simply sends a closing </stream> tag
   to the server (alternatively, the stream may be closed by the
   server), after which both the client and server SHOULD terminate the
   underlying connection (usually a TCP connection) as well.

   Those who are accustomed to thinking of XML in a document-centric
   manner may wish to view a client's session with a server as
   consisting of two open-ended XML documents: one from the client to
   the server and one from the server to the client.  From this
   perspective, the root <stream/> element can be considered the
   document entity for each "document", and the two "documents" are
   built up through the accumulation of XML stanzas sent over the two
   XML streams.  However, this perspective is a convenience only, and
   XMPP does not deal in documents but in XML streams and XML stanzas.

   In essence, then, an XML stream acts as an envelope for all the XML
   stanzas sent during a session.  We can represent this in a simplistic
   fashion as follows:

   |--------------------|
   | <stream>           |
   |--------------------|
   | <presence>         |
   |   <show/>          |
   | </presence>        |
   |--------------------|
   | <message to='foo'> |
   |   <body/>          |
   | </message>         |
   |--------------------|
   | <iq to='bar'>      |
   |   <query/>         |
   | </iq>              |
   |--------------------|
   | ...                |
   |--------------------|
   | </stream>          |
   |--------------------|


4.2 Binding to TCP

   Although there is no necessary coupling of an XML stream to a [TCP]
   connection (e.g., two entities could connect to each other via



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


   another mechanism such as polling over [HTTP]), this specification
   defines a binding of XMPP to TCP only.  In the context of
   client-to-server communications, a server MUST allow a client to
   share a single TCP connection for XML stanzas sent from client to
   server and from server to client.  In the context of server-to-server
   communications, a server MUST use one TCP connection for XML stanzas
   sent from the server to the peer and another TCP connection
   (initiated by the peer) for stanzas from the peer to the server, for
   a total of two TCP connections.

4.3 Stream Security

   When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as
   defined under Use of TLS (Section 5) and SASL MUST be used as defined
   under Use of SASL (Section 6).  The "initial stream" (i.e., the
   stream from the initiating entity to the receiving entity) and the
   "response stream" (i.e., the stream from the receiving entity to the
   initiating entity) MUST be secured separately, although security in
   both directions MAY be established via mechanisms that provide mutual
   authentication.  An entity SHOULD NOT attempt to send XML Stanzas
   (Section 9) over the stream before the stream has been authenticated,
   but if it does then the other entity MUST NOT accept such stanzas and
   SHOULD return a <not-authorized/> stream error and then terminate
   both the XML stream and the underlying TCP connection; note well that
   this applies to XML stanzas only (i.e., <message/>, <presence/>, and
   <iq/> elements scoped by the default namespace) and not to XML
   elements used for stream negotiation (e.g., elements used to
   negotiate use of TLS (Section 5) or Use of SASL (Section 6)).

4.4 Stream Attributes

   The attributes of the stream element are as follows:

   o  to -- The 'to' attribute SHOULD be used only in the XML stream
      header from the initiating entity to the receiving entity, and
      MUST be set to a hostname serviced by the receiving entity.  There
      SHOULD NOT be a 'to' attribute set in the XML stream header by
      which the receiving entity replies to the initiating entity;
      however, if a 'to' attribute is included, it SHOULD be silently
      ignored by the initiating entity.

   o  from -- The 'from' attribute SHOULD be used only in the XML stream
      header from the receiving entity to the initiating entity, and
      MUST be set to a hostname serviced by the receiving entity that is
      granting access to the initiating entity.  There SHOULD NOT be a
      'from' attribute on the XML stream header sent from the initiating
      entity to the receiving entity; however, if a 'from' attribute is
      included, it SHOULD be silently ignored by the receiving entity.



Saint-Andre (ed.)      Expires September 17, 2004              [Page 11]

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