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.

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/>.

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

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 unavailable/> stanza error.