draft-ietf-xmpp-im-21.txt

pwlib源码库

   with a distinct language value.  The <subject/> element MUST NOT
   contain mixed content (as defined in Section 3.2.2 of [XML]).

2.1.2.2 Body

   The <body/> element contains human-readable XML character data that
   specifies the textual contents of the message; this child element is
   normally included but is OPTIONAL.  The <body/> element MUST NOT
   possess any attributes, with the exception of the 'xml:lang'
   attribute.  Multiple instances of the <body/> element MAY be included
   but only if each instance possesses an 'xml:lang' attribute with a
   distinct language value.  The <body/> element MUST NOT contain mixed
   content (as defined in Section 3.2.2 of [XML]).

2.1.2.3 Thread

   The <thread/> element contains non-human-readable XML character data
   specifying an identifier that is used for tracking a conversation
   thread (sometimes referred to as an "instant messaging session")
   between two entities.  The value of the <thread/> element is
   generated by the sender and SHOULD be copied back in any replies.  If
   used, it MUST be unique to that conversation thread within the stream
   and MUST be consistent throughout that conversation (a client that
   receives a message from the same full JID but with a different thread
   ID MUST assume that the message in question exists outside the
   context of the existing conversation thread).  The use of the
   <thread/> element is OPTIONAL and is not used to identify individual
   messages, only conversations.  A message stanza MUST NOT contain more
   than one <thread/> element.  The <thread/> element MUST NOT possess
   any attributes.  The value of the <thread/> element MUST be treated
   as opaque by entities; no semantic meaning may be derived from it,
   and only exact comparisons may be made against it.  The <thread/>
   element MUST NOT contain mixed content (as defined in Section 3.2.2
   of [XML]).

2.2 Presence Syntax

   Presence stanzas are used qualified by the 'jabber:client' or
   'jabber:server' namespace to express an entity's current network
   availability (offline or online, along with various sub-states of the
   latter and optional user-defined descriptive text), and to notify
   other entities of that availability.  Presence stanzas are also used
   to negotiate and manage subscriptions to the presence of other
   entities.





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


2.2.1 Types of Presence

   The 'type' attribute of a presence stanza is OPTIONAL.  A presence
   stanza that does not possess a 'type' attribute is used to signal to
   the server that the sender is online and available for communication.
   If included, the 'type' attribute specifies a lack of availability, a
   request to manage a subscription to another entity's presence, a
   request for another entity's current presence, or an error related to
   a previously-sent presence stanza.  If included, the 'type' attribute
   MUST have one of the following values:

   o  unavailable -- Signals that the entity is no longer available for
      communication.

   o  subscribe -- The sender wishes to subscribe to the recipient's
      presence.

   o  subscribed -- The sender has allowed the recipient to receive
      their presence.

   o  unsubscribe -- The sender is unsubscribing from another entity's
      presence.

   o  unsubscribed -- The subscription request has been denied or a
      previously-granted subscription has been cancelled.

   o  probe -- A request for an entity's current presence; SHOULD be
      generated only by a server on behalf of a user.

   o  error -- An error has occurred regarding processing or delivery of
      a previously-sent presence stanza.

   For detailed information regarding presence semantics and the
   subscription model used in the context of XMPP-based instant
   messaging and presence applications, refer to Exchanging Presence
   Information (Section 5) and Managing Subscriptions (Section 6).

2.2.2 Child Elements

   As described under extended namespaces (Section 2.4), a presence
   stanza MAY contain any properly-namespaced child element.

   In accordance with the default namespace declaration, by default a
   presence stanza is qualified by the 'jabber:client' or
   'jabber:server' namespace, which defines certain allowable children
   of presence stanzas.  If the presence stanza is of type "error", it
   MUST include an <error/> child; for details, see [XMPP-CORE].  If the
   presence stanza possesses no 'type' attribute, it MAY contain any of



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


   the following child elements (note that the <status/> child MAY be
   sent in a presence stanza of type "unavailable" or, for historical
   reasons, "subscribe"):

   1.  <show/>

   2.  <status/>

   3.  <priority/>


2.2.2.1 Show

   The OPTIONAL <show/> element contains non-human-readable XML
   character data that specifies the particular availability status of
   an entity or specific resource.  A presence stanza MUST NOT contain
   more than one <show/> element.  The <show/> element MUST NOT possess
   any attributes.  If provided, the XML character data value MUST be
   one of the following (additional availability types could be defined
   through a properly-namespaced child element of the presence stanza):

   o  away -- The entity or resource is temporarily away.

   o  chat -- The entity or resource is actively interested in chatting.

   o  dnd -- The entity or resource is busy (dnd = "Do Not Disturb").

   o  xa -- The entity or resource is away for an extended period (xa =
      "eXtended Away").

   If no <show/> element is provided, the entity is assumed to be online
   and available.

2.2.2.2 Status

   The OPTIONAL <status/> element contains XML character data specifying
   a natural-language description of availability status.  It is
   normally used in conjunction with the show element to provide a
   detailed description of an availability state (e.g., "In a meeting").
   The <status/> element MUST NOT possess any attributes, with the
   exception of the 'xml:lang' attribute.  Multiple instances of the
   <status/> element MAY be included but only if each instance possesses
   an 'xml:lang' attribute with a distinct language value.

2.2.2.3 Priority

   The OPTIONAL <priority/> element contains non-human-readable XML
   character data that specifies the priority level of the resource.



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


   The value MUST be an integer between -128 and +127.  A presence
   stanza MUST NOT contain more than one <priority/> element.  The
   <priority/> element MUST NOT possess any attributes.  If no priority
   is provided, a server SHOULD consider the priority to be zero.  For
   information regarding the semantics of priority values in stanza
   routing within instant messaging and presence applications, refer to
   Server Rules for Handling XML Stanzas (Section 11).

2.3 IQ Syntax

   IQ stanzas provide a structured request-response mechanism.  The
   basic semantics of that mechanism (e.g., that the 'id' attribute is
   REQUIRED) are defined in [XMPP-CORE], whereas the specific semantics
   required to complete particular use cases are defined in all cases by
   an extended namespace (Section 2.4) (note that the 'jabber:client'
   and 'jabber:server' namespaces do not define any children of IQ
   stanzas other than the common <error/>).  This memo defines two such
   extended namespaces, one for Roster Management (Section 7) and the
   other for Blocking Communication (Section 10); however, an IQ stanza
   MAY contain structured information qualified by any extended
   namespace.

2.4 Extended Namespaces

   While the three XML stanza kinds defined in the "jabber:client" or
   "jabber:server" namespace (along with their attributes and child
   elements) provide a basic level of functionality for messaging and
   presence, XMPP uses XML namespaces to extend the stanzas for the
   purpose of providing additional functionality.  Thus a message or
   presence stanza MAY contain one or more optional child elements
   specifying content that extends the meaning of the message (e.g., an
   XHTML-formatted version of the message body), and an IQ stanza MAY
   contain one such child element.  This child element MAY have any name
   and MUST possess an 'xmlns' namespace declaration (other than
   "jabber:client", "jabber:server", or "http://etherx.jabber.org/
   streams") that defines all data contained within the child element.

   Support for any given extended namespace is OPTIONAL on the part of
   any implementation (aside from the extended namespaces defined
   herein).  If an entity does not understand such a namespace, the
   entity's expected behavior depends on whether the entity is (1) the
   recipient or (2) an entity that is routing the stanza to the
   recipient:

   Recipient: If a recipient receives a stanza that contains a child
      element it does not understand, it SHOULD ignore that specific XML
      data, i.e., it SHOULD not process it or present it to a user or
      associated application (if any).  In particular:



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


      *  If an entity receives a message or presence stanza that
         contains XML data qualified by a namespace it does not
         understand, the portion of the stanza that is in the unknown
         namespace SHOULD be ignored.

      *  If an entity receives a message stanza whose only child element
         is qualified by a namespace it does not understand, it MUST
         ignore the entire stanza.

      *  If an entity receives an IQ stanza of type "get" or "set"
         containing a child element qualified by a namespace it does not
         understand, the entity SHOULD return an IQ stanza of type
         "error" with an error condition of <service-unavailable/>.

   Router: If a routing entity (usually a server) handles a stanza that
      contains a child element it does not understand, it SHOULD ignore
      the associated XML data by passing it on untouched to the
      recipient.


3. Session Establishment

   Most instant messaging and presence applications based on XMPP are
   implemented via a client-server architecture that requires a client
   to establish a session on a server in order to engage in the expected
   instant messaging and presence activities.  However, there are
   several pre-conditions that MUST be met before a client can establish
   an instant messaging and presence session.  These are:

   1.  Stream Authentication -- a client MUST complete stream
       authentication as documented in [XMPP-CORE] before attempting to
       establish a session or send any XML stanzas.

   2.  Resource Binding -- after completing stream authentication, a
       client MUST bind a resource to the stream so that the client's
       address is of the form <user@domain/resource>, after which the
       entity is now said to be a "connected resource" in the
       terminology of [XMPP-CORE].

   If a server supports sessions, it MUST include a <session/> element
   qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace in
   the stream features it advertises to a client after the completion of
   stream authentication as defined in [XMPP-CORE]:

   Server advertises session establishment feature to client:

   <stream:stream
       xmlns='jabber:client'



Saint-Andre (ed.)      Expires September 19, 2004              [Page 11]

Internet-Draft                  XMPP IM                       March 2004


       xmlns:stream='http://etherx.jabber.org/streams'
       id='c2s_345'
       from='example.com'
       version='1.0'>
   <stream:features>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
   </stream:features>

   Upon being so informed that session establishment is required (and
   after completing resource binding), the client MUST establish a
   session if it desires to engage in instant messaging and presence
   functionality; it completes this step by sending to the server an IQ
   stanza of type "set" containing an empty <session/> child element
   qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace:

   Step 1: Client requests session with server:

   <iq to='example.com'
       type='set'
       id='sess_1'>
     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
   </iq>

   Step 2: Server informs client that session has been created:

   <iq from='example.com'
       type='result'
       id='sess_1'/>

   Upon establishing a session, a connected resource (in the terminology
   of [XMPP-CORE]) is said to be an "active resource".

   Several error conditions are possible.  For example, the server may
   encounter an internal condition that prevents it from creating the
   session, the username or authorization identity may lack permissions
   to create a session, or there may already be an active resource
   associated with a resource identifier of the same name.

   If the server encounters an internal condition that prevents it from
   creating the session, it MUST return an error.

   Step 2 (alt): Server responds with error (internal server error):

   <iq from='example.com' type='error' id='sess_1'>
     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
     <error type='wait'>
       <internal-server-error



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


           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     </error>
   </iq>

   If the username or resource is not allowed to create a session, the
   server MUST return an error (e.g., forbidden).