diff --git a/xep-0144.xml b/xep-0144.xml index 91feff77..413093ed 100644 --- a/xep-0144.xml +++ b/xep-0144.xml @@ -11,6 +11,7 @@ &LEGALNOTICE; 0144 Draft + Standards Track Standards @@ -26,6 +27,12 @@ http://www.xmpp.org/schemas/rosterx.xsd &stpeter; + + 1.1rc1 + in progress, last updated 2012-06-19 + psa + Clarified use of message vs. IQ and full JID vs. bare JID; removed IQ handling rules, which are specified in RFC 6120. + 1.0 2005-08-26 @@ -201,24 +208,14 @@ ]]> - -

If the sending entity has knowledge (e.g., via presence or an active chat conversation) that the receiving entity is online and available, it SHOULD: If the receiving entity has more than one available resource, the sending application SHOULD communicate with the "most available" resource according its best estimation (e.g., the resource with the highest priority).

-
    -
  1. Discover if the receiving entity supports the protocol defined herein (see the Service Discovery section of this document).
    2. -
  2. If so, send its roster item exchange stanza to a particular resource (user@host/resource) of the receiving entity using an &IQ; stanza rather than a &MESSAGE; stanza.
    3. -
-

If the sending entity does not know that the receiving entity is online and available, it MUST send a &MESSAGE; stanza to the receiving entity's "bare JID" (user@host) rather than an &IQ; stanza to a particular resource.

- -

If the sending entity uses &IQ; stanzas to communicate its roster item exchange suggestions, the receiving entity MUST adhere to the IQ semantics defined in &xmppcore;. Specifically:

-
    -
  1. If the receiving entity successfully processes the suggested action(s) (which may include ignoring certain suggestions), the receiving entity MUST return an empty IQ result to the sending entity.
    2. -
  2. If the receiving entity does not understand the roster item exchange namespace, the receiving entity MUST return an error to the sending entity, which error SHOULD be &unavailable;.
    3. -
  3. If the receiving entity will not process the suggested action(s) because the receiving entity is not registered with the sending entity, the receiving entity MUST return an error to the sending entity, which error SHOULD be ®istration;.
    4. -
  4. If the receiving entity will not process the suggested action(s) because the sending entity is not in the receiving entity's roster, the receiving entity MUST return an error to the sending entity, which error SHOULD be ¬authorized;.
    5. -
  5. If the receiving entity will not process the suggested action(s) because the sending entity is not trusted (see Trusted Entities), the receiving entity MUST return an error to the sending entity, which error SHOULD be &forbidden;.
    6. -
-

Naturally, other IQ errors may be more appropriate; however, if the receiving entity will not or cannot process the suggested action(s), it MUST return an error to the sending entity.

- + +

Roster item exchanges can be sent in any of the four following ways:

+
    +

  • In an &IQ; stanza to a full JID &LOCALFULL;. This is appropriate if the sender has knowledge (e.g., via presence and &xep0115;) that a particular resource associated with the recipient is online and supports this protocol.

    • +

  • In an &IQ; stanza to a bare JID &LOCALFULL;. This can be appropriate if the sender wants the roster item to be processed by the server on behalf of the recipient (e.g., if the sender is a trusted component of the server).

    • +

  • In a &MESSAGE; stanza to a bare JID &LOCALBARE;. This can be appropriate if the sender wants the roster item to be delivered to all of the recipient's online resources (e.g., because the sender does to have presence or capabilities information about particular resources).

    • +

  • In a &MESSAGE; stanza to a full JID &LOCALFULL;. This is generally undesirable, since it is better to se an &IQ; stanza when sending to a full JID (e.g., IQ stanzas are automatically acknowledged).

    • +