<forbidden
xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
</error>
</iq>
If there is already an active resource of the same name, the server
MUST either (1) terminate the active resource and allow the
newly-requested session, or (2) disallow the newly-requested session
and maintain the active resource. Which of these the server does is
up to the implementation, although it is RECOMMENDED to implement
case #1. In case #1, the server SHOULD send a <conflict/> stream
error to the active resource, terminate the XML stream and underlying
TCP connection for the active resource, and return a IQ stanza of
type "result" (indicating success) to the newly-requested session. In
case #2, the server SHOULD send a <conflict/> stanza error to the
newly-requested session but maintain the XML stream for that
connection so that the newly-requested session has an opportunity to
negotiate a non-conflicting resource identifier before sending
another request for session establishment.
Step 2 (alt): Server informs existing active resource of resource
conflict (case #1):
<stream:error>
<conflict xmlns=’urn:ietf:params:xml:ns:xmpp-streams’/>
</stream:error>
</stream:stream>
Step 2 (alt): Server informs newly-requested session of resource
conflict (case #2):
<iq from=’example.com’ type=’error’ id=’sess_1’>
<session xmlns=’urn:ietf:params:xml:ns:xmpp-session’/>
<error type=’cancel’>
<conflict xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
</error>
</iq>
After establishing a session, a client SHOULD send initial presence
and request its roster as described below, although these actions are
OPTIONAL.
Note: Before allowing the creation of instant messaging and presence
sessions, a server MAY require prior account provisioning. Possible
methods for account provisioning include account creation by a server
administrator as well as in-band account registration using the
’jabber:iq:register’ namespace; the latter method is out of scope for
this memo, but is documented in [JEP-0077], published by the Jabber
Software Foundation [JSF].
4. Exchanging Messages
Exchanging messages is a basic use of XMPP and is brought about when
a user generates a message stanza that is addressed to another
entity. As defined under Server Rules for Handling XML Stanzas
(Section 11), the sender’s server is responsible for delivering the
message to the intended recipient (if the recipient is on the same
server) or for routing the message to the recipient’s server (if the
recipient is on a different server).
For information regarding the syntax of message stanzas as well as
their defined attributes and child elements, refer to Message Syntax
(Section 2.1).
4.1. Specifying an Intended Recipient
An instant messaging client SHOULD specify an intended recipient for
a message by providing the JID of an entity other than the sender in
the ’to’ attribute of the <message/> stanza. If the message is being
sent in reply to a message previously received from an address of the
form <user@domain/resource> (e.g., within the context of a chat
session), the value of the ’to’ address SHOULD be of the form
<user@domain/resource> rather than of the form <user@domain> unless
the sender has knowledge (via presence) that the intended recipient’s
resource is no longer available. If the message is being sent
outside the context of any existing chat session or received message,
the value of the ’to’ address SHOULD be of the form <user@domain>
rather than of the form <user@domain/resource>.
4.2. Specifying a Message Type
As noted, it is RECOMMENDED for a message stanza to possess a ’type’
attribute whose value captures the conversational context (if any) of
the message (see Type (Section 2.1.1)).
The following example shows a valid value of the ’type’ attribute:
Example: A message of a defined type:
<message
to=’romeo@example.net’
from=’juliet@example.com/balcony’
type=’chat’
xml:lang=’en’>
<body>Wherefore art thou, Romeo?</body>
</message>
4.3. Specifying a Message Body
A message stanza MAY (and often will) contain a child <body/> element
whose XML character data specifies the primary meaning of the message
(see Body (Section 2.1.2.2)).
Example: A message with a body:
<message
to=’romeo@example.net’
from=’juliet@example.com/balcony’
type=’chat’
xml:lang=’en’>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang=’cz’>PročeŽ jsi ty, Romeo?</body>
</message>
4.4. Specifying a Message Subject
A message stanza MAY contain one or more child <subject/> elements
specifying the topic of the message (see Subject (Section 2.1.2.1)).
Example: A message with a subject:
<message
to=’romeo@example.net’
from=’juliet@example.com/balcony’
type=’chat’
xml:lang=’en’>
<subject>I implore you!</subject>
<subject
xml:lang=’cz’>Úpěnlivě prosim!</subject>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang=’cz’>PročeŽ jsi ty, Romeo?</body>
</message>
4.5. Specifying a Conversation Thread
A message stanza MAY contain a child <thread/> element specifying the
conversation thread in which the message is situated, for the purpose
of tracking the conversation (see Thread (Section 2.1.2.3)).
Example: A threaded conversation:
<message
to=’romeo@example.net/orchard’
from=’juliet@example.com/balcony’
type=’chat’
xml:lang=’en’>
<body>Art thou not Romeo, and a Montague?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
<message
to=’juliet@example.com/balcony’
from=’romeo@example.net/orchard’
type=’chat’
xml:lang=’en’>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
<message
to=’romeo@example.net/orchard’
from=’juliet@example.com/balcony’
type=’chat’
xml:lang=’en’>
<body>How cam’st thou hither, tell me, and wherefore?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
5. Exchanging Presence Information
Exchanging presence information is made relatively straightforward
within XMPP by using presence stanzas. However, we see here a
contrast to the handling of messages: although a client MAY send
directed presence information to another entity by including a ’to’
address, normally presence notifications (i.e., presence stanzas with
no ’type’ or of type "unavailable" and with no ’to’ address) are sent
from a client to its server and then broadcasted by the server to any
entities that are subscribed to the presence of the sending entity
(in the terminology of RFC 2778 [IMP-MODEL], these entities are
subscribers). This broadcast model does not apply to
subscription-related presence stanzas or presence stanzas of type
"error", but to presence notifications only as defined above. (Note:
While presence information MAY be provided on a user’s behalf by an
automated service, normally it is provided by the user’s client.)
For information regarding the syntax of presence stanzas as well as
their defined attributes and child elements, refer to [XMPP-CORE].
5.1. Client and Server Presence Responsibilities
5.1.1. Initial Presence
After establishing a session, a client SHOULD send initial presence
to the server in order to signal its availability for communications.
As defined herein, the initial presence stanza (1) MUST possess no
’to’ address (signalling that it is meant to be broadcasted by the
server on behalf of the client) and (2) MUST possess no ’type’
attribute (signalling the user’s availability). After sending
initial presence, an active resource is said to be an "available
resource".
Upon receiving initial presence from a client, the user’s server MUST
do the following if there is not already one or more available
resources for the user (if there is already one or more available
resources for the user, the server obviously does not need to send
the presence probes, since it already possesses the requisite
information):
1. Send presence probes (i.e., presence stanzas whose ’type’
attribute is set to a value of "probe") from the full JID (e.g.,
<user@example.com/resource>) of the user to all contacts to which
the user is subscribed in order to determine if they are
available; such contacts are those for which a JID is present in
the user’s roster with the ’subscription’ attribute set to a
value of "to" or "both". (Note: The user’s server MUST NOT send
presence probes to contacts from which the user is blocking
inbound presence notifications, as described under Blocking
Inbound Presence Notifications (Section 10.10).)
2. Broadcast initial presence from the full JID (e.g.,
<user@example.com/resource>) of the user to all contacts that are
subscribed to the user’s presence information; such contacts are
those for which a JID is present in the user’s roster with the
’subscription’ attribute set to a value of "from" or "both".
(Note: The user’s server MUST NOT broadcast initial presence to
contacts to which the user is blocking outbound presence
notifications, as described under Blocking Outbound Presence
Notifications (Section 10.11).)
In addition, the user’s server MUST broadcast initial presence from
the user’s new available resource to any of the user’s existing
available resources (if any).
Upon receiving initial presence from the user, the contact’s server
MUST deliver the user’s presence stanza to the full JIDs
(<contact@example.org/resource>) associated with all of the contact’s
available resources, but only if the user is in the contact’s roster
with a subscription state of "to" or "both" and the contact has not
blocked inbound presence notifications from the user’s bare or full
JID (as defined under Blocking Inbound Presence Notifications
(Section 10.10)).
If the user’s server receives a presence stanza of type "error" in
response to the initial presence that it sent to a contact on behalf
of the user, it SHOULD NOT send further presence updates to that
contact (until and unless it receives a presence stanza from the
contact).
5.1.2. Presence Broadcast
After sending initial presence, the user MAY update its presence
information for broadcasting at any time during its session by
sending a presence stanza with no ’to’ address and either no ’type’
attribute or a ’type’ attribute with a value of "unavailable". (Note:
A user’s client SHOULD NOT send a presence update to broadcast
information that changes independently of the user’s presence and
availability.)
If the presence stanza lacks a ’type’ attribute (i.e., expresses
availability), the user’s server MUST broadcast the full XML of that
presence stanza to all contacts (1) that are in the user’s roster
with a subscription type of "from" or "both", (2) to whom the user
has not blocked outbound presence notifications, and (3) from whom
the server has not received a presence error during the user’s
session (as well as to any of the user’s other available resources).
If the presence stanza has a ’type’ attribute set to a value of
"unavailable", the user’s server MUST broadcast the full XML of that
presence stanza to all entities that fit the above description, as
well as to any entities to which the user has sent directed available
presence during the user’s session (if the user has not yet sent
directed unavailable presence to that entity).
5.1.3. Presence Probes
Upon receiving a presence probe from the user, the contact’s server
SHOULD reply as follows:
1. If the user is not in the contact’s roster with a subscription
state of "From", "From + Pending Out", or "Both" (as defined
under Subscription States (Section 9)), the contact’s server MUST
return a presence stanza of type "error" in response to the
presence probe (however, if a server receives a presence probe
from a subdomain of the server’s hostname or another such trusted
service, it MAY provide presence information about the user to
that entity). Specifically:
* if the user is in the contact’s roster with a subscription
state of "None", "None + Pending Out", or "To" (or is not in
the contact’s roster at all), the contact’s server MUST return
a <forbidden/> stanza error in response to the presence probe.
* if the user is in the contact’s roster with a subscription
state of "None + Pending In", "None + Pending Out/In", or "To
+ Pending In", the contact’s server MUST return a
<not-authorized/> stanza error in response to the presence
probe.
2. Else, if the contact is blocking presence notifications to the
user’s bare JID or full JID (using either a default list or
active list as defined under Blocking Outbound Presence
Notifications (Section 10.11)), the server MUST NOT reply to the
presence probe.
3. Else, if the contact has no available resources, the server MUST
either (1) reply to the presence probe by sending to the user the
full XML of the last presence stanza of type "unavailable"
received by the server from the contact, or (2) not reply at all.
4. Else, if the contact has at least one available resource, the
server MUST reply to the presence probe by sending to the user
the full XML of the last presence stanza with no ’to’ attribute
received by the server from each of the contact’s available
resources (again, subject to privacy lists in force for each
session).
5.1.4. Directed Presence
A user MAY send directed presence to another entity (i.e., a presence
stanza with a ’to’ attribute whose value is the JID of the other
entity and with either no ’type’ attribute or a ’type’ attribute
whose value is "unavailable"). There are three possible cases:
1. If the user sends directed presence to a contact that is in the
user’s roster with a subscription type of "from" or "both" after
having sent initial presence and before sending unavailable
presence broadcast, the user’s server MUST route or deliver the
full XML of that presence stanza (subject to privacy lists) but
SHOULD NOT otherwise modify the contact’s status regarding
presence broadcast (i.e., it SHOULD include the contact’s JID in
any subsequent presence broadcasts initiated by the user).
2. If the user sends directed presence to an entity that is not in
the user’s roster with a subscription type of "from" or "both"
after having sent initial presence and before sending unavailable
presence broadcast, the user’s server MUST route or deliver the
full XML of that presence stanza to the entity but MUST NOT
modify the contact’s status regarding available presence
broadcast (i.e., it MUST NOT include the entity’s JID in any
subsequent broadcasts of available presence initiated by the
user); however, if the available resource from which the user
sent the directed presence become unavailable, the user’s server
MUST broadcast that unavailable presence to the entity (if the
user has not yet sent directed unavailable presence to that
entity).
3. If the user sends directed presence without first sending initial
presence or after having sent unavailable presence broadcast
(i.e., the resource is active but not available), the user’s
server MUST treat the entities to which the user sends directed
presence in the same way that it treats the entities listed in
case #2 above.
5.1.5. Unavailable Presence
Before ending its session with a server, a client SHOULD gracefully
become unavailable by sending a final presence stanza that possesses
no ’to’ attribute and that possesses a ’type’ attribute whose value
is "unavailable" (optionally, the final presence stanza MAY contain
one or more <status/> elements specifying the reason why the user is
no longer available). However, the user’s server MUST NOT depend on
receiving final presence from an available resource, since the
resource may become unavailable unexpectedly or may be timed out by
the server. If one of the user’s resources becomes unavailable for
any reason (either gracefully or ungracefully), the user’s server
MUST broadcast unavailable presence to all contacts (1) that are in
the user’s roster with a subscription type of "from" or "both", (2)
to whom the user has not blocked outbound presence, and (3) from whom
the server has not received a presence error during the user’s
session; the user’s server MUST also send that unavailable presence
stanza to any of the user’s other available resources, as well as to
any entities to which the user has sent directed presence during the
user’s session for that resource (if the user has not yet sent
directed unavailable presence to that entity). Any presence stanza
with no ’type’ attribute and no ’to’ attribute that is sent after
sending directed unavailable presence or broadcasted unavailable
presence MUST be broadcasted by the server to all subscribers.
5.1.6. Presence Subscriptions
A subscription request is a presence stanza whose ’type’ attribute
has a value of "subscribe". If the subscription request is being
sent to an instant messaging contact, the JID supplied in the ’to’
attribute SHOULD be of the form <contact@example.org> rather than
<contact@example.org/resource>, since the desired result is normally
for the user to receive presence from all of the contact’s resources,
not merely the particular resource specified in the ’to’ attribute.
A user’s server MUST NOT automatically approve subscription requests
on the user’s behalf. All subscription requests MUST be directed to
the user’s client, specifically to one or more available resources
associated with the user. If there is no available resource
associated with the user when the subscription request is received by
the user’s server, the user’s server MUST keep a record of the
subscription request and deliver the request when the user next
creates an available resource, until the user either approves or
denies the request. If there is more than one available resource
associated with the user when the subscription request is received by
the user’s server, the user’s server MUST broadcast that subscription
request to all available resources in accordance with Server Rules
for Handling XML Stanzas (Section 11). (Note: If an active resource
has not provided initial presence, the server MUST NOT consider it to
be available and therefore MUST NOT send subscription requests to
it.) However, if the user receives a presence stanza of type
"subscribe" from a contact to whom the user has already granted
permission to see the user’s presence information (e.g., in cases
when the contact is seeking to resynchronize subscription states),
the user’s server SHOULD auto-reply on behalf of the user. In
addition, the user’s server MAY choose to re-send an unapproved
pending subscription request to the contact based on an
implementation-specific algorithm (e.g., whenever a new resource
becomes available for the user, or after a certain amount of time has
elapsed); this helps to recover from transient, silent errors that
may have occurred in relation to the original subscription request.
5.2. Specifying Availability Status
A client MAY provide further information about its availability
status by using the <show/> element (see Show (Section 2.2.2.1)).
Example: Availability status:
<presence>
<show>dnd</show>
</presence>
5.3. Specifying Detailed Status Information
In conjunction with the <show/> element, a client MAY provide
detailed status information by using the <status/> element (see
Status (Section 2.2.2.2)).
Example: Detailed status information:
<presence xml:lang=’en’>
<show>dnd</show>
<status>Wooing Juliet</status>
<status xml:lang=’cz’>Ja dvořím Juliet</status>
</presence>
5.4. Specifying Presence Priority
A client MAY provide a priority for its resource by using the
<priority/> element (see Priority (Section 2.2.2.3)).
Example: Presence priority:
<presence xml:lang=’en’>
<show>dnd</show>
<status>Wooing Juliet</status>
<status xml:lang=’cz’>Ja dvořím Juliet</status>
<priority>1</priority>
</presence>
5.5. Presence Examples
The examples in this section illustrate the presence-related
protocols described above. The user is romeo@example.net, he has an
available resource whose resource identifier is "orchard", and he has
the following individuals in his roster:
o juliet@example.com (subscription="both" and she has two available
resources, one whose resource is "chamber" and another whose
resource is "balcony")
o benvolio@example.org (subscription="to")
o mercutio@example.org (subscription="from")
Example 1: User sends initial presence:
<presence/>
Example 2: User’s server sends presence probes to contacts with
subscription="to" and subscription="both" on behalf of the user’s
available resource:
<presence
type=’probe’
from=’romeo@example.net/orchard’
to=’juliet@example.com’/>
<presence
type=’probe’
from=’romeo@example.net/orchard’
to=’benvolio@example.org’/>
Example 3: User’s server sends initial presence to contacts with
subscription="from" and subscription="both" on behalf of the user’s
available resource:
<presence
from=’romeo@example.net/orchard’
to=’juliet@example.com’/>
<presence
from=’romeo@example.net/orchard’
to=’mercutio@example.org’/>
Example 4: Contacts’ servers reply to presence probe on behalf of all
available resources:
<presence
from=’juliet@example.com/balcony’
to=’romeo@example.net/orchard’
xml:lang=’en’>
<show>away</show>
<status>be right back</status>
<priority>0</priority>
</presence>
<presence
from=’juliet@example.com/chamber’
to=’romeo@example.net/orchard’>
<priority>1</priority>
</presence>
<presence
from=’benvolio@example.org/pda’
to=’romeo@example.net/orchard’
xml:lang=’en’>
<show>dnd</show>
<status>gallivanting</status>
</presence>
Example 5: Contacts’ servers deliver user’s initial presence to all
available resources or return error to user:
<presence
from=’romeo@example.net/orchard’
to=’juliet@example.com/chamber’/>
<presence
from=’romeo@example.net/orchard’
to=’juliet@example.com/balcony’/>
<presence
type=’error’
from=’mercutio@example.org’
to=’romeo@example.net/orchard’>
<error type=’cancel’>
<gone xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’/>
</error>
</presence>
Example 6: User sends directed presence to another user not in his
roster:
<presence
from=’romeo@example.net/orchard’
to=’nurse@example.com’
xml:lang=’en’>
<show>dnd</show>
<status>courting Juliet</status>
<priority>0</priority>
</presence>
Example 7: User sends updated available presence information for
broadcasting:
<presence xml:lang=’en’>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
Example 8: User’s server broadcasts updated presence information only