RFC 6121
Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
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>
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>
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.
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.
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>
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
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].
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.
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.
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 <service- unavailable/> stanza error.
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.
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.
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.
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
"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
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
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.
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.
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.
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.
[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.
[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.
[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 page on part 5)
