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/