1. If the JID is of the form <user@domain/resource> and an available
resource matches the full JID, the recipient’s server MUST
deliver the stanza to that resource.
2. Else if the JID is of the form <user@domain> or <user@domain/
resource> and the associated user account does not exist, the
recipient’s server (a) SHOULD silently ignore the stanza (i.e.,
neither deliver it nor return an error) if it is a presence
stanza, (b) MUST return a <service-unavailable/> stanza error to
the sender if it is an IQ stanza, and (c) SHOULD return a
<service-unavailable/> stanza error to the sender if it is a
message stanza.
3. Else if the JID is of the form <user@domain/resource> and no
available resource matches the full JID, the recipient’s server
(a) SHOULD silently ignore the stanza (i.e., neither deliver it
nor return an error) if it is a presence stanza, (b) MUST return
a <service-unavailable/> stanza error to the sender if it is an
IQ stanza, and (c) SHOULD treat the stanza as if it were
addressed to <user@domain> if it is a message stanza.
4. Else if the JID is of the form <user@domain> and there is at
least one available resource available for the user, the
recipient’s server MUST follow these rules:
1. For message stanzas, the server SHOULD deliver the stanza to
the highest-priority available resource (if the resource did
not provide a value for the <priority/> element, the server
SHOULD consider it to have provided a value of zero). If two
or more available resources have the same priority, the
server MAY use some other rule (e.g., most recent connect
time, most recent activity time, or highest availability as
determined by some hierarchy of <show/> values) to choose
between them or MAY deliver the message to all such
resources. However, the server MUST NOT deliver the stanza
to an 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 (defined below). In addition, the server MUST NOT
rewrite the ’to’ attribute (i.e., it MUST leave it as
<user@domain> rather than change it to <user@domain/
resource>).
2. For presence stanzas other than those of type "probe", the
server MUST deliver the stanza to all available resources;
for presence probes, the server SHOULD reply based on the
rules defined in Presence Probes (Section 5.1.3). In
addition, the server MUST NOT rewrite the ’to’ attribute
(i.e., it MUST leave it as <user@domain> rather than change
it to <user@domain/resource>).
3. For IQ stanzas, 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 available resources.
Specifically, if the semantics of the qualifying namespace
define a reply that the server can provide, the server MUST
reply to the stanza on behalf of the user; if not, the server
MUST reply with a <service-unavailable/> stanza error.
5. Else if the JID is of the form <user@domain> and there are no
available resources associated with the user, how the stanza is
handled depends on the stanza type:
1. For presence stanzas of type "subscribe", "subscribed",
"unsubscribe", and "unsubscribed", the server MUST maintain a
record of the stanza and deliver the stanza at least once
(i.e., when the user next creates an available resource); in
addition, the server MUST continue to deliver presence
stanzas of type "subscribe" until the user either approves or
denies the subscription request (see also Presence
Subscriptions (Section 5.1.6)).
2. For all other presence stanzas, the server SHOULD silently
ignore the stanza by not storing it for later delivery or
replying to it on behalf of the user.
3. For message stanzas, the server MAY choose to store the
stanza on behalf of the user and deliver it when the user
next becomes available, or forward the message to the user
via some other means (e.g., to the user’s email account).
However, if offline message storage or message forwarding is
not enabled, the server MUST return to the sender a
<service-unavailable/> stanza error. (Note: Offline message
storage and message forwarding are not defined in XMPP, since
they are strictly a matter of implementation and service
provisioning.)
4. For IQ stanzas, 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, the server MUST reply to the
stanza on behalf of the user; if not, the server MUST reply
with a <service-unavailable/> stanza error.
11.2. Outbound Stanzas
If the hostname of the domain identifier portion of the address
contained in the ’to’ attribute of an outbound stanza matches a
hostname of the server itself, the server MUST deliver the stanza to
a local entity according the rules for Inbound Stanzas (Section
11.1).
If the hostname of the domain identifier portion of the address
contained in the ’to’ attribute of an outbound stanza does not match
a hostname of the server itself, the server MUST attempt to route the
stanza to the foreign domain. The recommended order of actions is as
follows:
1. First attempt to resolve the foreign hostname using an [SRV]
Service of "xmpp-server" and Proto of "tcp", resulting in
resource records such as "_xmpp-server._tcp.example.com.", as
specified in [XMPP-CORE].
2. If the "xmpp-server" address record resolution fails, attempt to
resolve the "_im" or "_pres" [SRV] Service as specified in
[IMP-SRV], using the "_im" Service for <message/> stanzas and the
"_pres" Service for <presence/> stanzas (it is up to the
implementation how to handle <iq/> stanzas). This will result in
one or more resolutions of the form "_im.<proto>.example.com." or
"_pres.<proto>.example.com.", where "<proto>" would be a label
registered in the Instant Messaging SRV Protocol Label registry
or the Presence SRV Protocol Label registry: either "_xmpp" for
an XMPP-aware domain or some other IANA-registered label (e.g.,
"_simple") for a non-XMPP-aware domain.
3. If both SRV address record resolutions fail, attempt to perform a
normal IPv4/IPv6 address record resolution to determine the IP
address using the "xmpp-server" port of 5269 registered with the
IANA, as specified in [XMPP-CORE].
Administrators of server deployments are strongly encouraged to keep
the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly
synchronized, since different implementations might perform the "_im"
and "_pres" lookups before the "xmpp-server" lookup.
12. IM and Presence Compliance Requirements
This section summarizes the specific aspects of the Extensible
Messaging and Presence Protocol that MUST be supported by instant
messaging and presence servers and clients in order to be considered
compliant implementations. All such applications MUST comply with
the requirements specified in [XMPP-CORE]. The text in this section
specifies additional compliance requirements for instant messaging
and presence servers and clients; note well that the requirements
described here supplement but do not supersede the core requirements.
Note also that a server or client MAY support only presence or
instant messaging, and is not required to support both if only a
presence service or an instant messaging service is desired.
12.1. Servers
In addition to core server compliance requirements, an instant
messaging and presence server MUST additionally support the following
protocols:
o All server-related instant messaging and presence syntax and
semantics defined in this document, including presence broadcast
on behalf of clients, presence subscriptions, roster storage and
manipulation, privacy lists, and IM-specific routing and delivery
rules
12.2. Clients
In addition to core client compliance requirements, an instant
messaging and presence client MUST additionally support the following
protocols:
o Generation and handling of the IM-specific semantics of XML
stanzas as defined by the XML schemas, including the ’type’
attribute of message and presence stanzas as well as their child
elements
o All client-related instant messaging syntax and semantics defined
in this document, including presence subscriptions, roster
management, and privacy lists
o End-to-end object encryption as defined in End-to-End Object
Encryption in the Extensible Messaging and Presence Protocol
(XMPP) [XMPP-E2E]
A client MUST also handle addresses that are encoded as "im:" URIs as
specified in [CPIM], and MAY do so by removing the "im:" scheme and
entrusting address resolution to the server as specified under
Outbound Stanzas (Section 11.2).
13. Internationalization Considerations
For internationalization considerations, refer to the relevant
section of [XMPP-CORE].
14. Security Considerations
Core security considerations for XMPP are defined in the relevant
section of [XMPP-CORE].
Additional considerations that apply only to instant messaging and
presence applications of XMPP are defined in several places within
this memo; specifically:
o When a server processes an inbound stanza of any kind whose
intended recipient is a user associated with one of the server’s
hostnames, the server MUST first apply any privacy lists (Section
10) that are in force (see Server Rules for Handling XML Stanzas
(Section 11)).
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 hostnames, the server MUST NOT reveal the user’s presence
information if the sender is an entity that is not authorized to
receive that information as determined by presence subscriptions
(see Client and Server Presence Responsibilities (Section 5.1)).
o When a server processes an outbound presence stanza with no type
or of type "unavailable", it MUST follow the rules defined under
Client and Server Presence Responsibilities (Section 5.1) in order
to ensure that such presence information is not broadcasted to
entities that are not authorized to know such information.
o When a server generates an error stanza in response to receiving a
stanza for a user who does not exist, the use of the
<service-unavailable/> error condition helps protect against
well-known dictionary attacks, since this is the same error
condition that is returned if, for instance, the namespace of an
IQ child element is not understood, or if offline message storage
or message forwarding is not enabled for a domain.
15. IANA Considerations
For a number of related IANA considerations, refer to the relevant
section of [XMPP-CORE].
15.1. XML Namespace Name for Session Data
A URN sub-namespace for session-related data in the Extensible
Messaging and Presence Protocol (XMPP) is defined as follows. (This
namespace name adheres to the format defined in The IETF XML Registry
[XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-session
Specification: RFC 3921
Description: This is the XML namespace name for session-related data
in the Extensible Messaging and Presence Protocol (XMPP) as
defined by RFC 3921.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
15.2. Instant Messaging SRV Protocol Label Registration
Address Resolution for Instant Messaging and Presence [IMP-SRV]
defines an Instant Messaging SRV Protocol Label registry for
protocols that can provide services that conform to the "_im" SRV
Service label. Because XMPP is one such protocol, the IANA registers
the "_xmpp" protocol label in the appropriate registry, as follows:
Protocol label: _xmpp
Specification: RFC 3921
Description: Instant messaging protocol label for the Extensible
Messaging and Presence Protocol (XMPP) as defined by RFC 3921.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
15.3. Presence SRV Protocol Label Registration
Address Resolution for Instant Messaging and Presence [IMP-SRV]
defines a Presence SRV Protocol Label registry for protocols that can
provide services that conform to the "_pres" SRV Service label.
Because XMPP is one such protocol, the IANA registers the "_xmpp"
protocol label in the appropriate registry, as follows:
Protocol label: _xmpp
Specification: RFC 3921
Description: Presence protocol label for the Extensible Messaging and
Presence Protocol (XMPP) as defined by RFC 3921.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
16. References
16.1. Normative References
[CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., 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.
[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[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 3920, October 2004.
[XMPP-E2E] Saint-Andre, P., "End-to-End Object Encryption in the
Extensible Messaging and Presence Protocol (XMPP)", RFC
3923, October 2004.
16.2. Informative References
[IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000.
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
Protocol", RFC 1459, May 1993.
[JEP-0054] Saint-Andre, P., "vcard-temp", JSF JEP 0054, March 2003.
[JEP-0077] Saint-Andre, P., "In-Band Registration", JSF JEP 0077,
August 2004.
[JEP-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078,
July 2004.
[JSF] Jabber Software Foundation, "Jabber Software Foundation",
<http://www.jabber.org/>.
[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, September 1998.
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
Appendix A. vCards
Sections 3.1.3 and 4.1.4 of [IMP-REQS] require that it be possible to
retrieve out-of-band contact information for other users (e.g.,
telephone number or email address). An XML representation of the
vCard specification defined in RFC 2426 [VCARD] is in common use
within the Jabber community to provide such information but is out of
scope for XMPP (documentation of this protocol is contained in
[JEP-0054], published by the Jabber Software Foundation [JSF]).
Appendix B. XML Schemas
The following XML schemas are descriptive, not normative. For
schemas defining the core features of XMPP, refer to [XMPP-CORE].
B.1 jabber:client
<?xml version=’1.0’ encoding=’UTF-8’?>
<xs:schema
xmlns:xs=’http://www.w3.org/2001/XMLSchema’
targetNamespace=’jabber:client’
xmlns=’jabber:client’
elementFormDefault=’qualified’>
<xs:import namespace=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
<xs:element name=’message’>
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs=’0’ maxOccurs=’unbounded’>
<xs:element ref=’subject’/>
<xs:element ref=’body’/>
<xs:element ref=’thread’/>
</xs:choice>
<xs:any namespace=’##other’
minOccurs=’0’
maxOccurs=’unbounded’/>
<xs:element ref=’error’
minOccurs=’0’/>
</xs:sequence>
<xs:attribute name=’from’
type=’xs:string’
use=’optional’/>
<xs:attribute name=’id’
type=’xs:NMTOKEN’
use=’optional’/>
<xs:attribute name=’to’
type=’xs:string’
use=’optional’/>
<xs:attribute name=’type’ use=’optional’ default=’normal’>
<xs:simpleType>
<xs:restriction base=’xs:NCName’>
<xs:enumeration value=’chat’/>
<xs:enumeration value=’error’/>
<xs:enumeration value=’groupchat’/>
<xs:enumeration value=’headline’/>
<xs:enumeration value=’normal’/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref=’xml:lang’ use=’optional’/>
</xs:complexType>
</xs:element>
<xs:element name=’body’>
<xs:complexType>
<xs:simpleContent>
<xs:extension base=’xs:string’>
<xs:attribute ref=’xml:lang’ use=’optional’/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name=’subject’>
<xs:complexType>
<xs:simpleContent>
<xs:extension base=’xs:string’>
<xs:attribute ref=’xml:lang’ use=’optional’/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name=’thread’ type=’xs:NMTOKEN’/>
<xs:element name=’presence’>
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs=’0’ maxOccurs=’unbounded’>
<xs:element ref=’show’/>
<xs:element ref=’status’/>
<xs:element ref=’priority’/>
</xs:choice>
<xs:any namespace=’##other’
minOccurs=’0’
maxOccurs=’unbounded’/>
<xs:element ref=’error’
minOccurs=’0’/>
</xs:sequence>
<xs:attribute name=’from’
type=’xs:string’
use=’optional’/>
<xs:attribute name=’id’
type=’xs:NMTOKEN’
use=’optional’/>
<xs:attribute name=’to’
type=’xs:string’
use=’optional’/>
<xs:attribute name=’type’ use=’optional’>
<xs:simpleType>
<xs:restriction base=’xs:NCName’>
<xs:enumeration value=’error’/>
<xs:enumeration value=’probe’/>
<xs:enumeration value=’subscribe’/>
<xs:enumeration value=’subscribed’/>
<xs:enumeration value=’unavailable’/>
<xs:enumeration value=’unsubscribe’/>
<xs:enumeration value=’unsubscribed’/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref=’xml:lang’ use=’optional’/>
</xs:complexType>
</xs:element>
<xs:element name=’show’>
<xs:simpleType>
<xs:restriction base=’xs:NCName’>
<xs:enumeration value=’away’/>
<xs:enumeration value=’chat’/>
<xs:enumeration value=’dnd’/>
<xs:enumeration value=’xa’/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name=’status’>
<xs:complexType>
<xs:simpleContent>
<xs:extension base=’xs:string’>
<xs:attribute ref=’xml:lang’ use=’optional’/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name=’priority’ type=’xs:byte’/>
<xs:element name=’iq’>
<xs:complexType>
<xs:sequence>