Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
obsoletes
- rfc-3921 — Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
Extracted elements (29)
For roster versioning, the server chooses between returning the full roster or an empty IQ-result followed by incremental pushes; the incremental approach is preferred unless the full roster would use less bandwidth or the client's version ID is unrecognized.
RFC 3921 required a formal IM session establishment step after stream negotiation; RFC 6121 removes this as implementation experience showed it is unnecessary, but implementations MAY still offer it for backward compatibility, saving a round trip for newer software while allowing older clients to connect.
XMPP subscriptions persist across presence sessions (unlike SIP-PRES), lasting until explicitly canceled by unsubscribe or subscription cancellation, reflecting a buddy-list model where authorization decisions outlive individual login sessions.
The 'ver' attribute on <query/>, the 'approved' attribute on <item/>, and subscription pre-approval (Section 3.4) are all newly defined in RFC 6121 and absent from RFC 3921; implementations supporting only RFC 3921 will not recognize these features.
A client MUST ignore a roster push unless it arrives with no 'from' attribute (implicitly from the user's bare JID) or a 'from' matching the user's bare JID; if received from an unauthorized entity, the client MUST NOT process the pushed data.
A roster set MUST contain exactly one <item/> element; the server MUST return <bad-request/> if more than one item is included or if duplicate group names appear, and MUST return <not-acceptable/> for oversized name or group fields.
A subscription request MUST use the contact's bare JID <contact@domainpart> as the 'to' attribute, not a full JID, so the user receives presence from all of the contact's resources rather than a single one.
The contact's server MUST NOT automatically approve subscription requests on the contact's behalf unless the contact has pre-approved the user, configured auto-approval, or agreed to it with its service provider.
The contact's server MUST NOT deliver more than one subscription request from a given user when the contact next becomes available, storing only one (first or last) to prevent subscription request spam.
The entity processing a roster set MUST verify that the sender is authorized to update the roster and MUST return a <forbidden/> error if not; a client MUST NOT include the 'approved' or 'ask' attributes in roster sets it sends to the server.
The server MUST restrict access to the user's roster so that only authorized entities (typically the account owner) can retrieve, modify, or delete it, because the roster can contain confidential data.
Upon authenticating and binding a resource, a client SHOULD request the roster before sending initial presence; the server MUST send roster pushes to all interested resources.
When an interactive client receives a subscription request it MUST present the request to the controlling natural person for approval; an 'id' attribute in approval or denial responses MUST NOT mirror the 'id' of the original request.
When processing or generating outbound subscription stanzas (subscribe, subscribed, unsubscribe, unsubscribed), the server MUST stamp the stanza with the bare JID of the sending entity, not the full JID.
When roster versioning is enabled, the server MUST include the updated 'ver' attribute with each roster push; roster pushes MUST occur in modification order and each version value MUST be unique.
Presence information is disclosed only to entities that a user has explicitly authorized via a presence subscription; the contact's server MUST NOT add an item for the requesting user to the contact's roster until the contact approves the request.
Each roster <item/> element carries: 'jid' (REQUIRED), 'name' (OPTIONAL user-assigned handle, opaque to server), 'subscription' (none/to/from/both/remove), 'ask' (value 'subscribe' signals Pending Out, server-generated), 'approved' (boolean for subscription pre-approval, server-generated), and zero or more <group/> children.
Presence subscriptions use presence stanzas with type: 'subscribe' (request), 'subscribed' (approval), 'unsubscribe' (remove own outbound subscription), and 'unsubscribed' (cancel contact's subscription or deny a pending request).
Rosters are managed via <iq/> stanzas with a <query xmlns='jabber:iq:roster'/> child element; the four operations are roster get (type='get'), roster result (type='result'), roster set (type='set' client-to-server), and roster push (type='set' server-to-client).
The <message/> stanza's 'type' attribute takes values: 'chat' (one-to-one session), 'normal' (standalone, default), 'groupchat' (multi-user room), 'headline' (alerts/notifications), or 'error'; the <body/> child carries human-readable message content.
The <priority/> child element of a presence stanza carries an integer between -128 and 127 (default 0); a negative value signals that the resource declines to receive message stanzas addressed to the bare JID.
The roster versioning stream feature is advertised as <ver xmlns='urn:xmpp:features:rosterver'/> during stream negotiation; it is informative-only and never mandatory-to-negotiate.
The <show/> child element of a presence stanza carries one of: 'away' (temporarily absent), 'chat' (actively seeking chat), 'dnd' (do not disturb), or 'xa' (extended away); absence of <show/> means the entity is available.
The <thread/> element in a <message/> stanza carries an opaque identifier for conversation tracking; a 'parent' attribute MAY reference the identifier of a thread from which the current thread forked.
The 'ver' attribute on <query/> is a server-generated opaque version string; clients set it to their last cached version when requesting the roster, or to the empty string to bootstrap versioning; if unrecognized by the server, the full roster is returned.
RFC 6121 registers the 'jabber:iq:roster' XML namespace and the 'urn:xmpp:features:rosterver' stream feature namespace with the IANA XMPP registries, updating the namespace registry originally established by RFC 3921.
The requirement for a contact's server to store complete inbound subscription request stanzas introduces an application resource exhaustion risk; server implementers should set limits on the number or size of stored requests per contact to mitigate botnet-style attacks.
Presence subscription states for a roster item are: None, None+PendingOut (subscribe sent awaiting approval), None+PendingIn, From (contact subscribed to user), From+PendingOut, To (user subscribed to contact), To+PendingIn, and Both (mutual); transitions are triggered by subscribe/subscribed/unsubscribe/unsubscribed presence stanzas as detailed in Appendix A.
The IM session lifecycle: (1) stream negotiation per XMPP-CORE; (2) roster retrieval; (3) initial presence broadcast making the resource 'available' and triggering presence probes; (4) stanza exchange; (5) unavailable presence and stream closure.