Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
obsoleted by
- rfc-6121 — Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
Extracted elements (26)
Presence and instant messaging services are explicitly designed to be separable: a deployment may offer only presence, only IM, or both combined. Although XMPP satisfies RFC 2779 requirements, it was not designed with that specification in mind — the base protocol evolved within the Jabber open-source community before RFC 2779 was written.
A client SHOULD verify that incoming roster pushes originate from a trusted source: the stanza MUST either have no 'from' attribute (implicitly from the server) or a 'from' matching the user's bare or full JID; otherwise the client SHOULD ignore the roster push.
A user's server MUST NOT automatically approve subscription requests on the user's behalf; all requests MUST be directed to available resources. If no available resource exists, the server MUST store the request and deliver it when the user next creates an available resource.
Before establishing an IM/presence session, a client MUST complete stream authentication as defined in XMPP-CORE and MUST bind a resource to the stream so the client's address is of the form <user@domain/resource>.
If a user sends directed presence to an entity not in the roster with subscription 'from' or 'both', the server MUST route the stanza but MUST NOT include that entity in subsequent available presence broadcasts; however, if the resource becomes unavailable, the server MUST send unavailable presence to that entity.
If an active resource already holds the same resource identifier, the server MUST either terminate the existing active resource and allow the new session, or disallow the new session while maintaining the existing one; implementing the first case is RECOMMENDED.
If an application receives a message with no 'type' attribute or an unrecognized 'type' value, it MUST treat the message as type 'normal'. The 'error' type MUST be generated only in response to an error related to a message received from another entity.
If an entity receives an IQ stanza of type 'get' or 'set' containing a child element qualified by an unrecognized namespace, it SHOULD return an IQ of type 'error' with <service-unavailable/>. A routing entity encountering an unknown child element SHOULD pass the stanza through untouched.
Server routing for message stanzas to a bare JID MUST deliver to the available resource with the highest non-negative priority; if all resources have negative priority or there are no available resources, the server MUST either store the message for later delivery or return an error.
The <priority/> element value MUST be an integer between -128 and +127. A presence stanza MUST NOT contain more than one <priority/> element; if absent, a server SHOULD treat the priority as zero.
The server MUST NOT send presence subscription requests or roster pushes to unavailable resources, nor to available resources that have not requested the roster.
Upon receiving initial presence from a client with no existing available resources, the user's server MUST send presence probes to all contacts with subscription 'to' or 'both', and MUST broadcast initial presence to all contacts with subscription 'from' or 'both', excluding those blocked by privacy lists.
When a client receives a subscription request, it MUST either approve by sending a presence stanza of type 'subscribed' or refuse by sending a presence stanza of type 'unsubscribed'.
When a resource becomes unavailable for any reason, the user's server MUST broadcast unavailable presence to all contacts with subscription 'from' or 'both', to other available resources of the user, and to any entities that received directed presence during the session.
When a roster item is added, updated, or deleted, the server MUST update roster information in persistent storage and MUST push the change (a roster 'set' IQ) to all of the user's available resources that have requested the roster.
When a user broadcasts available presence, the server MUST send the full XML of the presence stanza to all roster contacts with subscription 'from' or 'both' to whom outbound presence is not blocked and from whom no presence error was received during the session.
When the server receives a 'subscribed' presence stanza addressed to a user, it MUST verify the sender is in the user's roster with subscription='none' and ask='subscribe' or subscription='from' and ask='subscribe'; if neither condition holds, the server MUST silently ignore the stanza without routing, modifying the roster, or generating a roster push.
A roster item in the 'jabber:iq:roster' namespace is identified by a required 'jid' attribute and carries a 'subscription' attribute with values 'none', 'to', 'from', or 'both'. Items may include an optional 'name' attribute and one or more <group/> child elements for categorization.
Communication blocking is implemented via privacy lists (jabber:iq:privacy namespace), supporting active and default lists. Lists can block inbound/outbound messages, presence notifications, IQ stanzas, or all communication based on JID, roster group, subscription type, or a catch-all rule.
Message stanzas support five 'type' values: 'chat' (one-to-one), 'error', 'groupchat' (multi-user), 'headline' (automated broadcast), and 'normal' (standalone). The 'type' attribute is RECOMMENDED; child elements include optional <subject/>, <body/>, and <thread/>.
Presence stanzas support seven defined 'type' values: 'unavailable', 'subscribe', 'subscribed', 'unsubscribe', 'unsubscribed', 'probe', and 'error'. A presence stanza with no 'type' attribute signals the sender is online and available for communication.
Session establishment is performed by the client sending an IQ stanza of type 'set' containing an empty <session/> element qualified by 'urn:ietf:params:xml:ns:xmpp-session'. The server advertises session support as a stream feature after authentication, and a connected resource that completes this step becomes an 'active resource'.
The optional <show/> element specifies availability sub-state and MUST contain one of four values: 'away', 'chat' (actively interested in chatting), 'dnd' (Do Not Disturb), or 'xa' (Extended Away). A presence stanza MUST NOT contain more than one <show/> element.
The <thread/> element carries an opaque, non-human-readable conversation identifier. It MUST be unique to the conversation thread within the stream, MUST remain consistent throughout the conversation, and a stanza MUST NOT contain more than one <thread/> element; its value MUST be treated as opaque with only exact comparisons permitted.
XMPP IM inherits all security considerations from XMPP-CORE (RFC 3920), including mandatory TLS and SASL for stream protection. Servers must enforce privacy lists to prevent unwanted communication, and implementors should be aware that presence information disclosure is controlled solely by the subscription model.
Presence subscription state machine has four primary states — None, To (user subscribed to contact), From (contact subscribed to user), and Both — plus intermediate pending substates (e.g., None+PendingOut, To+PendingIn). Transitions are triggered by outbound/inbound subscribe, subscribed, unsubscribe, and unsubscribed presence stanzas.