< draft-ietf-xmpp-cpim-04.txt		draft-ietf-xmpp-cpim-05.txt >
	XMPP Working Group P. Saint-Andre		XMPP Working Group P. Saint-Andre
	Internet-Draft Jabber Software Foundation		Internet-Draft Jabber Software Foundation
	Expires: September 6, 2004 March 8, 2004		Expires: November 1, 2004 May 3, 2004
	Mapping the Extensible Messaging and Presence Protocol (XMPP) to		Mapping the Extensible Messaging and Presence Protocol (XMPP) to
	Common Presence and Instant Messaging (CPIM)		Common Presence and Instant Messaging (CPIM)
	draft-ietf-xmpp-cpim-04		draft-ietf-xmpp-cpim-05
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	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."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 6, 2004.		This Internet-Draft will expire on November 1, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This memo describes a mapping of the Extensible Messaging and		This memo describes a mapping between the Extensible Messaging and
	Presence Protocol (XMPP) to the Common Presence and Instant Messaging		Presence Protocol (XMPP) and the Common Presence and Instant
	(CPIM) specifications.		Messaging (CPIM) specifications.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 5		3. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Syntax Mapping of Instant Messages . . . . . . . . . . . . . . 6		4. Syntax Mapping of Instant Messages . . . . . . . . . . . . . . 6
	5. Syntax Mapping of Presence Information . . . . . . . . . . . . 13		5. Syntax Mapping of Presence Information . . . . . . . . . . . . 13
	6. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . . . 26		6. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . . . 27
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 31		7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	Normative References . . . . . . . . . . . . . . . . . . . . . 31		Normative References . . . . . . . . . . . . . . . . . . . . . 32
	Informative References . . . . . . . . . . . . . . . . . . . . 33		Informative References . . . . . . . . . . . . . . . . . . . . 34
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 34
	A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 33		A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 34
	Intellectual Property and Copyright Statements . . . . . . . . 35		Intellectual Property and Copyright Statements . . . . . . . . 36
	1. Introduction		1. Introduction
	1.1 Overview		1.1 Overview
	The Instant Messaging and Presence (IMPP) Working Group has defined		The Instant Messaging and Presence (IMPP) Working Group has defined
	an abstract framework for interoperability among instant messaging		an abstract framework for interoperability among instant messaging
	(IM) and presence systems that are compliant with [IMP-REQS]. This		(IM) and presence systems that are compliant with [IMP-REQS]. This
	framework is commonly called Common Presence and Instant Messaging or		framework is commonly called Common Presence and Instant Messaging or
	"CPIM". The CPIM family of specifications include a Common Profile		"CPIM". The CPIM family of specifications include a Common Profile
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same		IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same
	meaning as defined therein.		meaning as defined therein.
	1.3 Conventions Used in this Document		1.3 Conventions Used in this Document
	The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",		The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		"SHALL NOT", "SHOULD", "SHOULD 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
	[TERMS].		[TERMS].
	1.4 Discussion Venue
	The author welcomes discussion and comments related to the topics
	presented in this document. The preferred forum is the
	<xmppwg@jabber.org> mailing list, for which archives and subscription
	information are available at <<http://www.jabber.org/cgi-bin/mailman/
	listinfo/xmppwg/>>.
	2. Approach		2. Approach
	XMPP and CPIM are distinctly foreign technologies. Therefore, care		XMPP and CPIM are distinctly foreign technologies. Therefore, care
	must be taken in mapping between XMPP and the abstract syntax defined		must be taken in mapping between XMPP and the abstract syntax defined
	by the CPIM specifications.		by the CPIM specifications.
	At root, XMPP is a data transport protocol for streaming XML elements		At root, XMPP is a data transport protocol for streaming XML elements
	(called "stanzas") between any two endpoints on the network; message		(called "stanzas") between any two endpoints on the network; message
	and presence stanzas are two of the core data elements defined in		and presence stanzas are two of the core data elements defined in
	XMPP and are often used to exchange instant messages and presence		XMPP and are often used to exchange instant messages and presence
	skipping to change at page 6, line 4 ¶		skipping to change at page 5, line 43 ¶
	to an im: or pres: URI:		to an im: or pres: URI:
	1. Split XMPP address into node identifier (local-part; mapping		1. Split XMPP address into node identifier (local-part; mapping
	described in remaining steps), domain identifier (hostname;		described in remaining steps), domain identifier (hostname;
	mapping is out of scope), and resource identifier (specifier for		mapping is out of scope), and resource identifier (specifier for
	particular device or connection; discard this for cross-system		particular device or connection; discard this for cross-system
	interoperability)		interoperability)
	2. Apply Nodeprep profile of [STRINGPREP] (as specified in		2. Apply Nodeprep profile of [STRINGPREP] (as specified in
	[XMPP-CORE]) for canonicalization (OPTIONAL)		[XMPP-CORE]) for canonicalization (OPTIONAL)
	3. Translate #26; to &, #27; to ', and #2f; to / respectively		3. Translate #26; to &, #27; to ', and #2f; to / respectively
	4. For each byte, if the byte is not in the set -A-Za-z0-9!$*.?_~+=		4. For each byte, if the byte is not in the set A-Za-z0-9!$*.?_~+=
	then change to %hexhex as described in Section 2.2.5 of		then change to %hexhex as described in Section 2.2.5 of
	[URL-GUIDE]		[URL-GUIDE]
	5. Combine resulting local-part with mapped hostname to form		5. Combine resulting local-part with mapped hostname to form
	local@domain address		local@domain address
	6. Prepend with 'im:' scheme (for XMPP <message/> stanzas) or		6. Prepend with 'im:' scheme (for XMPP <message/> stanzas) or
	'pres:' scheme (for XMPP <presence/> stanzas)		'pres:' scheme (for XMPP <presence/> stanzas)
	3.3 CPIM to XMPP		3.3 CPIM to XMPP
	The following is a high-level algorithm for mapping an im: or pres:		The following is a high-level algorithm for mapping an im: or pres:
	URI to an XMPP address:		URI to an XMPP address:
	1. Remove URI scheme		1. Remove URI scheme
	2. Split at the first '@' character into local-part and hostname		2. Split at the first '@' character into local-part and hostname
	(mapping the latter is out of scope)		(mapping the latter is out of scope)
	3. Translate %hexhex to equivalent octets as described in Section		3. Translate %hexhex to equivalent octets as described in Section
	2.2.5 of [URL-GUIDE]		2.2.5 of [URL-GUIDE]
	4. Treat result as a UTF-8 string		4. Treat result as a UTF-8 string
	5. Translate & to #26;, ' to #27;, and / to @2f respectively		5. Translate & to #26;, ' to #27;, and / to #2f respectively
	6. Apply Nodeprep profile of [STRINGPREP] (as specified in		6. Apply Nodeprep profile of [STRINGPREP] (as specified in
	[XMPP-CORE]) for canonicalization (OPTIONAL)		[XMPP-CORE]) for canonicalization (OPTIONAL)
	7. Recombine local-part with mapped hostname to form local@domain		7. Recombine local-part with mapped hostname to form local@domain
	address		address
	4. Syntax Mapping of Instant Messages		4. Syntax Mapping of Instant Messages
	This section describes how a gateway SHOULD map instant messages		This section describes how a gateway SHOULD map instant messages
	between an XMPP service and a non-XMPP service using a "Message/CPIM"		between an XMPP service and a non-XMPP service using a "Message/CPIM"
	object as the bearer of encapsulated text content in order to comply		object as the bearer of encapsulated text content in order to comply
	skipping to change at page 10, line 9 ¶		skipping to change at page 9, line 46 ¶
	4.1.9 Gateway-Generated CPIM Syntax		4.1.9 Gateway-Generated CPIM Syntax
	CPIM specifies the existence of "Message/CPIM" headers in addition to		CPIM specifies the existence of "Message/CPIM" headers in addition to
	those described above, but there is no exact analogue for those		those described above, but there is no exact analogue for those
	headers in the core XMPP specifications. These include:		headers in the core XMPP specifications. These include:
	o cc -- specifies the address of an entity that is to receive a		o cc -- specifies the address of an entity that is to receive a
	"courtesy copy" of the message (i.e., a non-primary addressee)		"courtesy copy" of the message (i.e., a non-primary addressee)
	o DateTime -- specifies the datetime at which the message was sent		o DateTime -- specifies the datetime at which the message was sent
	o NS -- specifies the namespace of a feature extension		o NS -- specifies the namespace of a feature extension
	o Required -- specifies mandatory-to-recognize features		o Require -- specifies mandatory-to-recognize features
	An XMPP-CPIM gateway MAY independently generate such headers based on		An XMPP-CPIM gateway MAY independently generate such headers based on
	its own information (e.g., the datetime at which it received a		its own information (e.g., the datetime at which it received a
	message stanza from an XMPP entity) or based on data encoded in		message stanza from an XMPP entity) or based on data encoded in
	non-core XMPP extensions, but rules for doing so are out of scope for		non-core XMPP extensions, but rules for doing so are out of scope for
	this memo.		this memo.
	4.2 Message Syntax Mapping from CPIM Specifications to XMPP		4.2 Message Syntax Mapping from CPIM Specifications to XMPP
	This section defines the mapping of syntax primitives from "Message/		This section defines the mapping of syntax primitives from "Message/
	skipping to change at page 11, line 20 ¶		skipping to change at page 11, line 10 ¶
	XMPP 'to' attribute		XMPP 'to' attribute
	<message to='juliet@example.com/balcony'>		<message to='juliet@example.com/balcony'>
	...		...
	</message>		</message>
	4.2.3 Courtesy Copy		4.2.3 Courtesy Copy
	The core XMPP specification does not include syntax for specifying a		The core XMPP specification does not include syntax for specifying a
	"courtesy copy" (non-primary addressee) for a message stanza.		"courtesy copy" (non-primary addressee) for a message stanza.
	Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object		Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
	that contains a 'cc' header, it SHOULD NOT pass that information on		that contains a 'cc' header, it SHOULD NOT pass the information
	to the XMPP recipient.		contained in that header on to the XMPP recipient.
	4.2.4 DateTime Header		4.2.4 DateTime Header
	The core XMPP specification does not include syntax for specifying		The core XMPP specification does not include syntax for specifying
	the datetime at which a message stanza was sent. Therefore, if an		the datetime at which a message stanza was sent. Therefore, if an
	XMPP-CPIM gateway receives a "Message/CPIM" object that contains a		XMPP-CPIM gateway receives a "Message/CPIM" object that contains a
	'DateTime' header, it SHOULD NOT pass that information on to the XMPP		'DateTime' header, it SHOULD NOT pass the information contained in
	recipient.		that header on to the XMPP recipient.
	4.2.5 Message Subject		4.2.5 Message Subject
	The 'Subject' header of a "Message/CPIM" object maps to the <subject/		The 'Subject' header of a "Message/CPIM" object maps to the <subject/
	> child element of an XMPP message stanza. To map the CPIM 'Subject'		> child element of an XMPP message stanza. To map the CPIM 'Subject'
	header to the XMPP <subject/> element, the gateway SHOULD simply map		header to the XMPP <subject/> element, the gateway SHOULD simply map
	the value of the 'Subject' header to the XML character data of the		the value of the 'Subject' header to the XML character data of the
	XMPP <subject/> element. The 'Subject' header MAY specify the "lang"		XMPP <subject/> element. The 'Subject' header MAY specify the "lang"
	in which the subject is written. If "lang" information is provided,		in which the subject is written. If "lang" information is provided,
	it MUST be mapped to the 'xml:lang' attribute of the <subject/>		it MUST be mapped to the 'xml:lang' attribute of the <subject/>
	skipping to change at page 12, line 13 ¶		skipping to change at page 12, line 5 ¶
	<subject>Hi!</subject>		<subject>Hi!</subject>
	<subject xml:lang='cz'>Ahoj!</subject>		<subject xml:lang='cz'>Ahoj!</subject>
	4.2.6 Header Extensions		4.2.6 Header Extensions
	"Message/CPIM" objects MAY include an optional 'NS' header to specify		"Message/CPIM" objects MAY include an optional 'NS' header to specify
	the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT		the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
	pass such headers through to the XMPP recipient, and no mapping for		pass such headers through to the XMPP recipient, and no mapping for
	such headers is defined.		such headers is defined.
	4.2.7 Required Headers		4.2.7 Require Header
	"Message/CPIM" objects MAY include an optional 'Required' header to		"Message/CPIM" objects MAY include an optional 'Require' header to
	specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST		specify mandatory-to-recognize features. In general, such a header
	NOT pass such headers through to the XMPP recipient, and no mapping		would be included by the non-XMPP sending application to (1) insist
	for such headers is defined.		that the receiving application needs to understand functionality
			specified by a particular header or (2) indicate that some non-header
			semantics need to be implemented by the receiving application in
			order to understand the contents of the message (e.g.,
			"Locale.MustRenderKanji"). Because the mandatory-to-recognize
			features would be required of the XMPP receiving application rather
			than the XMPP-CPIM gateway itself, the gateway cannot properly handle
			the 'Require' header without detailed knowledge about the
			capabilities of the XMPP receiving application. Therefore, it seems
			appropriate that the XMPP-CPIM gateway SHOULD return a warning or
			error to the non-XMPP sending application if it includes one or more
			'Require' headers in a "Message/CPIM" object; the exact nature of the
			warning or error will depend on the nature of the non-XMPP technology
			used by the foreign system, and is not defined herein. Furthermore,
			any mapping of the 'Require' header into XMPP or an XMPP extension is
			left up to the implementation or to a future specification.
	4.2.8 MIME Content-ID		4.2.8 MIME Content-ID
	XMPP does not include an element or attribute that captures a		XMPP does not include an element or attribute that captures a
	globally unique ID as is defined for the Content-ID MIME header as		globally unique ID as is defined for the Content-ID MIME header as
	specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object		specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object
	that includes a Content-ID, it MAY provide the Content-ID as the		that includes a Content-ID, it MAY provide the Content-ID as the
	value of the message stanza's 'id' attribute, but this is OPTIONAL.		value of the message stanza's 'id' attribute, but this is OPTIONAL.
	Example: Content-ID for Encapsulated Object		Example: Content-ID for Encapsulated Object
	skipping to change at page 13, line 25 ¶		skipping to change at page 13, line 25 ¶
	<body>Wherefore art thou?</body>		<body>Wherefore art thou?</body>
	</message>		</message>
	If the Content-Type is not "text/plain", the XMPP-CPIM gateway MAY		If the Content-Type is not "text/plain", the XMPP-CPIM gateway MAY
	map the content to an XMPP extension but MUST NOT map it to the		map the content to an XMPP extension but MUST NOT map it to the
	<body/> child of the XMPP message stanza, which is allowed to contain		<body/> child of the XMPP message stanza, which is allowed to contain
	XML character data only. The only exception to this rule is a		XML character data only. The only exception to this rule is a
	multi-part MIME object of the kind specified in [XMPP-E2E], which is		multi-part MIME object of the kind specified in [XMPP-E2E], which is
	to be mapped as described in that memo.		to be mapped as described in that memo.
	If the charset is "US-ASCII" or "UTF-8", the gateway SHOULD map the		If the charset is "US-ASCII" or "UTF-8", the gateway MUST map the
	"Message/CPIM" object; otherwise it SHOULD NOT.		"Message/CPIM" object; otherwise it SHOULD NOT.
	4.2.10 Gateway-Generated XMPP Syntax		4.2.10 Gateway-Generated XMPP Syntax
	XMPP specifies the existence of a 'type' attribute for XMPP message		XMPP specifies the existence of a 'type' attribute for XMPP message
	stanzas, which enables the sender to define the conversational		stanzas, which enables the sender to define the conversational
	context of the message. There is no exact analogue for this		context of the message. There is no exact analogue for this
	attribute in CPIM. An XMPP-CPIM gateway MAY independently generate		attribute in CPIM. An XMPP-CPIM gateway MAY independently generate
	the 'type' attribute based on its own information, but this is		the 'type' attribute based on its own information, but this is
	OPTIONAL and rules for doing so are out of scope for this memo.		OPTIONAL and rules for doing so are out of scope for this memo.
	skipping to change at page 19, line 49 ¶		skipping to change at page 19, line 49 ¶
	headers in the core XMPP specifications. These include:		headers in the core XMPP specifications. These include:
	o cc -- specifies the address of an entity that is to receive a		o cc -- specifies the address of an entity that is to receive a
	"courtesy copy" of the presence information (i.e., a non-primary		"courtesy copy" of the presence information (i.e., a non-primary
	addressee)		addressee)
	o DateTime -- specifies the datetime at which the presence		o DateTime -- specifies the datetime at which the presence
	information was sent		information was sent
	o NS -- specifies the namespace of a feature extension		o NS -- specifies the namespace of a feature extension
	o Subject -- specifies the subject or topic of the encapsulated		o Subject -- specifies the subject or topic of the encapsulated
	"Message/CPIM" object		"Message/CPIM" object
	o Required -- specifies mandatory-to-recognize features		o Require -- specifies mandatory-to-recognize features
	An XMPP-CPIM gateway MAY independently generate such headers based on		An XMPP-CPIM gateway MAY independently generate such headers based on
	its own information (e.g., the datetime at which it received a		its own information (e.g., the datetime at which it received a
	presence stanza from an XMPP entity) or based on data encoded in		presence stanza from an XMPP entity) or based on data encoded in
	non-core XMPP extensions, but rules for doing so are out of scope for		non-core XMPP extensions, but rules for doing so are out of scope for
	this memo.		this memo.
	5.1.9.2 PIDF Elements		5.1.9.2 PIDF Elements
	PIDF specifies the existence of XML elements in addition to those		PIDF specifies the existence of XML elements in addition to those
	skipping to change at page 20, line 40 ¶		skipping to change at page 20, line 40 ¶
	CPIM" objects with encapsulated "application/pidf+xml" objects to		CPIM" objects with encapsulated "application/pidf+xml" objects to
	XMPP presence stanzas.		XMPP presence stanzas.
	Note: An XMPP-CPIM gateway MUST NOT map to an XMPP presence stanza a		Note: An XMPP-CPIM gateway MUST NOT map to an XMPP presence stanza a
	"Message/CPIM" object whose encapsulated MIME object has a		"Message/CPIM" object whose encapsulated MIME object has a
	Content-type other than "application/pidf+xml" (with the exception of		Content-type other than "application/pidf+xml" (with the exception of
	multi-part MIME objects as specified in [XMPP-E2E]).		multi-part MIME objects as specified in [XMPP-E2E]).
	5.2.1 From Address		5.2.1 From Address
	The 'From' header of a "Message/CPIM" object maps to the 'from'		The 'From' header of a "Message/CPIM" object maps to the <user@host>
	attribute of an XMPP presence stanza. To map the CPIM 'From' header		portion of the 'from' attribute of an XMPP presence stanza, and the
	to the XMPP 'from' attribute, the gateway MUST remove the "im:"		'id' attribute of the PIDF <tuple/> child element maps to the
	Instant Messaging URI scheme from the front of the address and MUST		resource identifier portion XMPP 'from' attribute. Therefore, to map
	remove the CPIM "Formal-name" (if provided).		the CPIM and PIDF information to the XMPP 'from' attribute, the
			gateway MUST remove the "im:" Instant Messaging URI scheme from the
			front of the address and MUST remove the CPIM "Formal-name" (if
			provided) in order to generate the <user@host> portion of the XMPP
			'from' attribute, then add a '/' character followed by the value of
			the PIDF <tuple/> element's 'id' attribute.
	Example: From Address Mapping		Example: From Address Mapping
	CPIM 'From' header		CPIM 'From' header
	From: Romeo Montague <im:romeo@example.net>		From: Romeo Montague <im:romeo@example.net>
	XMPP 'from' attribute		XMPP 'from' attribute
	<presence from='romeo@example.net'>		<presence from='romeo@example.net'>
	...		...
	</presence>		</presence>
			.
			Example: Resource Identifier Mapping
			XMPP 'from' attribute
			<presence from='juliet@example.com/balcony'>
			...
			</presence>
			PIDF 'id' for <tuple/>
			<presence entity='pres:juliet@example.com'>
			<tuple id='balcony'>
			...
			</tuple>
			</presence>
	5.2.2 To Address		5.2.2 To Address
	The 'To' header of a "Message/CPIM" object maps to the 'to' attribute		The 'To' header of a "Message/CPIM" object maps to the 'to' attribute
	of an XMPP presence stanza. To map the CPIM 'To' header to the XMPP		of an XMPP presence stanza. To map the CPIM 'To' header to the XMPP
	'to' attribute, the gateway MUST remove the "im:" Instant Messaging		'to' attribute, the gateway MUST remove the "im:" Instant Messaging
	URI scheme from the front of the address and MUST remove the CPIM		URI scheme from the front of the address and MUST remove the CPIM
	"Formal-name" (if provided). If the gateway possesses knowledge of		"Formal-name" (if provided). If the gateway possesses knowledge of
	the resource identifier in use by the XMPP entity, the gateway MAY		the resource identifier in use by the XMPP entity, the gateway MAY
	append the resource identifier to the address.		append the resource identifier to the address.
	skipping to change at page 21, line 41 ¶		skipping to change at page 22, line 11 ¶
	<presence to='juliet@example.com/balcony'>		<presence to='juliet@example.com/balcony'>
	...		...
	</presence>		</presence>
	5.2.3 Courtesy Copy		5.2.3 Courtesy Copy
	The core XMPP specification does not include syntax for specifying a		The core XMPP specification does not include syntax for specifying a
	"courtesy copy" (non-primary addressee) for a presence stanza.		"courtesy copy" (non-primary addressee) for a presence stanza.
	Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object		Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
	with encapsulated PIDF object that contains a 'cc' header, it SHOULD		with encapsulated PIDF object that contains a 'cc' header, it SHOULD
	NOT pass that information on to the XMPP recipient.		NOT pass the information contained in that header on to the XMPP
			recipient.
	5.2.4 DateTime Header		5.2.4 DateTime Header
	The core XMPP specification does not include syntax for specifying		The core XMPP specification does not include syntax for specifying
	the datetime at which a presence stanza was sent. Therefore, if an		the datetime at which a presence stanza was sent. Therefore, if an
	XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated		XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
	PIDF object that contains a 'DateTime' header, it SHOULD NOT pass		PIDF object that contains a 'DateTime' header, it SHOULD NOT pass the
	that information on to the XMPP recipient.		information contained in that header on to the XMPP recipient.
	5.2.5 Subject Header		5.2.5 Subject Header
	An XMPP presence stanza contains no information that can be mapped to		An XMPP presence stanza contains no information that can be mapped to
	the 'Subject' header of a "Message/CPIM" object. Therefore, if an		the 'Subject' header of a "Message/CPIM" object. Therefore, if an
	XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated		XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
	PIDF object that contains a 'Subject' header, it SHOULD NOT pass that		PIDF object that contains a 'Subject' header, it SHOULD NOT pass the
	information on to the XMPP recipient.		information contained in that header on to the XMPP recipient.
	5.2.6 Header Extensions		5.2.6 Header Extensions
	"Message/CPIM" objects MAY include an optional 'NS' header to specify		"Message/CPIM" objects MAY include an optional 'NS' header to specify
	the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT		the namespace of a feature extension. An XMPP-CPIM gateway MUST NOT
	pass such headers through to the XMPP recipient, and no mapping for		pass such headers through to the XMPP recipient, and no mapping for
	such headers is defined.		such headers is defined.
	5.2.7 Required Headers		5.2.7 Require Header
	"Message/CPIM" objects MAY include an optional 'Required' header to		"Message/CPIM" objects MAY include an optional 'Require' header to
	specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST		specify mandatory-to-recognize features. An XMPP-CPIM gateway MUST
	NOT pass such headers through to the XMPP recipient, and no mapping		NOT pass such headers through to the XMPP recipient, and no mapping
	for such headers is defined.		for such headers is defined.
	5.2.8 MIME Content-ID		5.2.8 MIME Content-ID
	XMPP does not include an element or attribute that captures a		XMPP does not include an element or attribute that captures a
	globally unique ID as is defined for the Content-ID MIME header as		globally unique ID as is defined for the Content-ID MIME header as
	specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object		specified in [MIME]. If an XMPP-CPIM gateway receives a MIME object
	that includes a Content-ID, it MAY provide the Content-ID as the		that includes a Content-ID, it MAY provide the Content-ID as the
	skipping to change at page 23, line 42 ¶		skipping to change at page 24, line 25 ¶
	</tuple>		</tuple>
	</presence>		</presence>
	XMPP unavailable presence		XMPP unavailable presence
	<presence from='romeo@example.net/orchard'		<presence from='romeo@example.net/orchard'
	type='unavailable'/>		type='unavailable'/>
	5.2.10 Extended Status Information		5.2.10 Extended Status Information
	PIDF documents may contain extended <status/> content. As of this		PIDF documents may contain extended <status/> content. As of this
	writing there are no pre-defined extended status states that		writing there are no pre-defined extended status states that can be
	correspond to the defined values of the XMPP <show/> element ('away',		mapped to the defined values of the XMPP <show/> element ('away',
	'chat', 'dnd', and 'xa'); as soon as values are specified for		'chat', 'dnd', and 'xa'). Once PIDF extensions for such extended
	extended status states in the 'urn:ietf:params:xml:ns:pidf:im'		status states are defined within the Internet Standards Process, a
	namespace, the PIDF values will be mapped to the relevant XMPP		gateway SHOULD map those extensions; however, any such mapping is out
	values.		of scope for this memo, since the relevant PIDF extensions have not
			yet been defined.
	Example: Extended Status Information (provisional)		Example: Extended Status Information (provisional)
	PIDF extended presence information		PIDF extended presence information
	<?xml version='1.0' encoding='UTF-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<presence xmlns='urn:ietf:params:xml:ns:pidf'		<presence xmlns='urn:ietf:params:xml:ns:pidf'
	xmlns:im='urn:ietf:params:xml:ns:pidf:im'		xmlns:im='urn:ietf:params:xml:ns:pidf:im'
	entity='pres:romeo@example.net'>		entity='pres:romeo@example.net'>
	<tuple id='orchard'>		<tuple id='orchard'>
	<status>		<status>
	skipping to change at page 26, line 19 ¶		skipping to change at page 26, line 45 ¶
	0.992 and 0.999 to XMPP priority 126; note that this is an example		0.992 and 0.999 to XMPP priority 126; note that this is an example
	only, and that the exact mapping shall be determined by the XMPP-CPIM		only, and that the exact mapping shall be determined by the XMPP-CPIM
	gateway).		gateway).
	5.2.14 Timestamp Element		5.2.14 Timestamp Element
	The core XMPP specification does not include syntax for specifying		The core XMPP specification does not include syntax for specifying
	the datetime or timestamp at which a presence stanza was sent.		the datetime or timestamp at which a presence stanza was sent.
	Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object		Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
	with encapsulated PIDF object that contains a <timestamp/> element,		with encapsulated PIDF object that contains a <timestamp/> element,
	it SHOULD NOT pass that information on to the XMPP recipient.		it SHOULD NOT pass the XML character data of the <timestamp/> element
			on to the XMPP recipient.
	5.2.15 Inclusion of Complete PIDF Document		5.2.15 Inclusion of Complete PIDF Document
	Certain PIDF elements do not map to XMPP presence stanza syntax		Certain PIDF elements do not map to XMPP presence stanza syntax
	(e.g., the XML character data of the <contact/> element). However,		(e.g., the XML character data of the <contact/> element). However,
	an XMPP client may be able to handle such information by parsing a		an XMPP client may be able to handle such information by parsing a
	native PIDF document. To make this possible, an XMPP-CPIM gateway		native PIDF document. To make this possible, an XMPP-CPIM gateway
	MAY include the complete PIDF document as a child element of the		MAY include the complete PIDF document as a child element of the
	presence stanza, as described in [XMPP-PIDF]. If an XMPP client does		presence stanza, as described in [XMPP-PIDF]. If an XMPP client does
	not understand this extended data, it naturally MUST ignore it.		not understand this extended data, it naturally MUST ignore it.
	skipping to change at page 27, line 46 ¶		skipping to change at page 28, line 25 ¶
	presentity; if this exception occurs, the XMPP-CPIM gateway MUST		presentity; if this exception occurs, the XMPP-CPIM gateway MUST
	return an <item-not-found/> stanza error to the XMPP entity.		return an <item-not-found/> stanza error to the XMPP entity.
	o Access control rules do not permit the entity to subscribe to the		o Access control rules do not permit the entity to subscribe to the
	target; if this exception occurs, the XMPP-CPIM gateway MUST		target; if this exception occurs, the XMPP-CPIM gateway MUST
	return a <forbidden/> stanza error to the XMPP entity.		return a <forbidden/> stanza error to the XMPP entity.
	o There exists a pre-existing subscription or in-progress subscribe		o There exists a pre-existing subscription or in-progress subscribe
	operation between the XMPP entity and the target presentity; if		operation between the XMPP entity and the target presentity; if
	this exception occurs, the XMPP-CPIM gateway SHOULD return a		this exception occurs, the XMPP-CPIM gateway SHOULD return a
	<conflict/> stanza error to the XMPP entity.		<conflict/> stanza error to the XMPP entity.
			XMPP services assume that a subscription is active until it is
			explicitly terminated. However, non-XMPP services may implement
			subscriptions of limited duration, which must be periodically
			refreshed in order to mimic the permanence of XMPP subscriptions.
			Therefore, an XMPP-to-CPIM gateway may need to send such refreshes to
			the non-XMPP entity on behalf of the XMPP entity to that the
			subscription does not expire. Whether such refreshes are necessary
			depends on the native protocol implemented by the CPIM-aware non-XMPP
			service to which the gateway is translating.
	6.2 Receiving a Subscription Request		6.2 Receiving a Subscription Request
	If a non-XMPP presentity wants to subscribe to the presence		If a non-XMPP presentity wants to subscribe to the presence
	information of an XMPP entity through an XMPP-CPIM gateway, it MUST		information of an XMPP entity through an XMPP-CPIM gateway, it MUST
	use whatever protocol it uses to interact with the gateway in order		use whatever protocol it uses to interact with the gateway in order
	to request the subscription; subject to local access rules, the		to request the subscription; subject to local access rules, the
	gateway MUST then send a presence stanza of type "subscribe" to the		gateway MUST then send a presence stanza of type "subscribe" to the
	XMPP entity from the non-XMPP watcher. The syntax mapping is as		XMPP entity from the non-XMPP watcher. The syntax mapping is as
	follows:		follows:
	skipping to change at page 32, line 48 ¶		skipping to change at page 33, line 38 ¶
	[URL-GUIDE]		[URL-GUIDE]
	Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,		Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
	"Guidelines for new URL Schemes", RFC 2718, November 1999.		"Guidelines for new URL Schemes", RFC 2718, November 1999.
	[US-ASCII]		[US-ASCII]
	Cerf, V., "ASCII format for network interchange", RFC 20,		Cerf, V., "ASCII format for network interchange", RFC 20,
	October 1969.		October 1969.
	[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO		[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", RFC 2279, January 1998.		10646", STD 63, RFC 3629, November 2003.
	[XMPP-CORE]		[XMPP-CORE]
	Saint-Andre (ed.), P., "Extensible Messaging and Presence		Saint-Andre (ed.), P., "Extensible Messaging and Presence
	Protocol (XMPP): Core", draft-ietf-xmpp-core-22 (work in		Protocol (XMPP): Core", draft-ietf-xmpp-core-23 (work in
	progress), January 2004.		progress), April 2004.
	[XMPP-E2E]		[XMPP-E2E]
	Saint-Andre (ed.), P., "End-to-End Object Encryption in		Saint-Andre (ed.), P., "End-to-End Object Encryption in
	the Extensible Messaging and Presence Protocol (XMPP)",		the Extensible Messaging and Presence Protocol (XMPP)",
	draft-ietf-xmpp-e2e-07 (work in progress), December 2003.		draft-ietf-xmpp-e2e-07 (work in progress), December 2003.
	[XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and Presence		[XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and Presence
	Protocol (XMPP): Instant Messaging and Presence",		Protocol (XMPP): Instant Messaging and Presence",
	draft-ietf-xmpp-im-21 (work in progress), January 2004.		draft-ietf-xmpp-im-22 (work in progress), April 2004.
	Informative References		Informative References
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April		[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
	2001.		2001.
	[MIMETYPES]		[MIMETYPES]
	Freed, N. and N. Borenstein, "Multipurpose Internet Mail		Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
	skipping to change at page 33, line 44 ¶		skipping to change at page 34, line 33 ¶
	Peter Saint-Andre		Peter Saint-Andre
	Jabber Software Foundation		Jabber Software Foundation
	EMail: stpeter@jabber.org		EMail: stpeter@jabber.org
	Appendix A. Revision History		Appendix A. Revision History
	Note to RFC Editor: please remove this entire appendix, and the		Note to RFC Editor: please remove this entire appendix, and the
	corresponding entries in the table of contents, prior to publication.		corresponding entries in the table of contents, prior to publication.
	A.1 Changes from draft-ietf-xmpp-cpim-03		A.1 Changes from draft-ietf-xmpp-cpim-04
			o Addressed feedback from IESG.
			o Removed Discussion Venue section.
			o Corrected @2f to #2f in Section 3.3.
			o In Sections 4.2.3, 4.2.4, 5.2.3, 5.2.4, 5.2.5, and 5.2.14,
			clarified that it is only the information contained in the
			offending header or XML element that should not be passed from
			CPIM to XMPP if there is no mapping, not the entire "Message/CPIM"
			object.
			o Specified that a gateway should return a warning or error to a
			non-XMPP sending application if it receives a "Message/CPIM"
			object with a 'Require:' header detailing mandatory-to-recognize
			features.
			o Changed SHOULD to MUST regarding mapping of US-ASCII and UTF-8
			"Message/CPIM" objects in Section 4.2.9.
			o In Section 5.1.5, larified that work on PIDF extended status
			states (e.g., "away" and "dnd") is ongoing (not qualified by the
			'urn:ietf:params:xml:ns:pidf:im' namespace) and that gateways
			should support those extensions once they are defined.
			o Specified mapping of tuple IDs to resource identifiers in Section
			5.2.1.
			o Added text to Section 6.1 regarding the possibility that a gateway
			may need to refresh subscription states with the non-XMPP service,
			depending on what protocol that service implements.
			o Changed RFC 2279 reference to RFC 3629.
			A.2 Changes from draft-ietf-xmpp-cpim-03
	o Addressed feedback from WG Chairs.		o Addressed feedback from WG Chairs.
	A.2 Changes from draft-ietf-xmpp-cpim-02		A.3 Changes from draft-ietf-xmpp-cpim-02
	o Removed references to UTF-16.		o Removed references to UTF-16.
	o Changed MUST NOT to SHOULD NOT for mapping of courtesy copy data.		o Changed MUST NOT to SHOULD NOT for mapping of courtesy copy data.
	o Added information about internationalization of addresses.		o Added information about internationalization of addresses.
	o Completed formatting changes to meet RFC Editor requirements.		o Completed formatting changes to meet RFC Editor requirements.
	A.3 Changes from draft-ietf-xmpp-cpim-01		A.4 Changes from draft-ietf-xmpp-cpim-01
	o Added subsection about handling presence notifications for		o Added subsection about handling presence notifications for
	multiple XMPP resources and multiple PIDF tuples.		multiple XMPP resources and multiple PIDF tuples.
	o Added subsection about PIDF documents that contain zero tuples.		o Added subsection about PIDF documents that contain zero tuples.
	o Further specified mapping between XMPP addresses and CPIM instant		o Further specified mapping between XMPP addresses and CPIM instant
	inboxes and presentities.		inboxes and presentities.
	A.4 Changes from draft-ietf-xmpp-cpim-00		A.5 Changes from draft-ietf-xmpp-cpim-00
	o Updated references.		o Updated references.
	o Made several small editorial changes.		o Made several small editorial changes.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
End of changes. 32 change blocks.
	62 lines changed or deleted		131 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/