draft-ietf-xmpp-im-21.txt

pwlib源码库

   Step 2 (alt): Server responds with error (username or resource not
   allowed to create session):

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

   If there is already an active resource of the same name, the server
   MUST either (1) terminate the active resource and allow the
   newly-requested session, or (2) disallow the newly-requested session
   and maintain the active resource.  Which of these the server does is
   up to the implementation, although it is RECOMMENDED to implement
   case #1.  In case #1, the server SHOULD send a <conflict/> stream
   error to the active resource, terminate the XML stream and underlying
   TCP connection for the active resource, and return a IQ stanza of
   type "result" (indicating success) to the newly-requested session.
   In case #2, the server SHOULD send a <conflict/> stanza error to the
   newly-requested session but maintain the XML stream for that
   connection so that the newly-requested session has an opportunity to
   negotiate a non-conflicting resource identifier before sending
   another request for session establishment.

   Step 2 (alt): Server informs existing active resource of resource
   conflict (case #1):

   <stream:error>
     <conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
   </stream:error>
   </stream:stream>

   Step 2 (alt): Server informs newly-requested session of resource
   conflict (case #2):

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



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


     </error>
   </iq>

   After establishing a session, a client SHOULD send initial presence
   and request its roster as described below, although these actions are
   OPTIONAL.

   Note: Before allowing the creation of instant messaging and presence
   sessions, a server MAY require prior account provisioning.  Possible
   methods for account provisioning include account creation by a server
   administrator as well as in-band account registration using the
   'jabber:iq:register' namespace; the latter method is documented by
   the Jabber Software Foundation [JSF] at <http://www.jabber.org/
   protocol/> but is out of scope for this memo.

4. Exchanging Messages

   Exchanging messages is a basic use of XMPP and is brought about when
   a user generates a message stanza that is addressed to another
   entity.  As defined under Server Rules for Handling XML Stanzas
   (Section 11), the sender's server is responsible for delivering the
   message to the intended recipient (if the recipient is on the same
   server) or for routing the message to the recipient's server (if the
   recipient is on a different server).

   For information regarding the syntax of message stanzas as well as
   their defined attributes and child elements, refer to Message Syntax
   (Section 2.1).

4.1 Specifying an Intended Recipient

   An instant messaging client SHOULD specify an intended recipient for
   a message by providing the JID of an entity other than the sender in
   the 'to' attribute of the <message/> stanza.  If the message is being
   sent in reply to a message previously received from an address of the
   form <user@domain/resource> (e.g., within the context of a chat
   session), the value of the 'to' address SHOULD be of the form
   <user@domain/resource> rather than of the form <user@domain> unless
   the sender has knowledge (via presence) that the intended recipient's
   resource is no longer available.  If the message is being sent
   outside the context of any existing chat session or received message,
   the value of the 'to' address SHOULD be of the form <user@domain>
   rather than of the form <user@domain/resource>.

4.2 Specifying a Message Type

   As noted, it is RECOMMENDED for a message stanza to possess a 'type'
   attribute whose value captures the conversational context (if any) of



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


   the message (see Type (Section 2.1.1)).

   The following example shows a valid value of the 'type' attribute:

   Example: A message of a defined type:

   <message
       to='[e-mail]'
       from='[e-mail]/balcony'
       type='chat'
       xml:lang='en'>
     <body>Wherefore art thou, Romeo?</body>
   </message>


4.3 Specifying a Message Body

   A message stanza MAY (and often will) contain a child <body/> element
   whose XML character data specifies the primary meaning of the message
   (see Body (Section 2.1.2.2)).

   Example: A message with a body:

   <message
       to='[e-mail]'
       from='[e-mail]/balcony'
       type='chat'
       xml:lang='en'>
     <body>Wherefore art thou, Romeo?</body>
     <body xml:lang='cz'>Pro&#x010D;e&#x017D; jsi ty, Romeo?</body>
   </message>


4.4 Specifying a Message Subject

   A message stanza MAY contain one or more child <subject/> elements
   specifying the topic of the message (see Subject (Section 2.1.2.1)).

   Example: A message with a subject:

   <message
       to='[e-mail]'
       from='[e-mail]/balcony'
       type='chat'
       xml:lang='en'>
     <subject>I implore you!</subject>
     <subject
         xml:lang='cz'>&#x00DA;p&#x011B;nliv&#x011B; prosim!</subject>



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


     <body>Wherefore art thou, Romeo?</body>
     <body xml:lang='cz'>Pro&#x010D;e&#x017D; jsi ty, Romeo?</body>
   </message>


4.5 Specifying a Conversation Thread

   A message stanza MAY contain a child <thread/> element specifying the
   conversation thread in which the message is situated, for the purpose
   of tracking the conversation (see Thread (Section 2.1.2.3)).

   Example: A threaded conversation:

   <message
       to='[e-mail]/orchard'
       from='[e-mail]/balcony'
       type='chat'
       xml:lang='en'>
     <body>Art thou not Romeo, and a Montague?</body>
     <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
   </message>

   <message
       to='[e-mail]/balcony'
       from='[e-mail]/orchard'
       type='chat'
       xml:lang='en'>
     <body>Neither, fair saint, if either thee dislike.</body>
     <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
   </message>

   <message
       to='[e-mail]/orchard'
       from='[e-mail]/balcony'
       type='chat'
       xml:lang='en'>
     <body>How cam'st thou hither, tell me, and wherefore?</body>
     <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
   </message>


5. Exchanging Presence Information

   Exchanging presence information is made relatively straightforward
   within XMPP by using presence stanzas.  However, we see here a
   contrast to the handling of messages: although a client MAY send
   directed presence information to another entity by including a 'to'
   address, normally presence notifications (i.e., presence stanzas of



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


   type "available" and "unavailable" with no 'to' address) are sent
   from a client to its server and then broadcasted by the server to any
   entities that are subscribed to the presence of the sending entity
   (in the terminology of RFC 2778 [IMP-MODEL], these entities are
   subscribers).  This broadcast model does not apply to
   subscription-related presence stanzas or presence stanzas of type
   "error", but to presence notifications only as defined above.  (Note:
   While presence information MAY be provided on a user's behalf by an
   automated service, normally it is provided by the user's client.)

   For information regarding the syntax of presence stanzas as well as
   their defined attributes and child elements, refer to [XMPP-CORE].

5.1 Client and Server Presence Responsibilities

5.1.1 Initial Presence

   After establishing a session, a client SHOULD send initial presence
   to the server in order to signal its availability for communications.
   As defined herein, the initial presence stanza (1) MUST possess no
   'to' address (signalling that it is meant to be broadcasted by the
   server on behalf of the client) and (2) MUST possess no 'type'
   attribute (signalling the user's availability).  After sending
   initial presence, an active resource is said to be an "available
   resource".

   Upon receiving initial presence from a client, the user's server MUST
   do the following if there is not already one or more available
   resources for the user (if there is already one or more available
   resources for the user, the server obviously does not need to send
   the presence probes, since it already possesses the requisite
   information):

   1.  Send presence probes (i.e., presence stanzas whose 'type'
       attribute is set to a value of "probe") from the full JID (e.g.,
       <[e-mail]/resource>) of the user to all contacts to which
       the user is subscribed in order to determine if they are
       available; such contacts are those for which a JID is present in
       the user's roster with the 'subscription' attribute set to a
       value of "to" or "both".  (Note: The user's server MUST NOT send
       presence probes to contacts from which the user is blocking
       inbound presence notifications, as described under Blocking
       Inbound Presence Notifications (Section 10.10).)

   2.  Broadcast initial presence from the full JID (e.g.,
       <[e-mail]/resource>) of the user to all contacts that are
       subscribed to the user's presence information; such contacts are
       those for which a JID is present in the user's roster with the



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


       'subscription' attribute set to a value of "from" or "both".
       (Note: The user's server MUST NOT broadcast initial presence to
       contacts to which the user is blocking outbound presence
       notifications, as described under Blocking Outbound Presence
       Notifications (Section 10.11).)

   In addition, the user's server MUST broadcast initial presence from
   the user's new available resource to any of the user's existing
   available resources (if any).

   Upon receiving initial presence from the user, the contact's server
   MUST deliver the user's presence stanza to the full JIDs
   (<[e-mail]/resource>) associated with all of the contact's
   available resources, but only if the user is in the contact's roster
   with a subscription state of "to" or "both" and the contact has not
   blocked inbound presence notifications from the user's bare or full
   JID (as defined under Blocking Inbound Presence Notifications
   (Section 10.10)).

   If the user's server receives a presence stanza of type "error" in
   response to the initial presence that it sent to a contact on behalf
   of the user, it SHOULD NOT send further presence updates to that
   contact (until and unless it receives a presence stanza from the
   contact).

5.1.2 Presence Broadcast

   After sending initial presence, the user MAY update its presence
   information for broadcasting at any time during its session by
   sending a presence stanza with no 'to' address and either no 'type'
   attribute or a 'type' attribute with a value of "unavailable".
   (Note: A user's client SHOULD NOT send a presence update to broadcast
   information that changes independently of the user's presence and
   availability.)

   If the presence stanza lacks a 'type' attribute (i.e., expresses
   availability), the user's server MUST broadcast the full XML of that
   presence stanza to all contacts (1) that are in the user's roster
   with a subscription type of "from" or "both", (2) to whom the user
   has not blocked outbound presence notifications, and (3) from whom
   the server has not received a presence error during the user's
   session (as well as to any of the user's other available resources).

   If the presence stanza has a 'type' attribute set to a value of
   "unavailable", the user's server MUST broadcast the full XML of that
   presence stanza to all entities that fit the above description, as
   well as to any entities to which the user has sent directed available
   presence during the user's session (if the user has not yet sent



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


   directed unavailable presence to that entity).

5.1.3 Presence Probes

   Upon receiving a presence probe from the user, the contact's server
   SHOULD reply as follows:

   1.  If the user is not in the contact's roster with a subscription
       state of "From", "From + Pending Out", or "Both" (as defined
       under Subscription States (Section 9)), the contact's server MUST
       return a presence stanza of type "error" in response to the
       presence probe (however, if a server receives a presence probe