This document specifies best practices to be followed by instant messaging servers in verifying the existence of items added to user rosters.
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at <http://www.jabber.org/jeps/> and announced on the <firstname.lastname@example.org> mailing list.
Last Updated: 2005-09-06
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0030
Superseded By: None
Short Name: N/A
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
RFC 3920  defines a close connection between roster items and presence subscriptions. However, it is possible to treat adding a roster item and requesting a presence subscription as two distinct operations. This functionality is the default functionality in other IM systems, for example the IMPS (Wireless Village) protocol defined in WV Client-Server Protocol v1.1 , and may also be useful in some Jabber/XMPP deployments.
When an IM user adds a roster item in XMPP but does not request a presence subscription, the user may never discover whether the added JID actually exists. In order to map to the functionality in IMPS and similar IM systems, an XMPP server may want to verify the existence of the added JID when the user adds the roster item. This document specifies best practices for doing so.
The RECOMMENDED process flow is as follows:
This flow is described more fully below.
First, the user (in this example, email@example.com) adds a contact (firstname.lastname@example.org) to her roster.
<iq email@example.com/chamber' id='roster1' type='set'> <query xmlns='jabber:iq:roster'> <item firstname.lastname@example.org'/> </query> </iq>
Next, the user's server sends a disco#info request to the contact's bare JID <contact@domain>.
(Note: If the user added the contact's full JID <contact@domain/resource> rather than the contact's bare JID <contact@domain>, the user's server SHOULD first send a disco#info request to the contact's bare JID. If the response indicates that the contact has a service discovery category of "account", the user's server MUST NOT send a query to the full JID. If the response indicates that the contact has a service discovery category other than "account" (e.g., a chat service), the user's server SHOULD send a query to the full JID to verify the contact's existence (e.g., the "contact" may be chat room rather than a user account). If the response does not provide evidence as to the existence or identity of the contact (e.g., the contact's server returns a <forbidden/> or <service-unavailable/> error as described below), the user's service SHOULD NOT send a query to the full JID.)
<iq from='capulet.com' email@example.com' id='verify1' type='get'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
In accordance with JEP-0030, the contact's server shall reply to service discovery requests sent to <contact@domain> on the contact's behalf. It is RECOMMENDED for the contact's server to reply as described below.
If the contact's server trusts the user's server and the contact's account exists, the contact's server SHOULD return information about the contact as described in JEP-0030, and the user's server then MUST return an IQ-result to the user indicating that the contact has been successfully added to the roster:
<iq firstname.lastname@example.org' to='capulet.com' id='verify1' type='result'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='account' type='registered'/> </query> </iq>
<iq email@example.com/chamber' id='roster1' type='result'/>
If the contact's server trusts the user's server and the contact's account does not exist, the contact's server SHOULD return an <item-not-found/> error to the user's server, and the user's server then MUST return an <item-not-found/> error to the user:
<iq firstname.lastname@example.org' to='capulet.com' id='verify1' type='error'> <query xmlns='http://jabber.org/protocol/disco#info'/> <error code='404' type='cancel'> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
<iq email@example.com/chamber' id='roster1' type='error'/> <query xmlns='jabber:iq:roster'> <item firstname.lastname@example.org'/> </query> <error code='404' type='cancel'> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
The foregoing responses are unambiguous. However, it is possible that the contact's server does not trust the user's server (returning a <forbidden/> error) or that the contact's server does not provide information about user accounts (returning a <service-unavailable/> error). When the user's server receives such an error from the contact's server, it cannot definitively determine if the contact exists or not. In such an ambiguous situation, the user's server SHOULD NOT return a roster error to the user.
If a server allows peer servers to query for the existence of registered accounts, it opens itself up to the possibility of dictionary attacks. Therefore a server SHOULD carefully monitor such requests and SHOULD NOT return account information if there is cause to believe that the peer server is launching a dictionary attack or is otherwise abusing the account verification privilege; in addition, a server SHOULD maintain a list of peer servers that it trusts and/or a list of peer servers that it does not trust (i.e., a "whitelist" and/or a "blacklist"); the server SHOULD verify accounts for trusted servers and SHOULD NOT do so for untrusted servers.
The best practices defined herein are intended for use by peer servers only. If the contact's server handles a disco#info query on behalf of a registered account and the "from" address is not a peer server, it is STRONGLY RECOMMENDED that the contact's server return a <service-unavailable/> error if the requesting entity is not authorized to discover information about the contact (e.g., if the requesting entity is not in the contact's roster).
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) .
This JEP requires no interaction with the Jabber Registrar .
2. Wireless Village Client-Server Protocol v1.1 <http://www.openmobilealliance.org/tech/affiliates/wv/wvindex.html>.
4. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
5. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.