tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6121

 
 
 

Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence

Part 4 of 5, p. 78 to 102
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 78 
7.  A Sample Session

   The examples in this section illustrate a possible instant messaging
   and presence session.  The user is <romeo@example.net>, he has an
   available resource whose resourcepart is "orchard", and he has the
   following individuals in his roster:

   o  <juliet@example.com> (subscription="both" and she has two
      available resources, "chamber" and "balcony")

   o  <benvolio@example.net> (subscription="to")

   o  <mercutio@example.org> (subscription="from")

   First, the user completes the preconditions (stream establishment,
   TLS and SASL negotiation, and resource binding) described in
   [XMPP-CORE]; those protocol flows are not reproduced here.

   Next, the user requests his roster.

   Example 1: User requests current roster from server

   UC: <iq from='romeo@example.net/orchard'
           id='hf61v3n7'
           type='get'>
         <query xmlns='jabber:iq:roster'/>
       </iq>

   Example 2: User receives roster from server

   US: <iq id='hf61v3n7'
           to='romeo@example.net/orchard'
           type='result'>
         <query xmlns='jabber:iq:roster'>
           <item jid='juliet@example.com'
                 name='Juliet'
                 subscription='both'>
             <group>Friends</group>
           </item>
           <item jid='benvolio@example.org'
                 name='Benvolio'
                 subscription='to'/>
           <item jid='mercutio@example.org'
                 name='Mercutio'
                 subscription='from'/>
         </query>
       </iq>

Top      Up      ToC       Page 79 
   Now the user begins a presence session.

   Example 3: User sends initial presence

   UC: <presence/>

   Example 4: User's server sends presence probes to contacts with
   subscription="to" and subscription="both" on behalf of the user

   US: <presence
           from='romeo@example.net'
           to='juliet@example.com'
           type='probe'/>

   US: <presence
           from='romeo@example.net'
           to='benvolio@example.org'
           type='probe'/>

   Example 5: User's server sends initial presence to contacts with
   subscription="from" and subscription="both" on behalf of the user's
   available resource, as well as to user

   US: <presence
           from='romeo@example.net/orchard'
           to='juliet@example.com'/>

   US: <presence
           from='romeo@example.net/orchard'
           to='mercutio@example.org'/>

   US: <presence
           from='romeo@example.net/orchard'
           to='romeo@example.net'/>

   Example 6: Contacts' servers reply to presence probe on behalf of all
   available resources

   CS: <presence
           from='juliet@example.com/balcony'
           to='romeo@example.net'
           xml:lang='en'>
         <show>away</show>
         <status>be right back</status>
         <priority>0</priority>
       </presence>

Top      Up      ToC       Page 80 
   CS: <presence
           from='juliet@example.com/chamber'
           to='romeo@example.net'>
         <priority>1</priority>
       </presence>

   CS: <presence
           from='benvolio@example.org/pda'
           to='romeo@example.net'
           xml:lang='en'>
         <show>dnd</show>
         <status>gallivanting</status>
       </presence>

   Example 7: Contacts' servers deliver user's initial presence to all
   available resources

   CS: <presence
           from='romeo@example.net/orchard'
           to='juliet@example.com'/>

   CS: <presence
           from='romeo@example.net/orchard'
           to='juliet@example.com'/>

   CS: <presence
           from='romeo@example.net/orchard'
           to='mercutio@example.org'/>

   Example 8: User sends directed presence to another user not in his
   roster

   UC: <presence
           from='romeo@example.net/orchard'
           to='nurse@example.com'
           xml:lang='en'>
         <show>dnd</show>
         <status>courting Juliet</status>
         <priority>0</priority>
       </presence>

   Now the user engages in a chat session with one of his contacts.

Top      Up      ToC       Page 81 
   Example 9: A threaded conversation

   CC: <message
           from='juliet@example.com/balcony'
           to='romeo@example.net'
           type='chat'
           xml:lang='en'>
         <body>My ears have not yet drunk a hundred words</body>
         <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
       </message>

   CC: <message
           from='juliet@example.com/balcony'
           to='romeo@example.net'
           type='chat'
           xml:lang='en'>
         <body>Of that tongue's utterance, yet I know the sound:</body>
         <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
       </message>

   CC: <message
           from='juliet@example.com/balcony'
           to='romeo@example.net'
           type='chat'
           xml:lang='en'>
         <body>Art thou not Romeo, and a Montague?</body>
         <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
       </message>

   UC: <message
           from='romeo@example.net/orchard'
           to='juliet@example.com/balcony'
           type='chat'
           xml:lang='en'>
         <body>Neither, fair saint, if either thee dislike.</body>
         <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
       </message>

   CC: <message
           from='juliet@example.com/balcony'
           to='romeo@example.net/orchard'
           type='chat'
           xml:lang='en'>
         <body>How cam'st thou hither, tell me, and wherefore?</body>
         <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
       </message>

   And so on.

Top      Up      ToC       Page 82 
   The user can also send subsequent presence broadcast.

   Example 10: User sends updated available presence for broadcast

   UC: <presence xml:lang='en'>
         <show>away</show>
         <status>I shall return!</status>
         <priority>1</priority>
       </presence>

   Example 11: User's server broadcasts updated presence to the contacts
   who have a subscription of type "both" or "from" (but not to the
   entity to which the user sent directed presence)

   US: <presence
           from='romeo@example.net/orchard'
           to='juliet@example.com'
           xml:lang='en'>
         <show>away</show>
         <status>I shall return!</status>
         <priority>1</priority>
       </presence>

   US: <presence
           from='romeo@example.net/orchard'
           to='mercutio@example.org'
           xml:lang='en'>
         <show>away</show>
         <status>I shall return!</status>
         <priority>1</priority>
       </presence>

   Example 12: Contacts' servers deliver updated presence

   CS: <presence
           from='romeo@example.net/orchard'
           to='juliet@example.com'
           xml:lang='en'>
         <show>away</show>
         <status>I shall return!</status>
         <priority>1</priority>
       </presence>

Top      Up      ToC       Page 83 
   CS: <presence
           from='romeo@example.net/orchard'
           to='juliet@example.com'
           xml:lang='en'>
         <show>away</show>
         <status>I shall return!</status>
         <priority>1</priority>
       </presence>

   CS: <presence
           from='romeo@example.net/orchard'
           to='mercutio@example.org'
           xml:lang='en'>
         <show>away</show>
         <status>I shall return!</status>
         <priority>1</priority>
       </presence>

   Example 13: One of the contact's resources broadcasts unavailable
   notification

   CC: <presence from='juliet@example.com/chamber' type='unavailable'/>

   Example 14: Contact's server sends unavailable notification to user

   CS: <presence
           from='juliet@example.com/chamber'
           to='romeo@example.net'
           type='unavailable'/>

   Now the user ends his presence session.

   Example 15: User sends unavailable notification

   UC: <presence type='unavailable' xml:lang='en'>
         <status>gone home</status>
       </presence>

   Example 16: User's server broadcasts unavailable notification to
   contacts as well as to the entity to whom the user sent directed
   presence

Top      Up      ToC       Page 84 
   US: <presence
           from='romeo@example.net/orchard'
           to='juliet@example.com'
           type='unavailable'
           xml:lang='en'>
         <status>gone home</status>
       </presence>

   US: <presence
           from='romeo@example.net/orchard'
           to='mercutio@example.org'
           type='unavailable'
           xml:lang='en'>
         <status>gone home</status>
       </presence>

   US: <presence
           from='romeo@example.net/orchard'
           to='nurse@example.com'
           type='unavailable'
           xml:lang='en'>
         <status>gone home</status>
       </presence>

   Finally the user closes his stream and the server responds in kind.

   Example 17: User closes stream

   UC: </stream:stream>

   Example 18: User's server closes stream

   US: </stream:stream>

   THE END

8.  Server Rules for Processing XML Stanzas

   Basic server rules for processing XML stanzas are defined in
   [XMPP-CORE], and the reader is referred to that specification for
   underlying rules and security implications.  This section defines
   supplementary rules for XMPP instant messaging and presence servers.

   Some delivery rules defined in this section specify the use of
   "offline storage", i.e., the server's act of storing a message stanza
   on behalf of the user and then delivering it when the user next
   becomes available.  For recommendations regarding offline message
   storage, refer to [XEP-0160].

Top      Up      ToC       Page 85 
8.1.  General Considerations

   [XMPP-CORE] discusses general considerations for stanza delivery, in
   particular the tradeoffs between (i) providing an acceptable level of
   service regarding stanza delivery and (ii) preventing directory
   harvesting attacks and presence leaks.  However, the concept of a
   directory harvesting attack does not apply if a contact is known to
   and trusted by a user (because the contact is in the user's roster as
   described under Section 2).  Similarly, the concept of a presence
   leak does not apply if a contact is authorized to know a user's
   presence (by means of a presence subscription as described under
   Section 3) or if the user has voluntarily sent presence to an entity
   (by means of directed presence as described under Section 4.6).
   Therefore, in cases where the following sections guard against
   directory harvesting attacks and presence leaks by providing an
   alternative of (a) silently ignoring a stanza or (b) returning an
   error, a server SHOULD return an error if the originating entity is
   in the user's roster (when the error would reveal whether the user's
   account exists) or is authorized to receive presence from the user or
   has received directed presence from the user (when the error would
   reveal the presence of a user's resource).

      Security Warning: All of the stanza processing rules described
      below are defined with the understanding that they will be applied
      subject to enforcement of relevant privacy and security policies,
      such as those deployed by means of [XEP-0016] or [XEP-0191].  The
      conformance language (MUST, SHOULD, etc.) in the following
      sections is not meant to override any such local service policies.

8.2.  No 'to' Address

   If the stanza possesses no 'to' attribute, the rules defined in
   [XMPP-CORE] apply.

8.3.  Remote Domain

   If the domainpart of the address contained in the 'to' attribute of
   an outbound stanza does not match a configured domain of the server
   itself, then the rules provided in Section 10.4 of [XMPP-CORE] apply.

      Interoperability Note: RFC 3921 specified how to use the _im._xmpp
      and _pres._xmpp SRV records [IMP-SRV] as a fallback method for
      discovering whether a remote instant messaging and presence
      service communicates via XMPP.  Because those SRV records have not
      been widely deployed, this document no longer specifies their use,
      and new implementations are not encouraged.

Top      Up      ToC       Page 86 
8.4.  Local Domain

   If the domainpart of the JID contained in the 'to' attribute matches
   one of the configured domains of the server, the domain is serviced
   by the server itself (not by a specialized local service), and the
   JID is of the form <domainpart> or <domainpart/resourcepart>, the
   rules defined in [XMPP-CORE] apply.

8.5.  Local User

   If the 'to' address specifies a bare JID <localpart@domainpart> or
   full JID <localpart@domainpart/resourcepart> where the domainpart of
   the JID matches a configured domain that is serviced by the server
   itself, the server MUST proceed as follows.

8.5.1.  No Such User

   If the user account identified by the 'to' attribute does not exist,
   how the stanza is processed depends on the stanza type.

   o  For an IQ stanza, the server MUST return a <service-unavailable/>
      stanza error to the sender.

   o  For a message stanza, the server MUST either (a) silently ignore
      the message or (b) return a <service-unavailable/> stanza error to
      the sender.

   o  For a presence stanza with no 'type' attribute or a 'type'
      attribute of "unavailable", the server MUST silently ignore the
      stanza.

   o  For a presence stanza of type "subscribe", "subscribed",
      "unsubscribe", or "unsubscribed", the server MUST silently ignore
      the stanza.

   o  For a presence stanza of type "probe", the server MUST either (a)
      silently ignore the stanza or (b) return a presence stanza of type
      "unsubscribed".

8.5.2.  localpart@domainpart

   If the JID contained in the 'to' attribute is of the form
   <localpart@domainpart>, then the server MUST adhere to the following
   rules.

Top      Up      ToC       Page 87 
8.5.2.1.  Available or Connected Resources

   If there is at least one available resource or connected resource,
   how the stanza is processed depends on the stanza type.

8.5.2.1.1.  Message

   For a message stanza of type "normal":

   o  If all of the available resources have a negative presence
      priority then the server SHOULD either (a) store the message
      offline for later delivery or (b) return a stanza error to the
      sender, which SHOULD be <service-unavailable/>.

   o  If there is one available resource with a non-negative presence
      priority then the server MUST deliver the message to that
      resource.

   o  If there is more than one resource with a non-negative presence
      priority then the server MUST either (a) deliver the message to
      the "most available" resource or resources (according to the
      server's implementation-specific algorithm, e.g., treating the
      resource or resources with the highest presence priority as "most
      available") or (b) deliver the message to all of the non-negative
      resources.

   For a message stanza of type "chat":

   o  If the only available resource has a negative presence priority
      then the server SHOULD either (a) store the message offline for
      later delivery or (b) return a stanza error to the sender, which
      SHOULD be <service-unavailable/>.

   o  If the only available resource has a non-negative presence
      priority then the server MUST deliver the message to that
      resource.

   o  If there is more than one resource with a non-negative presence
      priority then the server MUST either (a) deliver the message to
      the "most available" resource or resources (according to the
      server's implementation-specific algorithm, e.g., treating the
      resource or resources with the highest presence priority as "most
      available") or (b) deliver the message to all of the non-negative
      resources that have opted in to receive chat messages.

   For a message stanza of type "groupchat", the server MUST NOT deliver
   the stanza to any of the available resources but instead MUST return
   a stanza error to the sender, which SHOULD be <service-unavailable/>.

Top      Up      ToC       Page 88 
   For a message stanza of type "headline":

   o  If the only available resource has a negative presence priority
      then the server MUST silently ignore the stanza.

   o  If the only available resource has a non-negative presence
      priority then the server MUST deliver the message to that
      resource.

   o  If there is more than one resource with a non-negative presence
      priority then the server MUST deliver the message to all of the
      non-negative resources.

   For a message stanza of type "error", the server MUST silently ignore
   the message.

   However, for any message type the server MUST NOT deliver the stanza
   to any available resource with a negative priority; if the only
   available resource has a negative priority, the server SHOULD handle
   the message as if there were no available resources or connected
   resources as described under Section 8.5.2.2.

   In all cases, the server MUST NOT rewrite the 'to' attribute (i.e.,
   it MUST leave it as <localpart@domainpart> rather than change it to
   <localpart@domainpart/resourcepart>).

8.5.2.1.2.  Presence

   For a presence stanza with no type or of type "unavailable", the
   server MUST deliver it to all available resources.

   For a presence stanza of type "subscribe", "subscribed",
   "unsubscribe", or "unsubscribed", the server MUST adhere to the rules
   defined under Section 3 and summarized under Appendix A.

   For a presence stanza of type "probe", the server MUST handle it
   directly as described under Section 4.3.

   In all cases, the server MUST NOT rewrite the 'to' attribute (i.e.,
   it MUST leave it as <localpart@domainpart> rather than change it to
   <localpart@domainpart/resourcepart>).

8.5.2.1.3.  IQ

   For an IQ stanza, the server itself MUST reply on behalf of the user
   with either an IQ result or an IQ error, and MUST NOT deliver the IQ
   stanza to any of the user's available resources.  Specifically, if
   the semantics of the qualifying namespace define a reply that the

Top      Up      ToC       Page 89 
   server can provide on behalf of the user, then the server MUST reply
   to the stanza on behalf of the user by returning either an IQ stanza
   of type "result" or an IQ stanza of type "error" that is appropriate
   to the original payload; if not, then the server MUST reply with a
   <service-unavailable/> stanza error.

8.5.2.2.  No Available or Connected Resources

   If there are no available resources or connected resources associated
   with the user, how the stanza is processed depends on the stanza
   type.

8.5.2.2.1.  Message

   For a message stanza of type "normal" or "chat", the server SHOULD
   either (a) add the message to offline storage or (b) return a stanza
   error to the sender, which SHOULD be <service-unavailable/>.

   For a message stanza of type "groupchat", the server MUST return an
   error to the sender, which SHOULD be <service-unavailable/>.

   For a message stanza of type "headline" or "error", the server MUST
   silently ignore the message.

8.5.2.2.2.  Presence

   For a presence stanza with no type or of type "unavailable", the
   server SHOULD silently ignore the stanza by not storing it for later
   delivery and not replying to it on behalf of the user.

   For a presence stanza of type "subscribe", "subscribed",
   "unsubscribe", or "unsubscribed", the server MUST adhere to the rules
   defined under Section 3 and summarized under Appendix A.

   For a presence stanza of type "probe", the server MUST handle it
   directly as described under Section 4.3.

8.5.2.2.3.  IQ

   For an IQ stanza, the server itself MUST reply on behalf of the user
   with either an IQ result or an IQ error.  Specifically, if the
   semantics of the qualifying namespace define a reply that the server
   can provide on behalf of the user, then the server MUST reply to the
   stanza on behalf of the user by returning either an IQ stanza of type
   "result" or an IQ stanza of type "error" that is appropriate to the
   original payload; if not, then the server MUST reply with a <service-
   unavailable/> stanza error.

Top      Up      ToC       Page 90 
8.5.3.  localpart@domainpart/resourcepart

   If the domainpart of the JID contained in the 'to' attribute of an
   inbound stanza matches one of the configured domains of the server
   itself and the JID contained in the 'to' attribute is of the form
   <localpart@domainpart/resourcepart>, then the server MUST adhere to
   the following rules.

8.5.3.1.  Resource Matches

   If an available resource or connected resource exactly matches the
   full JID, how the stanza is processed depends on the stanza type.

   o  For an IQ stanza of type "get" or "set", if the intended recipient
      does not share presence with the requesting entity either by means
      of a presence subscription of type "both" or "from" or by means of
      directed presence, then the server SHOULD NOT deliver the IQ
      stanza but instead SHOULD return a <service-unavailable/> stanza
      error to the requesting entity.  This policy helps to prevent
      presence leaks (see Section 11).

   o  For an IQ stanza of type "result" or "error", the server MUST
      deliver the stanza to the resource.

   o  For a message stanza, the server MUST deliver the stanza to the
      resource.

   o  For a presence stanza with no 'type' attribute or a 'type'
      attribute of "unavailable", the server MUST deliver the stanza to
      the resource.

   o  For a presence stanza of type "subscribe", "subscribed",
      "unsubscribe", or "unsubscribed", the server MUST follow the
      guidelines provided under Section 3.

   o  For a presence stanza of type "probe", the server MUST follow the
      guidelines provided under Section 4.3.

8.5.3.2.  No Resource Matches

   If no available resource or connected resource exactly matches the
   full JID, how the stanza is processed depends on the stanza type.

Top      Up      ToC       Page 91 
8.5.3.2.1.  Message

   For a message stanza of type "normal", "groupchat", or "headline",
   the server MUST either (a) silently ignore the stanza or (b) return
   an error stanza to the sender, which SHOULD be <service-
   unavailable/>.

   For a message stanza of type "chat":

   o  If there is no available or connected resource, the server MUST
      either (a) store the message offline for later delivery or (b)
      return an error stanza to the sender, which SHOULD be <service-
      unavailable/>.

   o  If all of the available resources have a negative presence
      priority then the server SHOULD (a) store the message offline for
      later delivery or (b) return a stanza error to the sender, which
      SHOULD be <service-unavailable/>.

   o  If there is one available resource with a non-negative presence
      priority then the server MUST deliver the message to that
      resource.

   o  If there is more than one resource with a non-negative presence
      priority then the server MUST either (a) deliver the message to
      the "most available" resource or resources (according to the
      server's implementation-specific algorithm, e.g., treating the
      resource or resources with the highest presence priority as "most
      available") or (b) deliver the message to all of the non-negative
      resources that have opted in to receive chat messages.

   For a message stanza of type "error", the server MUST silently ignore
   the stanza.

8.5.3.2.2.  Presence

   For a presence stanza with no 'type' attribute or a 'type' attribute
   of "unavailable", the server MUST silently ignore the stanza.

   For a presence stanza of type "subscribe", the server MUST follow the
   guidelines provided under Section 3.1.3.

   For a presence stanza of type "subscribed", "unsubscribe", or
   "unsubscribed", the server MUST ignore the stanza.

   For a presence stanza of type "probe", the server MUST follow the
   guidelines provided under Section 4.3.

Top      Up      ToC       Page 92 
8.5.3.2.3.  IQ

   For an IQ stanza, the server MUST return a <service-unavailable/>
   stanza error to the sender.

8.5.4.  Summary of Message Delivery Rules

   The following table summarizes the message (not stanza) delivery
   rules described earlier in this section.  The left column shows
   various combinations of conditions (non-existent account, no active
   resources, only one resource and it has a negative presence priority,
   only one resource and it has a non-negative presence priority, or
   more than one resource and each one has a non-negative presence
   priority) and 'to' addresses (bare JID, full JID matching an
   available resource, or full JID matching no available resource).  The
   subsequent columns list the four primary message types (normal, chat,
   groupchat, or headline) along with six possible delivery options:
   storing the message offline (O), bouncing the message with a stanza
   error (E), silently ignoring the message (S), delivering the message
   to the resource specified in the 'to' address (D), delivering the
   message to the "most available" resource or resources according to
   the server's implementation-specific algorithm, e.g., treating the
   resource or resources with the highest presence priority as "most
   available" (M), or delivering the message to all resources with non-
   negative presence priority (A -- where for chat messages "all
   resources" can mean the set of resources that have explicitly opted
   in to receiving every chat message).  The '/' character stands for
   "exclusive or".  The server SHOULD observe the rules given in section
   8.1 when choosing which action to take for a particular message.

Top      Up      ToC       Page 93 
   Table 1: Message Delivery Rules

   +----------------------------------------------------------+
   | Condition        | Normal | Chat  | Groupchat | Headline |
   +----------------------------------------------------------+
   | ACCOUNT DOES NOT EXIST                                   |
   |  bare            |  S/E   |  S/E  |     E     |    S     |
   |  full            |  S/E   |  S/E  |    S/E    |   S/E    |
   +----------------------------------------------------------+
   | ACCOUNT EXISTS, BUT NO ACTIVE RESOURCES                  |
   |  bare            |  O/E   |  O/E  |     E     |    S     |
   |  full (no match) |  S/E   |  O/E  |    S/E    |   S/E    |
   +----------------------------------------------------------+
   | 1+ NEGATIVE RESOURCES BUT ZERO NON-NEGATIVE RESOURCES    |
   |  bare            |  O/E   |  O/E  |     E     |    S     |
   |  full match      |   D    |   D   |     D     |    D     |
   |  full no match   |  S/E   |  O/E  |    S/E    |   S/E    |
   +----------------------------------------------------------+
   | 1 NON-NEGATIVE RESOURCE                                  |
   |  bare            |   D    |   D   |     E     |    D     |
   |  full match      |   D    |   D   |     D     |    D     |
   |  full no match   |  S/E   |   D   |    S/E    |   S/E    |
   +----------------------------------------------------------+
   | 1+ NON-NEGATIVE RESOURCES                                |
   |  bare            |  M/A   |  M/A* |     E     |    A     |
   |  full match      |   D    |  D/A* |     D     |    D     |
   |  full no match   |  S/E   |  M/A* |    S/E    |   S/E    |
   +----------------------------------------------------------+

      * For messages of type "chat", a server SHOULD NOT act in
      accordance with option (A) unless clients can explicitly opt in to
      receiving all chat messages; however, methods for opting in are
      outside the scope of this specification.

9.  Handling of URIs

   The addresses of XMPP entities as used in communication over an XMPP
   network (e.g., in the 'from' and 'to' addresses of an XML stanza)
   MUST NOT be prepended with a Uniform Resource Identifier [URI]
   scheme.

   However, an application that is external to XMPP itself (e.g., a page
   on the World Wide Web) might need to identify an XMPP entity either
   as a URI or as an Internationalized Resource Identifier [IRI], and an
   XMPP client might need to interact with such an external application
   (for example, an XMPP client might be invoked by clicking a link
   provided on a web page).  In the context of such interactions, XMPP
   clients are encouraged to handle addresses that are encoded as

Top      Up      ToC       Page 94 
   "xmpp:" URIs and IRIs as specified in [XMPP-URI] and further
   described in [XEP-0147].  Although XMPP clients are also encouraged
   to handle addresses that are encoded as "im:" URIs as specified in
   [CPIM] and "pres:" URIs as specified in [CPP], they can do so by
   removing the "im:" or "pres:" scheme and entrusting address
   resolution to the server as specified under Section 8.3.

10.  Internationalization Considerations

   For internationalization considerations, refer to the relevant
   section of [XMPP-CORE].

11.  Security Considerations

   Core security considerations for XMPP are provided in Section 13 of
   [XMPP-CORE], including discussion of channel encryption,
   authentication, information leaks, denial-of-service attacks, and
   interdomain federation.

   Section 13.1 of [XMPP-CORE] outlines the architectural roles of
   clients and servers in typical deployments of XMPP, and discusses the
   security properties associated with those roles.  These roles have an
   impact on the security of instant messages, presence subscriptions,
   and presence notifications as described in this document.  In
   essence, an XMPP user registers (or has provisioned) an account on an
   XMPP server and therefore places some level of trust in the server to
   complete various tasks on the user's behalf, enforce security
   policies, etc.  Thus it is the server's responsibility to:

   1.  Preferably mandate the use of channel encryption for
       communication with local clients and remote servers.

   2.  Authenticate any client that wishes to access the user's account.

   3.  Process XML stanzas to and from clients that have authenticated
       as the user (specifically with regard to instant messaging and
       presence functionality, store the user's roster, process inbound
       and outbound subscription requests and responses, generate and
       handle presence probes, broadcast outbound presence
       notifications, route outbound messages, and deliver inbound
       messages and presence notifications).

   As discussed in Sections 13.1 and 13.4 of [XMPP-CORE], even if the
   server fulfills the foregoing responsibilities, the client does not
   have any assurance that stanzas it might exchange with other clients
   (whether on the same server or a remote server) are protected for all
   hops along the XMPP communication path, or within the server itself.
   It is the responsibility of the client to use an appropriate

Top      Up      ToC       Page 95 
   technology for encryption and signing of XML stanzas if it wishes to
   ensure end-to-end confidentiality and integrity of its
   communications.

   Additional considerations that apply only to instant messaging and
   presence applications of XMPP are defined in several places within
   this document; specifically:

   o  When a server processes an inbound presence stanza of type "probe"
      whose intended recipient is a user associated with one of the
      server's configured domains, the server MUST NOT reveal the user's
      presence if the sender is an entity that is not authorized to
      receive that information as determined by presence subscriptions
      (see Section 4).

   o  A user's server MUST NOT leak the user's network availability to
      entities who are not authorized to know the user's presence.  In
      XMPP itself, authorization takes the form of an explicit
      subscription from a contact to the user (as described under
      Section 3).  However, some XMPP deployments might consider an
      entity to be authorized if there is an existing trust relationship
      between the entity and the user who is generating presence
      information (as an example, a corporate deployment of XMPP might
      automatically add the user's presence information to a private
      directory of employees if the organization mandates the sharing of
      presence information as part of an employment agreement).

   o  When a server processes an outbound presence stanza with no type
      or of type "unavailable", it MUST follow the rules defined under
      Section 4 in order to ensure that such presence information is not
      sent to entities that are not authorized to know such information.

   o  A client MAY ignore the <status/> element when contained in a
      presence stanza of type "subscribe", "unsubscribe", "subscribed",
      or "unsubscribed"; this can help prevent "presence subscription
      spam".

12.  Conformance Requirements

   This section describes a protocol feature set that summarizes the
   conformance requirements of this specification.  This feature set is
   appropriate for use in software certification, interoperability
   testing, and implementation reports.  For each feature, this section
   provides the following information:

   o  A human-readable name

   o  An informational description

Top      Up      ToC       Page 96 
   o  A reference to the particular section of this document that
      normatively defines the feature

   o  Whether the feature applies to the Client role, the Server role,
      or both (where "N/A" signifies that the feature is not applicable
      to the specified role)

   o  Whether the feature MUST or SHOULD be implemented, where the
      capitalized terms are to be understood as described in [KEYWORDS]

   The feature set specified here attempts to adhere to the concepts and
   formats proposed by Larry Masinter within the IETF's NEWTRK Working
   Group in 2005, as captured in [INTEROP].  Although this feature set
   is more detailed than called for by [REPORTS], it provides a suitable
   basis for the generation of implementation reports to be submitted in
   support of advancing this specification from Proposed Standard to
   Draft Standard in accordance with [PROCESS].

   Feature:  message-body
   Description:  Support the <body/> child element of the <message/>
      stanza.
   Section:  Section 5.2.3
   Roles:  Client MUST, Server N/A.

   Feature:  message-subject
   Description:  Support the <subject/> child element of the <message/>
      stanza.
   Section:  Section 5.2.4
   Roles:  Client SHOULD, Server N/A.

   Feature:  message-thread
   Description:  Support the <thread/> child element of the <message/>
      stanza.
   Section:  Section 5.2.5
   Roles:  Client SHOULD, Server N/A.

   Feature:  message-type-support
   Description:  Support reception of messages of type "normal", "chat",
      "groupchat", "headline", and "error".
   Section:  Section 5.2.2
   Roles:  Client SHOULD, Server N/A.

   Feature:  message-type-deliver
   Description:  Appropriately deliver messages of type "normal",
      "chat", "groupchat", "headline", and "error".
   Section:  Section 8
   Roles:  Client N/A, Server SHOULD.

Top      Up      ToC       Page 97 
   Feature:  presence-notype
   Description:  Treat a presence stanza with no 'type' attribute as
      indicating availability.
   Section:  Section 4.7.1
   Roles:  Client MUST, Server MUST.

   Feature:  presence-probe
   Description:  Send and receive presence stanzas with a 'type'
      attribute of "probe" for the discovery of presence information.
   Section:  Section 4.7.1
   Roles:  Client N/A, Server MUST.

   Feature:  presence-sub-approval
   Description:  Treat an outbound presence stanza of type "subscribed"
      as the act of approving a presence subscription request previously
      received from another entity, and treat an inbound presence stanza
      of type "subscribed" as a subscription approval from another
      entity.
   Section:  Section 3.1
   Roles:  Client MUST, Server MUST.

   Feature:  presence-sub-cancel
   Description:  Treat an outbound presence stanza of type
      "unsubscribed" as the act of denying a subscription request
      received from another entity or canceling a subscription approval
      previously granted to another entity, and treat an inbound
      presence stanza of type "unsubscribed" as an subscription denial
      or cancellation from another entity.
   Section:  Section 3.2
   Roles:  Client MUST, Server MUST.

   Feature:  presence-sub-preapproval
   Description:  Treat an outbound presence stanza of type "subscribed"
      in certain circumstances as the act of pre-approving a
      subscription request received from another entity; this includes
      support for the 'approved' attribute of the <item/> element within
      the 'jabber:iq:roster' namespace.
   Section:  Section 3.4
   Roles:  Client MAY, Server MAY.

   Feature:  presence-sub-request
   Description:  Treat an outbound presence stanza of type "subscribe"
      as the act of requesting a subscription to the presence
      information of another entity, and treat an inbound presence
      stanza of type "subscribe" as a presence subscription request from
      another entity.
   Section:  Section 3.1
   Roles:  Client MUST, Server MUST.

Top      Up      ToC       Page 98 
   Feature:  presence-sub-unsubscribe
   Description:  Treat an outbound presence stanza of type "unsubscribe"
      as the act of unsubscribing from another entity, and treat an
      inbound presence stanza of type "unsubscribe" as an unsubscribe
      notification from another entity.
   Section:  Section 3.3
   Roles:  Client MUST, Server MUST.

   Feature:  presence-unavailable
   Description:  Treat a presence stanza with a 'type' attribute of
      "unavailable" as indicating lack of availability.
   Section:  Section 4.7.1
   Roles:  Client MUST, Server MUST.

   Feature:  roster-get
   Description:  Treat an IQ stanza of type "get" containing an empty
      <query/> element qualified by the 'jabber:iq:roster' namespace as
      a request to retrieve the roster information associated with an
      account on a server.
   Section:  Section 2.1.3
   Roles:  Client MUST, Server MUST.

   Feature:  roster-set
   Description:  Treat an IQ stanza of type "set" containing a <query/>
      element qualified by the 'jabber:iq:roster' namespace as a request
      to add or update the item contained in the <query/> element.
   Section:  Section 2.1.5
   Roles:  Client MUST, Server MUST.

   Feature:  roster-push
   Description:  Send a roster push to each interested resource whenever
      the server-side representation of the roster information
      materially changes, or handle such a push when received from the
      server.
   Section:  Section 2.1.6
   Roles:  Client MUST, Server MUST.

   Feature:  roster-version
   Description:  Treat the 'ver' attribute of the <query/> element
      qualified by the 'jabber:iq:roster' namespace as an identifier of
      the particular version of roster information being sent or
      received.
   Section:  Section 2.1.1
   Roles:  Client SHOULD, Server MUST.

Top      Up      ToC       Page 99 
13.  References

13.1.  Normative References

   [DELAY]    Saint-Andre, P., "Delayed Delivery", XSF XEP 0203,
              September 2009.

   [KEYWORDS]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [XML]      Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J.,
              and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", World Wide Web Consortium
              Recommendation REC-xml-20081126, November 2008,
              <http://www.w3.org/TR/2008/REC-xml-20081126>.

   [XML-NAMES]
              Bray, T., Hollander, D., and A. Layman, "Namespaces in
              XML", W3C REC-xml-names, January 1999,
              <http://www.w3.org/TR/REC-xml-names>.

   [XMPP-CORE]
              Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

13.2.  Informative References

   [CPIM]     Peterson, J., "Common Profile for Instant Messaging
              (CPIM)", RFC 3860, August 2004.

   [CPP]      Peterson, J., "Common Profile for Presence (CPP)",
              RFC 3859, August 2004.

   [DOS]      Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
              Service Considerations", RFC 4732, December 2006.

   [IMP-MODEL]
              Day, M., Rosenberg, J., and H. Sugano, "A Model for
              Presence and Instant Messaging", RFC 2778, February 2000.

   [IMP-REQS]
              Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
              / Presence Protocol Requirements", RFC 2779,
              February 2000.

   [IMP-SRV]  Peterson, J., "Address Resolution for Instant Messaging
              and Presence", RFC 3861, August 2004.

Top      Up      ToC       Page 100 
   [INTEROP]  Masinter, L., "Formalizing IETF Interoperability
              Reporting", Work in Progress, October 2005.

   [IRC]      Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
              April 2000.

   [IRI]      Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [PROCESS]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [REPORTS]  Dusseault, L. and R. Sparks, "Guidance on Interoperation
              and Implementation Reports for Advancement to Draft
              Standard", BCP 9, RFC 5657, September 2009.

   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

   [RFC3921]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 3921, October 2004.

   [SASL]     Melnikov, A. and K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", RFC 4422, June 2006.

   [SIP-PRES]
              Rosenberg, J., "A Presence Event Package for the Session
              Initiation Protocol (SIP)", RFC 3856, August 2004.

   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [TLS-CERTS]
              Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, March 2011.

   [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
              6.0", 2010,
              <http://www.unicode.org/versions/Unicode6.0.0/>.

   [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

Top      Up      ToC       Page 101 
   [UUID]     Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July 2005.

   [XEP-0016]
              Millard, P. and P. Saint-Andre, "Privacy Lists", XSF
              XEP 0016, February 2007.

   [XEP-0045]
              Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
              July 2008.

   [XEP-0054]
              Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008.

   [XEP-0071]
              Saint-Andre, P., "XHTML-IM", XSF XEP 0071, September 2008.

   [XEP-0115]
              Hildebrand, J., Saint-Andre, P., and R. Troncon, "Entity
              Capabilities", XSF XEP 0115, February 2008.

   [XEP-0147]
              Saint-Andre, P., "XMPP URI Scheme Query Components", XSF
              XEP 0147, September 2006.

   [XEP-0160]
              Saint-Andre, P., "Best Practices for Handling Offline
              Messages", XSF XEP 0160, January 2006.

   [XEP-0163]
              Saint-Andre, P. and K. Smith, "Personal Eventing
              Protocol", XSF XEP 0163, July 2010.

   [XEP-0191]
              Saint-Andre, P., "Simple Communications Blocking", XSF
              XEP 0191, February 2007.

   [XEP-0201]
              Saint-Andre, P., Paterson, I., and K. Smith, "Best
              Practices for Message Threads", XSF XEP 0201,
              November 2010.

   [XEP-0237]
              Saint-Andre, P. and D. Cridland, "Roster Versioning", XSF
              XEP 0237, March 2010.

Top      Up      ToC       Page 102 
   [XML-DATATYPES]
              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
              Second Edition", W3C REC-xmlschema-2, October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.

   [XML-SCHEMA]
              Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech,
              "XML Schema Part 1: Structures Second Edition", World Wide
              Web Consortium Recommendation REC-xmlschema-1-20041028,
              October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

   [XMPP-ADDR]
              Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Address Format", RFC 6122, March 2011.

   [XMPP-URI]
              Saint-Andre, P., "Internationalized Resource Identifiers
              (IRIs) and Uniform Resource Identifiers (URIs) for the
              Extensible Messaging and Presence Protocol (XMPP)",
              RFC 5122, February 2008.

   [VCARD]    Dawson, F. and T. Howes, "vCard MIME Directory Profile",
              RFC 2426, September 1998.


Next RFC Part