draft-ietf-xmpp-3921bis-15.txt   draft-ietf-xmpp-3921bis-16.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 3921 (if approved) October 6, 2010 Obsoletes: 3921 (if approved) October 20, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: April 9, 2011 Expires: April 23, 2011
Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and
Presence Presence
draft-ietf-xmpp-3921bis-15 draft-ietf-xmpp-3921bis-16
Abstract Abstract
This document defines extensions to core features of the Extensible This document defines extensions to core features of the Extensible
Messaging and Presence Protocol (XMPP) that provide basic instant Messaging and Presence Protocol (XMPP) that provide basic instant
messaging (IM) and presence functionality in conformance with the messaging (IM) and presence functionality in conformance with the
requirements in RFC 2779. This document obsoletes RFC 3921. requirements in RFC 2779. This document obsoletes RFC 3921.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 9, 2011. This Internet-Draft will expire on April 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 33 skipping to change at page 3, line 33
4.2. Initial Presence . . . . . . . . . . . . . . . . . . . . 51 4.2. Initial Presence . . . . . . . . . . . . . . . . . . . . 51
4.2.1. Client Generation of Initial Presence . . . . . . . . 51 4.2.1. Client Generation of Initial Presence . . . . . . . . 51
4.2.2. Server Processing of Outbound Initial Presence . . . 51 4.2.2. Server Processing of Outbound Initial Presence . . . 51
4.2.3. Server Processing of Inbound Initial Presence . . . . 52 4.2.3. Server Processing of Inbound Initial Presence . . . . 52
4.2.4. Client Processing of Initial Presence . . . . . . . . 52 4.2.4. Client Processing of Initial Presence . . . . . . . . 52
4.3. Presence Probes . . . . . . . . . . . . . . . . . . . . . 53 4.3. Presence Probes . . . . . . . . . . . . . . . . . . . . . 53
4.3.1. Server Generation of Outbound Presence Probe . . . . 53 4.3.1. Server Generation of Outbound Presence Probe . . . . 53
4.3.2. Server Processing of Inbound Presence Probe . . . . . 54 4.3.2. Server Processing of Inbound Presence Probe . . . . . 54
4.4. Subsequent Presence Broadcast . . . . . . . . . . . . . . 57 4.4. Subsequent Presence Broadcast . . . . . . . . . . . . . . 57
4.4.1. Client Generation of Subsequent Presence Broadcast . 57 4.4.1. Client Generation of Subsequent Presence Broadcast . 57
4.4.2. Server Processing of Outbound Presence . . . . . . . 57 4.4.2. Server Processing of Outbound Presence . . . . . . . 58
4.4.3. Server Processing of Inbound Presence . . . . . . . . 59 4.4.3. Server Processing of Inbound Presence . . . . . . . . 59
4.4.4. Client Processing of Subsequent Presence . . . . . . 59 4.4.4. Client Processing of Subsequent Presence . . . . . . 59
4.5. Unavailable Presence . . . . . . . . . . . . . . . . . . 59 4.5. Unavailable Presence . . . . . . . . . . . . . . . . . . 59
4.5.1. Client Generation of Unavailable Presence . . . . . . 59 4.5.1. Client Generation of Unavailable Presence . . . . . . 59
4.5.2. Server Processing of Outbound Unavailable Presence . 60 4.5.2. Server Processing of Outbound Unavailable Presence . 60
4.5.3. Server Processing of Inbound Unavailable Presence . . 61 4.5.3. Server Processing of Inbound Unavailable Presence . . 61
4.5.4. Client Processing of Unavailable Presence . . . . . . 62 4.5.4. Client Processing of Unavailable Presence . . . . . . 62
4.6. Directed Presence . . . . . . . . . . . . . . . . . . . . 62 4.6. Directed Presence . . . . . . . . . . . . . . . . . . . . 62
4.6.1. General Considerations . . . . . . . . . . . . . . . 62 4.6.1. General Considerations . . . . . . . . . . . . . . . 62
4.6.2. Client Generation of Directed Presence . . . . . . . 63 4.6.2. Client Generation of Directed Presence . . . . . . . 63
skipping to change at page 9, line 13 skipping to change at page 9, line 13
(See Section 5, Section 3, Section 2, and Section 6.) (See Section 5, Section 3, Section 2, and Section 6.)
4. Terminate the session when desired by sending unavailable 4. Terminate the session when desired by sending unavailable
presence and closing the underlying XML stream. (See presence and closing the underlying XML stream. (See
Section 4.5.) Section 4.5.)
1.5. Conventions 1.5. Conventions
This document inherits the terminology defined in [XMPP-CORE]. This document inherits the terminology defined in [XMPP-CORE].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[KEYWORDS]. [KEYWORDS].
For convenience, this document employs the term "user" to refer to For convenience, this document employs the term "user" to refer to
the owner of an XMPP account; however, account owners need not be the owner of an XMPP account; however, account owners need not be
natural persons and can be bots, devices, or other automated natural persons and can be bots, devices, or other automated
applications. applications.
Following the "XML Notation" used in [IRI] to represent characters Following the "XML Notation" used in [IRI] to represent characters
skipping to change at page 16, line 28 skipping to change at page 16, line 28
<query/> element qualified by the 'jabber:iq:roster' namespace. <query/> element qualified by the 'jabber:iq:roster' namespace.
The following rules apply to roster pushes: The following rules apply to roster pushes:
1. The <query/> element in a roster push MUST contain one and only 1. The <query/> element in a roster push MUST contain one and only
one <item/> element. one <item/> element.
2. A receiving client MUST ignore the stanza unless it has no 'from' 2. A receiving client MUST ignore the stanza unless it has no 'from'
attribute (i.e., implicitly from the bare JID of the user's attribute (i.e., implicitly from the bare JID of the user's
account) or it has a 'from' attribute whose value matches the account) or it has a 'from' attribute whose value matches the
user's bare JID <user@domain>. user's bare JID <user@domainpart>.
S: <iq id='a78b4q6ha463' S: <iq id='a78b4q6ha463'
to='juliet@example.com/chamber' to='juliet@example.com/chamber'
type='set'> type='set'>
<query xmlns='jabber:iq:roster'> <query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'/> <item jid='nurse@example.com'/>
</query> </query>
</iq> </iq>
As mandated by the semantics of the IQ stanza as defined in As mandated by the semantics of the IQ stanza as defined in
skipping to change at page 23, line 49 skipping to change at page 23, line 49
S: <iq id='qh3b4v19' S: <iq id='qh3b4v19'
to='juliet@example.com/balcony' to='juliet@example.com/balcony'
type='error'> type='error'>
<error type='modify'> <error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
Interoperability Note: Some servers return a <not-allowed/> stanza Interoperability Note: Some servers return a <not-allowed/> stanza
error to the client if the value of the <item/> element's 'jid' error to the client if the value of the <item/> element's 'jid'
attribute matches the bare JID <node@domain> of the user's attribute matches the bare JID <localpart@domainpart> of the
account. user's account.
2.4. Updating a Roster Item 2.4. Updating a Roster Item
2.4.1. Request 2.4.1. Request
Updating an existing roster item is done in the same way as adding a Updating an existing roster item is done in the same way as adding a
new roster item, i.e., by sending a roster set to the server. new roster item, i.e., by sending a roster set to the server.
Because a roster item is atomic, the item MUST be updated exactly as Because a roster item is atomic, the item MUST be updated exactly as
provided in the roster set. provided in the roster set.
skipping to change at page 32, line 18 skipping to change at page 32, line 18
lasts until the contact unsubscribes or the user cancels the lasts until the contact unsubscribes or the user cancels the
previously-granted subscription. previously-granted subscription.
Subscriptions are managed within XMPP by sending presence stanzas Subscriptions are managed within XMPP by sending presence stanzas
containing specially-defined attributes ("subscribe", "unsubscribe", containing specially-defined attributes ("subscribe", "unsubscribe",
"subscribed", and "unsubscribed"). "subscribed", and "unsubscribed").
Implementation Note: When a server processes or generates an Implementation Note: When a server processes or generates an
outbound presence stanza of type "subscribe", "subscribed", outbound presence stanza of type "subscribe", "subscribed",
"unsubscribe", or "unsubscribed", the server MUST stamp the "unsubscribe", or "unsubscribed", the server MUST stamp the
outgoing presence stanza with the bare JID <node@domain> of the outgoing presence stanza with the bare JID <nodepart@domainpart>
sending entity, not the full JID <node@domain/resource>. of the sending entity, not the full JID
Enforcement of this rule simplifies the presence subscription <localpart@domainpart/resourcepart>. Enforcement of this rule
model and helps to prevent presence leaks; for information about simplifies the presence subscription model and helps to prevent
presence leaks, refer to the security considerations of presence leaks; for information about presence leaks, refer to the
[XMPP-CORE]. security considerations of [XMPP-CORE].
Subscription states are reflected in the rosters of both the user and Subscription states are reflected in the rosters of both the user and
the contact. This section does not cover every possible case related the contact. This section does not cover every possible case related
to presence subscriptions, and mainly narrates the protocol flows for to presence subscriptions, and mainly narrates the protocol flows for
bootstrapping a mutual subscription between a user and a contact. bootstrapping a mutual subscription between a user and a contact.
Complete details regarding subscription states can be found in Complete details regarding subscription states can be found in
Appendix A. Appendix A.
3.1. Requesting a Subscription 3.1. Requesting a Subscription
skipping to change at page 33, line 18 skipping to change at page 33, line 18
presence stanza of type "subscribe" and specifying a 'to' address of presence stanza of type "subscribe" and specifying a 'to' address of
the potential contact's bare JID <contact@domain>. the potential contact's bare JID <contact@domain>.
UC: <presence id='xk3h1v69' UC: <presence id='xk3h1v69'
to='juliet@example.com' to='juliet@example.com'
type='subscribe'/> type='subscribe'/>
When a user sends a presence subscription request to a potential When a user sends a presence subscription request to a potential
instant messaging and presence contact, the value of the 'to' instant messaging and presence contact, the value of the 'to'
attribute MUST be a bare JID <contact@domain> rather a full JID attribute MUST be a bare JID <contact@domain> rather a full JID
<contact@domain/resource>, since the desired result is for the user <contact@domainpart/resourcepart>, since the desired result is for
to receive presence from all of the contact's resources, not merely the user to receive presence from all of the contact's resources, not
the particular resource specified in the 'to' attribute. Use of bare merely the particular resource specified in the 'to' attribute. Use
JIDs also simplifies subscription processing, presence probes, and of bare JIDs also simplifies subscription processing, presence
presence notifications by the user's server and the contact's server. probes, and presence notifications by the user's server and the
contact's server.
For tracking purposes, a client SHOULD include an 'id' attribute in a For tracking purposes, a client SHOULD include an 'id' attribute in a
presence subscription request. presence subscription request.
Implementation Note: Many XMPP clients prompt the user for Implementation Note: Many XMPP clients prompt the user for
information about the potential contact (e.g., "handle" and information about the potential contact (e.g., "handle" and
desired roster group) when generating an outbound presence desired roster group) when generating an outbound presence
subscription request and therefore send a roster set before subscription request and therefore send a roster set before
sending the outbound presence subscription request. This behavior sending the outbound presence subscription request. This behavior
is OPTIONAL, because a client MAY instead wait until receiving the is OPTIONAL, because a client MAY instead wait until receiving the
skipping to change at page 33, line 44 skipping to change at page 33, line 45
information about the contact. A server MUST process a roster set information about the contact. A server MUST process a roster set
and outbound presence subscription request in either order. and outbound presence subscription request in either order.
3.1.2. Server Processing of Outbound Subscription Request 3.1.2. Server Processing of Outbound Subscription Request
Upon receiving the outbound presence subscription request, the user's Upon receiving the outbound presence subscription request, the user's
server MUST proceed as follows. server MUST proceed as follows.
1. Before processing the request, the user's server SHOULD check the 1. Before processing the request, the user's server SHOULD check the
syntax of the JID contained in the 'to' attribute. If the JID is syntax of the JID contained in the 'to' attribute. If the JID is
of the form <contact@domain/resource> instead of of the form <contact@domainpart/resourcepart> instead of
<contact@domain>, the user's server SHOULD treat it as if the <contact@domain>, the user's server SHOULD treat it as if the
request had been directed to the contact's bare JID and modify request had been directed to the contact's bare JID and modify
the 'to' address accordingly. The server MAY also verify that the 'to' address accordingly. The server MAY also verify that
the JID adheres to the format defined in [XMPP-ADDR] and possibly the JID adheres to the format defined in [XMPP-ADDR] and possibly
return a <jid-malformed/> stanza error. return a <jid-malformed/> stanza error.
2. If the potential contact is hosted on the same server as the 2. If the potential contact is hosted on the same server as the
user, then the server MUST adhere to the rules specified in the user, then the server MUST adhere to the rules specified in the
next section in processing the subscription request and next section in processing the subscription request and
delivering it to the (local) contact. delivering it to the (local) contact.
3. If the potential contact is hosted on a remote server, subject to 3. If the potential contact is hosted on a remote server, subject to
local service policies the user's server MUST then route the local service policies the user's server MUST then route the
stanza to that remote domain in accordance with core XMPP stanza stanza to that remote domain in accordance with core XMPP stanza
processing rules. (This can result in returning an appropriate processing rules. (This can result in returning an appropriate
stanza error to the user, such as <remote-server-timeout/>.) stanza error to the user, such as <remote-server-timeout/>.)
As mentioned, before locally delivering or remotely routing the As mentioned, before locally delivering or remotely routing the
presence subscription request, the user's server MUST stamp the presence subscription request, the user's server MUST stamp the
outbound subscription request with the bare JID <user@domain> of the outbound subscription request with the bare JID <user@domainpart> of
user. the user.
US: <presence from='romeo@example.net' US: <presence from='romeo@example.net'
id='xk3h1v69' id='xk3h1v69'
to='juliet@example.com' to='juliet@example.com'
type='subscribe'/> type='subscribe'/>
If the presence subscription request cannot be locally delivered or If the presence subscription request cannot be locally delivered or
remotely routed (e.g., because the request is malformed, the local remotely routed (e.g., because the request is malformed, the local
contact does not exist, the remote server does not exist, an attempt contact does not exist, the remote server does not exist, an attempt
to contact the remote server times out, or any other error determined to contact the remote server times out, or any other error determined
skipping to change at page 35, line 41 skipping to change at page 35, line 41
elapsed); this helps to recover from transient, silent errors that elapsed); this helps to recover from transient, silent errors that
might have occurred when the original subscription request was routed might have occurred when the original subscription request was routed
to the remote domain. When doing so, it is RECOMMENDED for the to the remote domain. When doing so, it is RECOMMENDED for the
server to include an 'id' attribute so that it can track responses to server to include an 'id' attribute so that it can track responses to
the resent subscription request. the resent subscription request.
3.1.3. Server Processing of Inbound Subscription Request 3.1.3. Server Processing of Inbound Subscription Request
Before processing the inbound presence subscription request, the Before processing the inbound presence subscription request, the
contact's server SHOULD check the syntax of the JID contained in the contact's server SHOULD check the syntax of the JID contained in the
'to' attribute. If the JID is of the form <contact@domain/resource> 'to' attribute. If the JID is of the form
instead of <contact@domain>, the contact's server SHOULD treat it as <contact@domainpart/resourcepart> instead of <contact@domain>, the
if the request had been directed to the contact's bare JID and modify contact's server SHOULD treat it as if the request had been directed
the 'to' address accordingly. The server MAY also verify that the to the contact's bare JID and modify the 'to' address accordingly.
JID adheres to the format defined in [XMPP-ADDR] and possibly return The server MAY also verify that the JID adheres to the format defined
a <jid-malformed/> stanza error. in [XMPP-ADDR] and possibly return a <jid-malformed/> stanza error.
When processing the inbound presence subscription request, the When processing the inbound presence subscription request, the
contact's server MUST adhere to the following rules: contact's server MUST adhere to the following rules:
1. Above all, the contact's server MUST NOT automatically approve 1. Above all, the contact's server MUST NOT automatically approve
subscription requests on the contact's behalf -- unless the subscription requests on the contact's behalf -- unless the
contact has (a) pre-approved subscription requests from the user contact has (a) pre-approved subscription requests from the user
as described under Section 3.4, (b) configured its account to as described under Section 3.4, (b) configured its account to
automatically approve subscription requests, or (c) accepted an automatically approve subscription requests, or (c) accepted an
agreement with its service provider that allows automatic agreement with its service provider that allows automatic
skipping to change at page 45, line 23 skipping to change at page 45, line 23
processing the subscription request. processing the subscription request.
2. If the contact is hosted on a remote server, subject to local 2. If the contact is hosted on a remote server, subject to local
service policies the user's server MUST then route the stanza to service policies the user's server MUST then route the stanza to
that remote domain in accordance with core XMPP stanza processing that remote domain in accordance with core XMPP stanza processing
rules. (This can result in returning an appropriate stanza error rules. (This can result in returning an appropriate stanza error
to the user, such as <remote-server-timeout/>.) to the user, such as <remote-server-timeout/>.)
As mentioned, before locally delivering or remotely routing the As mentioned, before locally delivering or remotely routing the
unsubscribe, the user's server MUST stamp the stanza with the bare unsubscribe, the user's server MUST stamp the stanza with the bare
JID <user@domain> of the user. JID <user@domainpart> of the user.
US: <presence from='romeo@example.net' US: <presence from='romeo@example.net'
id='ul4bs71n' id='ul4bs71n'
to='juliet@example.com' to='juliet@example.com'
type='unsubscribe'/> type='unsubscribe'/>
The user's server then MUST send a roster push with the updated The user's server then MUST send a roster push with the updated
roster item to all of the user's interested resources, where the roster item to all of the user's interested resources, where the
subscription state is now either "none" or "from" (see Appendix A). subscription state is now either "none" or "from" (see Appendix A).
skipping to change at page 51, line 35 skipping to change at page 51, line 35
UC: <presence/> UC: <presence/>
The initial presence stanza MAY contain the <priority/> element, the The initial presence stanza MAY contain the <priority/> element, the
<show/> element, and one or more instances of the <status/> element, <show/> element, and one or more instances of the <status/> element,
as well as extended content; see Section 4.7 for details. as well as extended content; see Section 4.7 for details.
4.2.2. Server Processing of Outbound Initial Presence 4.2.2. Server Processing of Outbound Initial Presence
Upon receiving initial presence from a client, the user's server MUST Upon receiving initial presence from a client, the user's server MUST
send the initial presence stanza from the full JID send the initial presence stanza from the full JID
<user@domain/resource> of the user to all contacts that are <user@domainpart/resourcepart> of the user to all contacts that are
subscribed to the user's presence; such contacts are those for which subscribed to the user's presence; such contacts are those for which
a JID is present in the user's roster with the 'subscription' a JID is present in the user's roster with the 'subscription'
attribute set to a value of "from" or "both". attribute set to a value of "from" or "both".
US: <presence from='juliet@example.com/balcony' US: <presence from='juliet@example.com/balcony'
to='romeo@example.net'/> to='romeo@example.net'/>
US: <presence from='juliet@example.com/balcony' US: <presence from='juliet@example.com/balcony'
to='mercutio@example.com'/> to='mercutio@example.com'/>
skipping to change at page 53, line 47 skipping to change at page 53, line 47
since the task of gathering presence from a user's contacts is since the task of gathering presence from a user's contacts is
managed by the user's server. However, if a client generates an managed by the user's server. However, if a client generates an
outbound presence probe then the user's server SHOULD route the outbound presence probe then the user's server SHOULD route the
probe (if the contact is at another server) or process the probe probe (if the contact is at another server) or process the probe
(if the contact is at the same server) and MUST NOT return a (if the contact is at the same server) and MUST NOT return a
stanza or stream error to the client. stanza or stream error to the client.
4.3.1. Server Generation of Outbound Presence Probe 4.3.1. Server Generation of Outbound Presence Probe
When a server needs to discover the availability of a user's contact, When a server needs to discover the availability of a user's contact,
it sends a presence probe from the bare JID <user@domain> of the user it sends a presence probe from the bare JID <user@domainpart> of the
to the bare JID <contact@domain> of the contact. user to the bare JID <contact@domain> of the contact.
Implementation Note: Although presence probes are intended for Implementation Note: Although presence probes are intended for
sending to contacts (i.e., entities to which a user is sending to contacts (i.e., entities to which a user is
subscribed), a server MAY send a presence probe to the full JID of subscribed), a server MAY send a presence probe to the full JID of
an entity from which the user has received presence information an entity from which the user has received presence information
during the current session. during the current session.
The user's server SHOULD send a presence probe whenever the user The user's server SHOULD send a presence probe whenever the user
starts a new presence session by sending initial presence; however, starts a new presence session by sending initial presence; however,
the server MAY choose not to send the probe at that point if it has the server MAY choose not to send the probe at that point if it has
skipping to change at page 56, line 33 skipping to change at page 56, line 33
CS: <presence from='romeo@example.net/foo' CS: <presence from='romeo@example.net/foo'
id='hzf1v27k' id='hzf1v27k'
to='juliet@example.com'/> to='juliet@example.com'/>
CS: <presence from='romeo@example.net/bar' CS: <presence from='romeo@example.net/bar'
id='ps6t1fu3' id='ps6t1fu3'
to='juliet@example.com'> to='juliet@example.com'>
<show>away</show> <show>away</show>
</presence> </presence>
Implementation Note: By "full XML" is meant the complete stanza
from the opening <presence> tag to the closing </presence> tag,
including all elements and attributes whether qualified by the
content namespace or extended namespaces; however, in accordance
with [XMPP-CORE], the contact's server will need to transform the
content namespace from 'jabber:client' to 'jabber:server' if it
sends the complete stanza over a server-to-server stream.
If the contact's server receives a presence probe addressed to a full If the contact's server receives a presence probe addressed to a full
JID of the contact, the server MUST NOT return presence information JID of the contact, the server MUST NOT return presence information
about any resource except the resource specified by the 'to' address about any resource except the resource specified by the 'to' address
of the probe. Rules #1 and #2 for a bare JID probe apply equally to of the probe. Rules #1 and #2 for a bare JID probe apply equally to
the case of a full JID probe. If there is a resource matching the the case of a full JID probe. If there is a resource matching the
full JID and the probing entity has authorization via a presence full JID and the probing entity has authorization via a presence
subscription to see the contact's presence, then the server MUST subscription to see the contact's presence, then the server MUST
return an available presence notification, which SHOULD communicate return an available presence notification, which SHOULD communicate
only the fact that the resource is available (not detailed only the fact that the resource is available (not detailed
information such as the <show/>, <status/>, <priority/>, or presence information such as the <show/>, <status/>, <priority/>, or presence
skipping to change at page 70, line 26 skipping to change at page 70, line 26
contact (rather than sending a single message to which no reply is contact (rather than sending a single message to which no reply is
expected), the message type generated by the user's client SHOULD be expected), the message type generated by the user's client SHOULD be
"chat" and the contact's client SHOULD preserve that message type in "chat" and the contact's client SHOULD preserve that message type in
subsequent replies. The user's client also SHOULD include a subsequent replies. The user's client also SHOULD include a
<thread/> element with its initial message, which the contact's <thread/> element with its initial message, which the contact's
client SHOULD also preserve during the life of the chat session (see client SHOULD also preserve during the life of the chat session (see
Section 5.2.5). Section 5.2.5).
The user's client SHOULD address the initial message in a chat The user's client SHOULD address the initial message in a chat
session to the bare JID <contact@domain> of the contact (rather than session to the bare JID <contact@domain> of the contact (rather than
attempting to guess an appropriate full JID <contact@domain/resource> attempting to guess an appropriate full JID
based on the <show/>, <status/>, or <priority/> value of any presence <contact@domainpart/resourcepart> based on the <show/>, <status/>, or
notifications it has received from the contact). Until and unless <priority/> value of any presence notifications it has received from
the user's client receives a reply from the contact, it SHOULD send the contact). Until and unless the user's client receives a reply
any further messages to the contact's bare JID. The contact's client from the contact, it SHOULD send any further messages to the
SHOULD address its replies to the user's full JID contact's bare JID. The contact's client SHOULD address its replies
<user@domain/resource> as provided in the 'from' address of the to the user's full JID <user@domainpart/resourcepart> as provided in
initial message. Once the user's client receives a reply from the the 'from' address of the initial message. Once the user's client
contact's full JID, it SHOULD address its subsequent messages to the receives a reply from the contact's full JID, it SHOULD address its
contact's full JID as provided in the 'from' address of the contact's subsequent messages to the contact's full JID as provided in the
replies, thus "locking in" on that full JID. A client SHOULD 'from' address of the contact's replies, thus "locking in" on that
"unlock" after having received a <message/> or <presence/> stanza full JID. A client SHOULD "unlock" after having received a
from any other resource controlled by the peer (or a presence stanza <message/> or <presence/> stanza from any other resource controlled
from the locked resource); as a result, it SHOULD address its next by the peer (or a presence stanza from the locked resource); as a
message(s) in the chat session to the bare JID of the peer (thus result, it SHOULD address its next message(s) in the chat session to
"unlocking" the previous "lock") until it receives a message from one the bare JID of the peer (thus "unlocking" the previous "lock") until
of the peer's full JIDs. it receives a message from one of the peer's full JIDs.
When two parties engage in a chat session but do not share presence When two parties engage in a chat session but do not share presence
with each other based on a presence subscription, they SHOULD send with each other based on a presence subscription, they SHOULD send
directed presence to each other so that either party can easily directed presence to each other so that either party can easily
discover if the peer changes its availability or goes offline during discover if the peer changes its availability or goes offline during
the course of the chat session. However, a client MUST provide a way the course of the chat session. However, a client MUST provide a way
for a user to disable such presence sharing globally or to enable it for a user to disable such presence sharing globally or to enable it
only with particular entities. Furthermore, a party SHOULD send only with particular entities. Furthermore, a party SHOULD send
directed unavailable presence to the peer when it has reason to directed unavailable presence to the peer when it has reason to
believe that the chat session is over (e.g., if, after some believe that the chat session is over (e.g., if, after some
skipping to change at page 71, line 22 skipping to change at page 71, line 22
The following sections describe the syntax of the <message/> stanza. The following sections describe the syntax of the <message/> stanza.
5.2.1. To Attribute 5.2.1. To Attribute
An instant messaging client specifies an intended recipient for a An instant messaging client specifies an intended recipient for a
message by providing the JID of the intended recipient in the 'to' message by providing the JID of the intended recipient in the 'to'
attribute of the <message/> stanza. attribute of the <message/> stanza.
If the message is being sent outside the context of any existing chat 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 session or received message, the value of the 'to' address SHOULD be
of the form <user@domain> rather than of the form of the form <user@domainpart> rather than of the form
<user@domain/resource> (see Section 5.1). <user@domainpart/resourcepart> (see Section 5.1).
<message <message
from='juliet@example.com/balcony' from='juliet@example.com/balcony'
id='ktx72v49' id='ktx72v49'
to='romeo@example.net' to='romeo@example.net'
type='chat' type='chat'
xml:lang='en'> xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body> <body>Art thou not Romeo, and a Montague?</body>
</message> </message>
If the message is being sent in reply to a message previously If the message is being sent in reply to a message previously
received from an address of the form <user@domain/resource> (e.g., received from an address of the form <user@domainpart/resourcepart>
within the context of a one-to-one chat session as described under (e.g., within the context of a one-to-one chat session as described
Section 5.1), the value of the 'to' address SHOULD be of the form under Section 5.1), the value of the 'to' address SHOULD be of the
<user@domain/resource> rather than of the form <user@domain> unless form <user@domainpart/resourcepart> rather than of the form
the sender has knowledge (e.g., via presence) that the intended <user@domainpart> unless the sender has knowledge (e.g., via
recipient's resource is no longer available. presence) that the intended recipient's resource is no longer
available.
<message <message
from='romeo@example.net/orchard' from='romeo@example.net/orchard'
id='sl3nx51f' id='sl3nx51f'
to='juliet@example.com/balcony' to='juliet@example.com/balcony'
type='chat' type='chat'
xml:lang='en'> xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body> <body>Neither, fair saint, if either thee dislike.</body>
</message> </message>
skipping to change at page 87, line 29 skipping to change at page 87, line 29
8.4. Local Domain 8.4. Local Domain
If the domainpart of the JID contained in the 'to' attribute matches If the domainpart of the JID contained in the 'to' attribute matches
one of the configured domains of the server, the domain is serviced one of the configured domains of the server, the domain is serviced
by the server itself (not by a specialized local service), and the by the server itself (not by a specialized local service), and the
JID is of the form <domainpart> or <domainpart/resourcepart>, the JID is of the form <domainpart> or <domainpart/resourcepart>, the
rules defined in [XMPP-CORE] apply. rules defined in [XMPP-CORE] apply.
8.5. Localpart at Domain 8.5. Localpart at Domain
If the 'to' address specifies a bare JID <user@domain> or full JID If the 'to' address specifies a bare JID <user@domainpart> or full
<user@domain/resourcepart> where the domainpart of the JID matches a JID <user@domainpart/resourcepart> where the domainpart of the JID
configured domain that is serviced by the server itself, the server matches a configured domain that is serviced by the server itself,
MUST proceed as follows. the server MUST proceed as follows.
8.5.1. No Such User 8.5.1. No Such User
If the user account identified by the 'to' attribute does not exist, If the user account identified by the 'to' attribute does not exist,
how the stanza is processed depends on the stanza type. how the stanza is processed depends on the stanza type.
o For an IQ stanza, the server MUST return a <service-unavailable/> o For an IQ stanza, the server MUST return a <service-unavailable/>
stanza error to the sender. stanza error to the sender.
o For a message stanza, the server MUST either (a) silently ignore o For a message stanza, the server MUST either (a) silently ignore
skipping to change at page 88, line 16 skipping to change at page 88, line 16
"unsubscribe", or "unsubscribed", the server MUST silently ignore "unsubscribe", or "unsubscribed", the server MUST silently ignore
the stanza. the stanza.
o For a presence stanza of type "probe", the server MUST either (a) o For a presence stanza of type "probe", the server MUST either (a)
silently ignore the stanza or (b) return a presence stanza of type silently ignore the stanza or (b) return a presence stanza of type
"unsubscribed". "unsubscribed".
8.5.2. Bare JID 8.5.2. Bare JID
If the JID contained in the 'to' attribute is of the form If the JID contained in the 'to' attribute is of the form
<user@domain>, then the server MUST adhere to the following rules. <user@domainpart>, then the server MUST adhere to the following
rules.
8.5.2.1. Available or Connected Resources 8.5.2.1. Available or Connected Resources
If there is at least one available resource or connected resource, If there is at least one available resource or connected resource,
how the stanza is processed depends on the stanza type. how the stanza is processed depends on the stanza type.
8.5.2.1.1. Message 8.5.2.1.1. Message
For a message stanza of type "normal": For a message stanza of type "normal":
skipping to change at page 89, line 45 skipping to change at page 89, line 45
For a message stanza of type "error", the server MUST silently ignore For a message stanza of type "error", the server MUST silently ignore
the message. the message.
However, for any message type the server MUST NOT deliver the stanza However, for any message type the server MUST NOT deliver the stanza
to any available resource with a negative priority; if the only to any available resource with a negative priority; if the only
available resource has a negative priority, the server SHOULD handle available resource has a negative priority, the server SHOULD handle
the message as if there were no available resources or connected the message as if there were no available resources or connected
resources as described under Section 8.5.2.2. resources as described under Section 8.5.2.2.
In all cases, the server MUST NOT rewrite the 'to' attribute (i.e., In all cases, the server MUST NOT rewrite the 'to' attribute (i.e.,
it MUST leave it as <user@domain> rather than change it to it MUST leave it as <user@domainpart> rather than change it to
<user@domain/resource>). <user@domainpart/resourcepart>).
8.5.2.1.2. Presence 8.5.2.1.2. Presence
For a presence stanza with no type or of type "unavailable", the For a presence stanza with no type or of type "unavailable", the
server MUST deliver it to all available resources. server MUST deliver it to all available resources.
For a presence stanza of type "subscribe", "subscribed", For a presence stanza of type "subscribe", "subscribed",
"unsubscribe", or "unsubscribed", the server MUST adhere to the rules "unsubscribe", or "unsubscribed", the server MUST adhere to the rules
defined under Section 3 and summarized under Appendix A. defined under Section 3 and summarized under Appendix A.
For a presence stanza of type "probe", the server MUST handle it For a presence stanza of type "probe", the server MUST handle it
directly as described under Section 4.3. directly as described under Section 4.3.
In all cases, the server MUST NOT rewrite the 'to' attribute (i.e., In all cases, the server MUST NOT rewrite the 'to' attribute (i.e.,
it MUST leave it as <user@domain> rather than change it to it MUST leave it as <user@domainpart> rather than change it to
<user@domain/resource>). <user@domainpart/resourcepart>).
8.5.2.1.3. IQ 8.5.2.1.3. IQ
For an IQ stanza, the server itself MUST reply on behalf of the user For an IQ stanza, 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 with either an IQ result or an IQ error, and MUST NOT deliver the IQ
stanza to any of the user's available resources. Specifically, if stanza to any of the user's available resources. Specifically, if
the semantics of the qualifying namespace define a reply that the the semantics of the qualifying namespace define a reply that the
server can provide on behalf of the user, then the server MUST reply server can provide on behalf of the user, then the server MUST reply
to the stanza on behalf of the user by returning either an IQ stanza to the stanza on behalf of the user by returning either an IQ stanza
of type "result" or an IQ stanza of type "error" that is appropriate of type "result" or an IQ stanza of type "error" that is appropriate
skipping to change at page 91, line 26 skipping to change at page 91, line 26
stanza on behalf of the user by returning either an IQ stanza of type stanza on behalf of the user by returning either an IQ stanza of type
"result" or an IQ stanza of type "error" that is appropriate to the "result" or an IQ stanza of type "error" that is appropriate to the
original payload; if not, then the server MUST reply with a <service- original payload; if not, then the server MUST reply with a <service-
unavailable/> stanza error. unavailable/> stanza error.
8.5.3. Full JID 8.5.3. Full JID
If the domainpart of the JID contained in the 'to' attribute of an If the domainpart of the JID contained in the 'to' attribute of an
inbound stanza matches one of the configured domains of the server inbound stanza matches one of the configured domains of the server
itself and the JID contained in the 'to' attribute is of the form itself and the JID contained in the 'to' attribute is of the form
<user@domain/resource>, then the server MUST adhere to the following <user@domainpart/resourcepart>, then the server MUST adhere to the
rules. following rules.
8.5.3.1. Resource Matches 8.5.3.1. Resource Matches
If an available resource or connected resource exactly matches the If an available resource or connected resource exactly matches the
full JID, how the stanza is processed depends on the stanza type. full JID, how the stanza is processed depends on the stanza type.
o For an IQ stanza of type "get" or "set", if the intended recipient o For an IQ stanza of type "get" or "set", if the intended recipient
does not share presence with the requesting entity either by means does not share presence with the requesting entity either by means
of a presence subscription of type "both" or "from" or by means of of a presence subscription of type "both" or "from" or by means of
directed presence, then the server SHOULD NOT deliver the IQ directed presence, then the server SHOULD NOT deliver the IQ
 End of changes. 25 change blocks. 
69 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/