draft-ietf-xmpp-cpim-03.txt   draft-ietf-xmpp-cpim-04.txt 
XMPP Working Group P. Saint-Andre XMPP Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation Internet-Draft Jabber Software Foundation
Expires: May 20, 2004 November 20, 2003 Expires: September 6, 2004 March 8, 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-03 draft-ietf-xmpp-cpim-04
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 May 20, 2004. This Internet-Draft will expire on September 6, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). 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 of the Extensible Messaging and
Presence Protocol (XMPP) to the Common Presence and Instant Messaging Presence Protocol (XMPP) to the Common Presence and Instant Messaging
(CPIM) specifications. (CPIM) specifications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Mapping of Instant Messages . . . . . . . . . . . . . . . . . 5 3. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 5
4. Mapping of Presence . . . . . . . . . . . . . . . . . . . . . 13 4. Syntax Mapping of Instant Messages . . . . . . . . . . . . . . 6
5. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . . . 26 5. Syntax Mapping of Presence Information . . . . . . . . . . . . 13
6. Internationalization Considerations . . . . . . . . . . . . . 31 6. XMPP-CPIM Gateway as Presence Service . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
Normative References . . . . . . . . . . . . . . . . . . . . . 32 Normative References . . . . . . . . . . . . . . . . . . . . . 31
Informative References . . . . . . . . . . . . . . . . . . . . 33 Informative References . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33
A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 34 A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . 35
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
for Instant Messaging [CPIM] (also called CPIM), a Common Profile for for Instant Messaging [CPIM] (also called CPIM), a Common Profile for
Presence [CPP], a CPIM Message Format [MSGFMT], and a Common Presence Presence [CPP], a CPIM Message Format [MSGFMT], and a Common Presence
Information Data Format [PIDF]. (Note: To prevent confusion, Common Information Data Format [PIDF]. (Note: To prevent confusion, Common
Presence and Instant Messaging is referred to herein collectively as Presence and Instant Messaging is referred to herein collectively as
"the CPIM specifications", whereas the Common Profile for Instant "the CPIM specifications", whereas the Common Profile for Instant
Messaging is referred to as "CPIM". In order to refer to a gateway Messaging is referred to as "CPIM".)
between an Extensible Messaging and Presence Protocol (XMPP) service
and a non-XMPP service where the common format is defined by the CPIM
specifications, the term "XMPP-CPIM Gateway" is used herein.)
This memo describes how the Extensible Messaging and Presence This memo describes how the Extensible Messaging and Presence
Protocol ([XMPP-CORE], [XMPP-IM]) maps to the abstract model Protocol ([XMPP-CORE], [XMPP-IM]) maps to the abstract model
contained in the CPIM specifications, mainly for the purpose of contained in the CPIM specifications, mainly for the purpose of
establishing gateways between XMPP services and non-XMPP services establishing gateways between XMPP services and non-XMPP services
that conform to [IMP-REQS]. Such gateways may be established to that conform to [IMP-REQS]. Such a gateway, referred to herein as an
interpret the protocols of one service and translate them into the "XMPP-CPIM gateway", may be established to interpret the protocols of
protocols of the other service. We can visualize this relationship one service and translate them into the protocols of the other
as follows: service. We can visualize this relationship as follows:
+-------------+ +-------------+ +------------+ +-------------+ +-------------+ +------------+
| | | | | | | | | | | |
| XMPP | | XMPP-CPIM | | Non-XMPP | | XMPP | | XMPP-CPIM | | Non-XMPP |
| Service | <----> | Gateway | <----> | Service | | Service | <----> | Gateway | <----> | Service |
| | | | | | | | | | | |
+-------------+ +-------------+ +------------+ +-------------+ +-------------+ +------------+
This memo defines a mapping for use by a gateway that translates This memo defines a mapping for use by a gateway that translates
between XMPP and a non-XMPP protocol via the CPIM specifications. between XMPP and a non-XMPP protocol via the CPIM specifications.
skipping to change at page 4, line 26 skipping to change at page 4, line 26
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 1.4 Discussion Venue
The authors welcome discussion and comments related to the topics The author welcomes discussion and comments related to the topics
presented in this document. The preferred forum is the presented in this document. The preferred forum is the
<xmppwg@jabber.org> mailing list, for which archives and subscription <xmppwg@jabber.org> mailing list, for which archives and subscription
information are available at <http://www.jabber.org/cgi-bin/mailman/ information are available at <<http://www.jabber.org/cgi-bin/mailman/
listinfo/xmppwg/>. listinfo/xmppwg/>>.
1.5 Intellectual Property Notice
This document is in full compliance with all provisions of Section 10
of RFC 2026. Parts of this specification use the term "jabber" for
identifying namespaces and other protocol syntax. Jabber[tm] is a
registered trademark of Jabber, Inc. Jabber, Inc. grants permission
to the IETF for use of the Jabber trademark in association with this
specification and its successors, if any.
1.6 Contributors
Tony Bamonti contributed to the first version of this memo.
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
skipping to change at page 5, line 28 skipping to change at page 5, line 15
arbitrary MIME media types [MIMETYPES]. By contrast, each arbitrary MIME media types [MIMETYPES]. By contrast, each
"application/pidf+xml" object is a complete XML document whose "application/pidf+xml" object is a complete XML document whose
structure is defined by an XML schema. structure is defined by an XML schema.
The approach taken herein is to specify mappings from XMPP elements The approach taken herein is to specify mappings from XMPP elements
and attributes to the headers and MIME formats defined by [MSGFMT] and attributes to the headers and MIME formats defined by [MSGFMT]
and [PIDF] in order to comply with the semantics defined by [CPIM] and [PIDF] in order to comply with the semantics defined by [CPIM]
and [CPP]. Naturally, mappings in the opposite direction are and [CPP]. Naturally, mappings in the opposite direction are
provided as well. provided as well.
3. Mapping of Instant Messages 3. Address Mapping
3.1 Overview
Address mapping may be required since the address formats used to
identify XMPP entities (specified in [XMPP-CORE]) are different from
those used to identify instant inboxes (the im: URI scheme specified
in [CPIM]) and presentitites (the pres: URI scheme specified in
[CPP]). In particular, different characters are allowed in im: and
pres: URIs than are allowed in XMPP addresses:
o The following [US-ASCII] characters are allowed in im:/pres: URIs
but not in XMPP addresses: #26; (&), #27; ('), and #2f; (/).
o Many non-US-ASCII (specifically, UTF-8) characters are allowed in
XMPP addresses but not allowed in im:/pres: URIs, since XMPP
allows internationalized local-part addresses.
Note: In this document we discuss characters allowed in local-part
addresses only (i.e., we have ruled the mapping of domain names as
out of scope for the initial version of this document, since it is a
matter for the Domain Name System and the translation of fully
internationalized domain names).
3.2 XMPP to CPIM
The following is a high-level algorithm for mapping an XMPP address
to an im: or pres: URI:
1. Split XMPP address into node identifier (local-part; mapping
described in remaining steps), domain identifier (hostname;
mapping is out of scope), and resource identifier (specifier for
particular device or connection; discard this for cross-system
interoperability)
2. Apply Nodeprep profile of [STRINGPREP] (as specified in
[XMPP-CORE]) for canonicalization (OPTIONAL)
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!$*.?_~+=
then change to %hexhex as described in Section 2.2.5 of
[URL-GUIDE]
5. Combine resulting local-part with mapped hostname to form
local@domain address
6. Prepend with 'im:' scheme (for XMPP <message/> stanzas) or
'pres:' scheme (for XMPP <presence/> stanzas)
3.3 CPIM to XMPP
The following is a high-level algorithm for mapping an im: or pres:
URI to an XMPP address:
1. Remove URI scheme
2. Split at the first '@' character into local-part and hostname
(mapping the latter is out of scope)
3. Translate %hexhex to equivalent octets as described in Section
2.2.5 of [URL-GUIDE]
4. Treat result as a UTF-8 string
5. Translate & to #26;, ' to #27;, and / to @2f respectively
6. Apply Nodeprep profile of [STRINGPREP] (as specified in
[XMPP-CORE]) for canonicalization (OPTIONAL)
7. Recombine local-part with mapped hostname to form local@domain
address
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
with the instant messaging semantics defined by [CPIM]. with the instant messaging semantics defined by [CPIM].
3.1 Identification of Instant Inboxes 4.1 Message Syntax Mapping from XMPP to CPIM Specifications
There is a one-to-one relationship between an XMPP entity and a CPIM
instant inbox when the address of the XMPP entity contains only a
node identifier and domain identifier, and the node identifier
uniquely corresponds to an IM user who possesses an account on an
XMPP server. However, the syntax for addressing an instant inbox is
specified as including the 'im:' URI scheme as defined in [CPIM],
whereas an XMPP address does not include that scheme, so any mapping
between an instant inbox address and an XMPP address must add or
remove the 'im:' URI scheme as appropriate.
3.2 Message Syntax Mapping from XMPP to CPIM Specifications
This section defines the mapping of syntax primitives from XMPP This section defines the mapping of syntax primitives from XMPP
message stanzas to "Message/CPIM" objects with encapsulated text message stanzas to "Message/CPIM" objects with encapsulated text
content. content.
3.2.1 From Address Note: As specified in [MIME], the default Content-type of a MIME
object is "Content-type: text/plain; charset=us-ascii". Because XMPP
uses the [UTF-8] character encoding exclusively, the encapsulated
MIME object generated by an XMPP-CPIM gateway MUST set the
'Content-type' header for that object. Specifically, the
"Content-type" MUST be set to "text/plain" and the charset MUST be
set to "utf-8".
4.1.1 From Address
The 'from' attribute of an XMPP message stanza maps to the 'From' The 'from' attribute of an XMPP message stanza maps to the 'From'
header of a "Message/CPIM" object. In XMPP, the sender's server header of a "Message/CPIM" object. In XMPP, the sender's server
stamps or validates the "from" address and sets its value to the full stamps or validates the "from" address and sets its value to the full
<user@host/resource> negotiated between client and server during <user@host/resource> negotiated between client and server during
authentication and resource binding as defined in [XMPP-CORE]. Thus authentication and resource binding as defined in [XMPP-CORE]. Thus
an XMPP-CPIM gateway will receive from the sender's XMPP server a an XMPP-CPIM gateway will receive from the sender's XMPP server a
message stanza containing a "from" address of the form <user@host/ message stanza containing a "from" address of the form <user@host/
resource>. To map the 'from' attribute of an XMPP message stanza to resource>. To map the 'from' attribute of an XMPP message stanza to
the 'From' header of a "Message/CPIM" object, the gateway MUST remove the 'From' header of a "Message/CPIM" object, the gateway MUST remove
skipping to change at page 6, line 30 skipping to change at page 7, line 30
Example: From Address Mapping Example: From Address Mapping
XMPP 'from' attribute XMPP 'from' attribute
<message from='juliet@example.com/balcony'> <message from='juliet@example.com/balcony'>
... ...
</message> </message>
CPIM 'From' header CPIM 'From' header
From: Juliet Capulet <im:juliet@example.com> From: Juliet Capulet <im:juliet@example.com>
3.2.2 To Address 4.1.2 To Address
The 'to' attribute of an XMPP message stanza maps to the 'To' header The 'to' attribute of an XMPP message stanza maps to the 'To' header
of a "Message/CPIM" object. In XMPP, the sender SHOULD include a of a "Message/CPIM" object. In XMPP, the sender SHOULD include a
'to' attribute on a message stanza, and MUST include it if the 'to' attribute on a message stanza, and MUST include it if the
message is intended for delivery to another user. Thus an XMPP-CPIM message is intended for delivery to another user. Thus an XMPP-CPIM
gateway will receive from the sender's XMPP server a message stanza gateway will receive from the sender's XMPP server a message stanza
containing a "to" address of the form <user@host> or <user@host/ containing a "to" address of the form <user@host> or <user@host/
resource>. To map the 'to' attribute of an XMPP message stanza to resource>. To map the 'to' attribute of an XMPP message stanza to
the 'To' header of a "Message/CPIM" object, the gateway MUST remove the 'To' header of a "Message/CPIM" object, the gateway MUST remove
the resource identifier (if included), MUST append the "im:" Instant the resource identifier (if included), MUST append the "im:" Instant
skipping to change at page 7, line 6 skipping to change at page 8, line 6
Example: To Address Mapping Example: To Address Mapping
XMPP 'to' attribute XMPP 'to' attribute
<message to='romeo@example.net/orchard'> <message to='romeo@example.net/orchard'>
... ...
</message> </message>
CPIM 'To' header CPIM 'To' header
To: Romeo Montague <im:romeo@example.net> To: Romeo Montague <im:romeo@example.net>
3.2.3 CPIM Courtesy Copy 4.1.3 Stanza ID
The core XMPP specification does not include syntax for specifying a
"courtesy copy" (non-primary addressee) for a message stanza.
Therefore, an XMPP-CPIM gateway SHOULD NOT generate the 'cc' header
of a "Message/CPIM" object.
3.2.4 XMPP Stanza ID
An XMPP message stanza MAY possess an 'id' attribute, which is used An XMPP message stanza MAY possess an 'id' attribute, which is used
by the sending application for the purpose of tracking stanzas. by the sending application for the purpose of tracking stanzas and is
There is no mapping of an XMPP 'id' attribute to a "Message/CPIM" not a globally-unique identifier such as is defined by the MIME
header, common MIME features, or encapsulated text content. Content-ID header. Because the XMPP 'id' attribute does not have the
Therefore if an XMPP stanza received by an XMPP-CPIM gateway same meaning as the MIME Content-ID header, it SHOULD NOT be mapped
possesses an 'id' attribute, the gateway SHOULD ignore the value to that header; however, if the 'id' is known to be unique (e.g., if
provided. it is generated to be unique by the XMPP server and that fact is
known by the XMPP-CPIM gateway), then it SHOULD be so mapped.
3.2.5 XMPP Message Type 4.1.4 Message Type
An XMPP message stanza MAY possess a 'type' attribute, which is used An XMPP message stanza MAY possess a 'type' attribute, which is used
by the sending application to capture the conversational context of by the sending application to capture the conversational context of
the message. There is no mapping of an XMPP 'type' attribute to a the message. There is no mapping of an XMPP 'type' attribute to a
"Message/CPIM" header, common MIME features, or encapsulated text "Message/CPIM" header, common MIME features, or encapsulated text
content. Therefore if an XMPP stanza received by an XMPP-CPIM content. Therefore if an XMPP stanza received by an XMPP-CPIM
gateway possesses a 'type' attribute, the gateway SHOULD ignore the gateway possesses a 'type' attribute, the gateway SHOULD ignore the
value provided. value provided.
3.2.6 XMPP Message Thread 4.1.5 Message Thread
An XMPP message stanza MAY contain a <thread/> child element to An XMPP message stanza MAY contain a <thread/> child element to
specify the conversation thread in which the message is situated. specify the conversation thread in which the message is situated.
There is no mapping of an XMPP <thread/> element to a "Message/CPIM" There is no mapping of an XMPP <thread/> element to a "Message/CPIM"
header, common MIME features, or encapsulated text content. header, common MIME features, or encapsulated text content.
Therefore if an XMPP message stanza received by an XMPP-CPIM gateway Therefore if an XMPP message stanza received by an XMPP-CPIM gateway
contains a <thread/> child element, the gateway SHOULD ignore the contains a <thread/> child element, the gateway SHOULD ignore the
value provided. value provided.
3.2.7 CPIM DateTime Header 4.1.6 Message Subject
The core XMPP specification does not include syntax for specifying
the datetime at which a message stanza was sent. However, an
XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
CPIM" object it generates, the value of which SHOULD be the datetime
at which the message stanza was received for processing by the
gateway.
3.2.8 Message Subject
An XMPP message stanza MAY include a <subject/> child element. If An XMPP message stanza MAY include a <subject/> child element. If
included, it maps to the 'Subject' header of a "Message/CPIM" object. included, it maps to the 'Subject' header of a "Message/CPIM" object.
To map the XMPP <subject/> element to the 'Subject' header of a To map the XMPP <subject/> element to the 'Subject' header of a
"Message/CPIM" object, the gateway SHOULD simply map the XML "Message/CPIM" object, the gateway SHOULD simply map the XML
character data of the XMPP <subject/> element to the value of the character data of the XMPP <subject/> element to the value of the
'Subject' header. The <subject/> element MAY include an 'xml:lang' 'Subject' header. The <subject/> element MAY include an 'xml:lang'
attribute specifying the language in which the subject is written. attribute specifying the language in which the subject is written.
If an 'xml:lang' attribute is provided, it MUST be mapped by If an 'xml:lang' attribute is provided, it MUST be mapped by
including ';lang=tag' after the header name and colon, where 'tag' is including ';lang=tag' after the header name and colon, where 'tag' is
skipping to change at page 8, line 28 skipping to change at page 9, line 15
Example: Subject Mapping Example: Subject Mapping
XMPP <subject/> element XMPP <subject/> element
<subject>Hi!</subject> <subject>Hi!</subject>
<subject xml:lang='cz'>Ahoj!</subject> <subject xml:lang='cz'>Ahoj!</subject>
CPIM 'Subject' header CPIM 'Subject' header
Subject: Hi! Subject: Hi!
Subject:;lang=cz Ahoj! Subject:;lang=cz Ahoj!
3.2.9 CPIM Header Extensions 4.1.7 Message Body
A "Message/CPIM" object MAY include an optional 'NS' header to
specify the namespace of a feature extension. An XMPP-CPIM gateway
SHOULD NOT generate such headers.
3.2.10 CPIM Required Headers
A "Message/CPIM" object MAY include an optional 'Required' header to
specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
NOT generate such headers.
3.2.11 MSGFMT MIME Content-type
As specified in [MIME], the default Content-type of a MIME object is
"Content-type: text/plain; charset=us-ascii". Because XMPP uses the
[UTF-8] character encoding exclusively, the encapsulated MIME object
generated by an XMPP-CPIM gateway MUST set the 'Content-type' header
for that object. The "Content-type" MUST be set to "text/plain" and
the charset MUST be set to UTF-8.
Example: Content-type for Encapsulated Object
Content-type: text/plain; charset=utf-8
3.2.12 MSGFMT MIME Content-ID
As specified in [MIME], the Content-ID is OPTIONAL for MIME objects.
While an XMPP-CPIM gateway MAY generate a Content-ID for encapsulated
MIME objects, it is NOT REQUIRED to do so. If included, Content-ID
values MUST be generated to be world-unique.
Example: Content-ID for Encapsulated Object
Content-ID: <123456789@example.net>
3.2.13 Message Body
The <body/> child element of an XMPP message stanza is used to The <body/> child element of an XMPP message stanza is used to
provide the primary meaning of the message. The XML character data provide the primary meaning of the message. The XML character data
of the XMPP <body/> element maps to the encapsulated text message of the XMPP <body/> element maps to the encapsulated text message
content. content.
Example: Message Body Example: Message Body
XMPP message <body/> XMPP message <body/>
<message> <message>
<body>Wherefore art thou, Romeo?</body> <body>Wherefore art thou, Romeo?</body>
</message> </message>
Encapsulated MIME text content Encapsulated MIME text content
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <123456789@example.net> Content-ID: <123456789@example.net>
Wherefore art thou, Romeo? Wherefore art thou, Romeo?
3.2.14 XMPP Message Extensions 4.1.8 Message Extensions
As defined in [XMPP-CORE], an XMPP message stanza may contain As defined in [XMPP-CORE], an XMPP message stanza may contain
"extended" content in any namespace in order to supplement or extend "extended" content in any namespace in order to supplement or extend
the semantics of the core message stanza. With the exception of the semantics of the core message stanza. With the exception of
extended information qualified by the extended information qualified by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E], 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E],
an XMPP-CPIM gateway SHOULD ignore such information and not pass it an XMPP-CPIM gateway SHOULD ignore such information and not pass it
through the gateway to the intended recipient. No mapping for such through the gateway to the intended recipient. No mapping for such
information is defined. information is defined.
3.3 Message Syntax Mapping from CPIM Specifications to XMPP 4.1.9 Gateway-Generated CPIM Syntax
CPIM specifies the existence of "Message/CPIM" headers in addition to
those described above, but there is no exact analogue for those
headers in the core XMPP specifications. These include:
o cc -- specifies the address of an entity that is to receive a
"courtesy copy" of the message (i.e., a non-primary addressee)
o DateTime -- specifies the datetime at which the message was sent
o NS -- specifies the namespace of a feature extension
o Required -- specifies mandatory-to-recognize features
An XMPP-CPIM gateway MAY independently generate such headers based on
its own information (e.g., the datetime at which it received a
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
this memo.
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/
CPIM" objects with encapsualted text content to XMPP message stanzas. CPIM" objects with encapsualted text content to XMPP message stanzas.
3.3.1 From Address 4.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 'from'
attribute of an XMPP message stanza. To map the CPIM 'From' header attribute of an XMPP message stanza. To map the CPIM 'From' header
to the XMPP 'from' attribute, the gateway MUST remove the "im:" to the XMPP 'from' attribute, the gateway MUST remove the "im:"
Instant Messaging URI scheme from the front of the address and MUST Instant Messaging URI scheme from the front of the address and MUST
remove the CPIM "Formal-name" (if provided). remove the CPIM "Formal-name" (if provided).
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
<message from='romeo@example.net'> <message from='romeo@example.net'>
... ...
</message> </message>
3.3.2 To Address 4.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 message stanza. To map the CPIM 'To' header to the XMPP of an XMPP message 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.
Example: To Address Mapping Example: To Address Mapping
CPIM 'To' header CPIM 'To' header
To: Juliet Capulet <im:juliet@example.com> To: Juliet Capulet <im:juliet@example.com>
XMPP 'to' attribute XMPP 'to' attribute
<message to='juliet@example.com/balcony'> <message to='juliet@example.com/balcony'>
... ...
</message> </message>
3.3.3 CPIM 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 that information on
to the XMPP recipient. to the XMPP recipient.
3.3.4 XMPP Message Type 4.2.4 DateTime Header
MSGFMT does not possess the concept of a message type that can map to
the XMPP 'type' attribute for message stanzas. Therefore an
XMPP-CPIM gateway SHOULD NOT include the 'type' attribute on the
messages it sends to XMPP recipients.
3.3.5 CPIM 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 that information on to the XMPP
recipient. recipient.
3.3.6 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/>
element, where the value of the 'xml:lang' attribute is the the "tag" element, where the value of the 'xml:lang' attribute is the the "tag"
value supplied in the string ';lang=tag' included CPIM 'Subject' value supplied in the string ';lang=tag' included CPIM 'Subject'
skipping to change at page 11, line 43 skipping to change at page 12, line 6
Example: Subject Mapping Example: Subject Mapping
CPIM 'Subject' header CPIM 'Subject' header
Subject: Hi! Subject: Hi!
Subject:;lang=cz Ahoj! Subject:;lang=cz Ahoj!
XMPP <subject/> element XMPP <subject/> element
<subject>Hi!</subject> <subject>Hi!</subject>
<subject xml:lang='cz'>Ahoj!</subject> <subject xml:lang='cz'>Ahoj!</subject>
3.3.7 CPIM 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.
3.3.8 CPIM Required Headers 4.2.7 Required Headers
"Message/CPIM" objects MAY include an optional 'Required' header to "Message/CPIM" objects MAY include an optional 'Required' 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.
3.3.9 MSGFMT MIME Content-type 4.2.8 MIME Content-ID
As specified in [MSGFMT], a "Message/CPIM" object MAY contain any
arbitrary MIME content. However, support for arbitrary content types
is not a requirement in XMPP; in particular, the <body/> child
element of an XMPP message stanza MUST contain XML character data
only. Therefore, an XMPP-CPIM gateway MUST NOT map to an XMPP
message stanza a "Message/CPIM" object whose encapsulated MIME object
has a Content-type other than "text/plain" (with the exception of
multi-part MIME objects as specified in [XMPP-E2E]).
3.3.10 MSGFMT 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 is NOT REQUIRED to value of the message stanza's 'id' attribute, but this is OPTIONAL.
do so.
Example: Content-ID for Encapsulated Object Example: Content-ID for Encapsulated Object
MIME header MIME header
Content-ID: <123456789@example.net> Content-ID: <123456789@example.net>
XMPP 'id' attribute (OPTIONAL) XMPP 'id' attribute (OPTIONAL)
<message id='123456789@example.net'> <message id='123456789@example.net'>
... ...
</message> </message>
3.3.11 Message Body 4.2.9 Message Body
If the Content-type of an encapsulated MIME object is "text/plain", If the Content-type of an encapsulated MIME object is "text/plain",
then the encapsulated text message content maps to the XML character then the encapsulated text message content maps to the XML character
data of the <body/> child element of an XMPP message stanza. data of the <body/> child element of an XMPP message stanza.
Example: Message Body Example: Message Body
Encapsulated MIME text content Encapsulated MIME text content
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <123456789@example.net> Content-ID: <123456789@example.net>
skipping to change at page 13, line 4 skipping to change at page 13, line 10
If the Content-type of an encapsulated MIME object is "text/plain", If the Content-type of an encapsulated MIME object is "text/plain",
then the encapsulated text message content maps to the XML character then the encapsulated text message content maps to the XML character
data of the <body/> child element of an XMPP message stanza. data of the <body/> child element of an XMPP message stanza.
Example: Message Body Example: Message Body
Encapsulated MIME text content Encapsulated MIME text content
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <123456789@example.net> Content-ID: <123456789@example.net>
Wherefore art thou? Wherefore art thou?
XMPP message <body/> XMPP message <body/>
<message id='123456789@example.net'> <message id='123456789@example.net'>
<body>Wherefore art thou?</body> <body>Wherefore art thou?</body>
</message> </message>
4. Mapping of Presence 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
<body/> child of the XMPP message stanza, which is allowed to contain
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
to be mapped as described in that memo.
If the charset is "US-ASCII" or "UTF-8", the gateway SHOULD map the
"Message/CPIM" object; otherwise it SHOULD NOT.
4.2.10 Gateway-Generated XMPP Syntax
XMPP specifies the existence of a 'type' attribute for XMPP message
stanzas, which enables the sender to define the conversational
context of the message. There is no exact analogue for this
attribute in CPIM. An XMPP-CPIM gateway MAY independently generate
the 'type' attribute based on its own information, but this is
OPTIONAL and rules for doing so are out of scope for this memo.
5. Syntax Mapping of Presence Information
This section describes how a gateway SHOULD map presence information This section describes how a gateway SHOULD map presence information
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 an encapsulated [PIDF] object in order to object as the bearer of an encapsulated [PIDF] object in order to
comply with the presence semantics defined by [CPP]. comply with the presence semantics defined by [CPP].
4.1 Identification of Presentities 5.1 Presence Syntax Mapping from XMPP to CPIM Specifications
There is a one-to-one relationship between an XMPP entity and a CPP
presentity when the address of the XMPP entity contains only a node
identifier and domain identifier, and the node identifier uniquely
corresponds to an IM user who possesses an account on an XMPP server.
However, the syntax of presentities is specified as including the
'pres:' URI scheme as defined in [CPP], whereas XMPP addresses do not
include that scheme, so any mapping between presentities and XMPP
addresses must add or remove the 'pres:' URI scheme as appropriate.
4.2 Presence Syntax Mapping from XMPP to CPIM Specifications
This section defines the mapping of syntax primitives from XMPP This section defines the mapping of syntax primitives from XMPP
presence stanzas to "Message/CPIM" objects with encapsulated presence stanzas to "Message/CPIM" objects with encapsulated
"application/pidf+xml" objects. "application/pidf+xml" objects.
4.2.1 From Address Note: As specified in [MIME], the default Content-type of a MIME
object is "Content-type: text/plain; charset=us-ascii". Because XMPP
uses the [UTF-8] character encoding exclusively and because PIDF
specifies the "application/pidf+xml" MIME type, the encapsulated MIME
object generated by an XMPP-CPIM gateway for presence information
MUST set the 'Content-type' header for that object. The
"Content-type" MUST be set to "application/pidf+xml" and the charset
MUST be set to "utf-8".
5.1.1 From Address
The 'from' attribute of an XMPP presence stanza maps to the 'From' The 'from' attribute of an XMPP presence stanza maps to the 'From'
header of a "Message/CPIM" object. In XMPP, the sender's server header of a "Message/CPIM" object. In XMPP, the sender's server
stamps or validates the "from" address and sets its value to the stamps or validates the "from" address and sets its value to the
<user@host/resource> negotiated between client and server during <user@host/resource> negotiated between client and server during
authenticating and resource binding as defined in [XMPP-CORE]. Thus authenticating and resource binding as defined in [XMPP-CORE]. Thus
an XMPP-CPIM gateway will receive from the sender's XMPP server a an XMPP-CPIM gateway will receive from the sender's XMPP server a
presence stanza containing a "from" address of the form <user@host/ presence stanza containing a "from" address of the form <user@host/
resource>. To map the 'from' attribute of an XMPP presence stanza to resource>. To map the 'from' attribute of an XMPP presence stanza to
the 'From' header of a "Message/CPIM" object, the gateway MUST remove the 'From' header of a "Message/CPIM" object, the gateway MUST remove
skipping to change at page 14, line 48 skipping to change at page 15, line 22
... ...
</presence> </presence>
PIDF 'id' for <tuple/> PIDF 'id' for <tuple/>
<presence entity='pres:juliet@example.com'> <presence entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
... ...
</tuple> </tuple>
</presence> </presence>
4.2.2 To Address 5.1.2 To Address
The 'to' attribute of an XMPP presence stanza maps to the 'To' header The 'to' attribute of an XMPP presence stanza maps to the 'To' header
of a "Message/CPIM" object. In XMPP, the sender MAY include a 'to' of a "Message/CPIM" object. In XMPP, the sender MAY include a 'to'
attribute on a presence stanza, and MUST include it if the presence attribute on a presence stanza, and MUST include it if the presence
stanza is intended for delivery directly to another user (presence stanza is intended for delivery directly to another user (presence
stanzas intended for broadcasting are stamped with a 'to' address by stanzas intended for broadcasting are stamped with a 'to' address by
the sender's server). Thus an XMPP-CPIM gateway will receive from the sender's server). Thus an XMPP-CPIM gateway will receive from
the sender's XMPP server a presence stanza containing a "to" address the sender's XMPP server a presence stanza containing a "to" address
of the form <user@host> or <user@host/resource>. To map the 'to' of the form <user@host> or <user@host/resource>. To map the 'to'
attribute of an XMPP presence stanza to the 'To' header of a attribute of an XMPP presence stanza to the 'To' header of a
skipping to change at page 15, line 27 skipping to change at page 16, line 5
Example: To Address Mapping Example: To Address Mapping
XMPP 'to' attribute XMPP 'to' attribute
<presence to='romeo@example.net/orchard'> <presence to='romeo@example.net/orchard'>
... ...
</presence> </presence>
CPIM 'To' header CPIM 'To' header
To: Romeo Montague <im:romeo@example.net> To: Romeo Montague <im:romeo@example.net>
4.2.3 CPIM Courtesy Copy 5.1.3 Stanza ID
The core XMPP specification does not include syntax for specifying a
"courtesy copy" (non-primary addressee) for a presence stanza.
Therefore, an XMPP-CPIM gateway SHOULD NOT generate the 'cc' header
of a "Message/CPIM" object.
4.2.4 XMPP Stanza ID
An XMPP presence stanza MAY possess an 'id' attribute, which is used An XMPP presence stanza MAY possess an 'id' attribute, which is used
by the sending application for the purpose of tracking stanzas. by the sending application for the purpose of tracking stanzas and is
There is no mapping of an XMPP 'id' attribute to a "Message/CPIM" not a globally-unique identifier such as is defined by the MIME
header, common MIME features, or PIDF elements and attributes. Content-ID header. Because the XMPP 'id' attribute does not have the
Therefore if an XMPP stanza received by an XMPP-CPIM gateway same meaning as the MIME Content-ID header, it SHOULD NOT be mapped
possesses an 'id' attribute, the gateway SHOULD ignore the value to that header; however, if the 'id' is known to be unique (e.g., if
provided. it is generated to be unique by the XMPP server and that fact is
known by the XMPP-CPIM gateway), then it SHOULD be so mapped.
4.2.5 CPIM DateTime Header
The core XMPP specification does not include syntax for specifying
the datetime at which a presence stanza was sent. However, an
XMPP-CPIM gateway MAY include a 'DateTime' header in the "Message/
CPIM" object it generates, the value of which SHOULD be the datetime
at which the presence stanza was received for processing by the
gateway.
4.2.6 CPIM Subject Header
An XMPP presence stanza contains no information that can be mapped to
the 'Subject' header of a "Message/CPIM" object. Therefore an
XMPP-CPIM gateway SHOULD NOT generate such headers when mapping XMPP
presence stanzas.
4.2.7 CPIM Header Extensions
A "Message/CPIM" object MAY include an optional 'NS' header to
specify the namespace of a feature extension. An XMPP-CPIM gateway
SHOULD NOT generate such headers.
4.2.8 CPIM Required Headers
A "Message/CPIM" object MAY include an optional 'Required' header to
specify mandatory-to-recognize features. An XMPP-CPIM gateway SHOULD
NOT generate such headers.
4.2.9 PIDF MIME Content-type
As specified in [MIME], the default Content-type of a MIME object is
"Content-type: text/plain; charset=us-ascii". Because XMPP uses the
[UTF-8] character encoding exclusively and because PIDF specifies the
"application/pidf+xml" MIME time, the encapsulated MIME object
generated by an XMPP-CPIM gateway for presence information MUST set
the 'Content-type' header for that object. The "Content-type" MUST
be set to "application/pidf+xml" and the charset MUST be set to
UTF-8.
Example: Content-type for Encapsulated PIDF Object
Content-type: application/pidf+xml; charset=utf-8
4.2.10 PIDF MIME Content-ID
As specified in [MIME], the Content-ID is OPTIONAL for MIME objects.
While an XMPP-CPIM gateway MAY generate a Content-ID for encapsulated
MIME objects, it is NOT REQUIRED to do so. If included, Content-ID
values MUST be generated to be world-unique.
Example: Content-ID for Encapsulated Object
Content-ID: <123456789@example.net>
4.2.11 XMPP Presence Type 5.1.4 Presence Type
An XMPP presence stanza MAY possess a 'type' attribute. If no 'type' An XMPP presence stanza MAY possess a 'type' attribute. If no 'type'
attribute is included, the presence stanza indicates that the sender attribute is included, the presence stanza indicates that the sender
is available; this state maps to the PIDF basic presence type of is available; this state maps to the PIDF basic presence type of
OPEN. If the 'type' attribute has a value of "unavailable", the OPEN. If the 'type' attribute has a value of "unavailable", the
presence stanza indicates that the sender is no longer available; presence stanza indicates that the sender is no longer available;
this state maps to the PIDF basic presence type of CLOSED. Thus both this state maps to the PIDF basic presence type of CLOSED. Thus both
the absence of a 'type' attribute and a 'type' attribute set to a the absence of a 'type' attribute and a 'type' attribute set to a
value of "unavailable" correspond to the [CPP] "notify operation". value of "unavailable" correspond to the [CPP] "notify operation".
All other presence types are used to manage presence subscriptions or All other presence types are used to manage presence subscriptions or
probe for current presence; mappings for these other presence types probe for current presence; mappings for these other presence types
are defined under XMPP-CPIM Gateway as Presence Service (Section 5). are defined under XMPP-CPIM Gateway as Presence Service (Section 6).
Example: Available Presence Example: Available Presence
XMPP available presence XMPP available presence
<presence from='juliet@example.com/balcony'/> <presence from='juliet@example.com/balcony'/>
PIDF basic presence (OPEN) PIDF basic presence (OPEN)
<?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'
entity='pres:juliet@example.com'> entity='pres:juliet@example.com'>
skipping to change at page 18, line 5 skipping to change at page 17, line 20
<?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'
entity='pres:romeo@example.net'> entity='pres:romeo@example.net'>
<tuple id='balcony'> <tuple id='balcony'>
<status> <status>
<basic>closed</basic> <basic>closed</basic>
</status> </status>
</tuple> </tuple>
</presence> </presence>
4.2.12 XMPP Show Element 5.1.5 Show Element
The <show/> child element of an XMPP presence stanza provides The <show/> child element of an XMPP presence stanza provides
additional information about the sender's availability. The XML additional information about the sender's availability. The XML
character data of the XMPP <show/> element maps to extended <status/> character data of the XMPP <show/> element maps to extended <status/>
content in PIDF. The defined values of the <show/> element are content in PIDF. The defined values of the <show/> element are
'away', 'chat', 'dnd', and 'xa'; as soon as values are specified for 'away', 'chat', 'dnd', and 'xa'; as soon as values are specified for
extended status states in the 'urn:ietf:params:xml:ns:pidf:im' extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
namespace, the XMPP values will be mapped to the PIDF values. namespace, the XMPP values will be mapped to the PIDF values.
Example: Show Element Example: Show Element
skipping to change at page 18, line 35 skipping to change at page 18, line 5
xmlns:im='urn:ietf:params:xml:ns:pidf:im' xmlns:im='urn:ietf:params:xml:ns:pidf:im'
entity='pres:juliet@example.com'> entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>away</im:im> <im:im>away</im:im>
</status> </status>
</tuple> </tuple>
</presence> </presence>
4.2.13 XMPP Status Element 5.1.6 Status Element
The <status/> child element of an XMPP presence stanza provides a The <status/> child element of an XMPP presence stanza provides a
user-defined, natural-language description of the sender's detailed user-defined, natural-language description of the sender's detailed
availability state. The XMPP <status/> element maps to the PIDF availability state. The XMPP <status/> element maps to the PIDF
<note/> child of the PIDF <tuple/> element. <note/> child of the PIDF <tuple/> element.
Example: Status Element Example: Status Element
XMPP <status/> element XMPP <status/> element
<presence from='juliet@example.com/balcony'> <presence from='juliet@example.com/balcony'>
skipping to change at page 19, line 16 skipping to change at page 18, line 34
entity='pres:juliet@example.com'> entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>away</im:im> <im:im>away</im:im>
</status> </status>
<note>retired to the chamber</note> <note>retired to the chamber</note>
</tuple> </tuple>
</presence> </presence>
4.2.14 PIDF Contact Element 5.1.7 Presence Priority
The core XMPP specification does not include syntax for specifying
the URL of a contact address, since the contact address is implicit
in the 'from' attribute of the XMPP presence stanza. However, an
XMPP-CPIM gateway MAY include the <contact/> child of the <tuple/>
element, the value of which SHOULD be the <user@host> of the XMPP
sender, prepended by the "im:" Instant Messaging URI scheme.
Example: PIDF Contact Element
XMPP presence stanza
<presence from='juliet@example.com/balcony'/>
PIDF <contact/> element
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:juliet@example.com'>
<tuple id='balcony'>
...
<contact>im:juliet@example.com</contact>
</tuple>
</presence>
4.2.15 Presence Priority
An XMPP presence stanza MAY contain a <priority/> child element whose An XMPP presence stanza MAY contain a <priority/> child element whose
value is an integer between -128 and +127. The value of this element value is an integer between -128 and +127. The value of this element
MAY be mapped to the 'priority' attribute of the <contact/> child of MAY be mapped to the 'priority' attribute of the <contact/> child of
the PIDF <tuple/> element. If the value of the XMPP <priority/> the PIDF <tuple/> element. If the value of the XMPP <priority/>
element is negative, an XMPP-CPIM gateway MUST NOT map the value. element is negative, an XMPP-CPIM gateway MUST NOT map the value.
The range of allowable values for the PIDF 'priority' attribute is The range of allowable values for the PIDF 'priority' attribute is
any decimal number from zero to one inclusive, with a maximum of any decimal number from zero to one inclusive, with a maximum of
three decimal places. If an XMPP-CPIM gateway maps these values, it three decimal places. If an XMPP-CPIM gateway maps these values, it
SHOULD treat XMPP <priority>0</priority> as PIDF priority='0' and SHOULD treat XMPP <priority>0</priority> as PIDF priority='0' and
skipping to change at page 20, line 29 skipping to change at page 19, line 22
PIDF <note/> element PIDF <note/> element
<?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'
entity='pres:juliet@example.com'> entity='pres:juliet@example.com'>
<tuple id='balcony'> <tuple id='balcony'>
... ...
<contact priority='0.102'>im:juliet@example.com</contact> <contact priority='0.102'>im:juliet@example.com</contact>
</tuple> </tuple>
</presence> </presence>
4.2.16 PIDF Timestamp Element 5.1.8 Presence Extensions
The core XMPP specification does not include syntax for specifying
the datetime at which a presence stanza was sent. However, an
XMPP-CPIM gateway MAY include a <timestamp/> element within the PIDF
document it generates, the value of which SHOULD be the datetime at
which the presence stanza was received for processing by the gateway.
4.2.17 XMPP Presence Extensions
As defined in [XMPP-CORE], an XMPP presence stanza may contain As defined in [XMPP-CORE], an XMPP presence stanza may contain
"extended" content in any namespace in order to supplement or extend "extended" content in any namespace in order to supplement or extend
the semantics of the core presence stanza. With the exception of the semantics of the core presence stanza. With the exception of
extended information qualified by the extended information qualified by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E], 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as defined in [XMPP-E2E],
an XMPP-CPIM gateway SHOULD ignore such information and not pass it an XMPP-CPIM gateway SHOULD ignore such information and not pass it
through the gateway to the intended recipient. No mapping for such through the gateway to the intended recipient. No mapping for such
information is defined. information is defined.
4.3 Presence Syntax Mapping from CPIM Specifications to XMPP 5.1.9 Gateway-Generated CPIM and PIDF Syntax
5.1.9.1 CPIM Message Headers
CPIM specifies the existence of "Message/CPIM" headers in addition to
those described above, but there is no exact analogue for those
headers in the core XMPP specifications. These include:
o cc -- specifies the address of an entity that is to receive a
"courtesy copy" of the presence information (i.e., a non-primary
addressee)
o DateTime -- specifies the datetime at which the presence
information was sent
o NS -- specifies the namespace of a feature extension
o Subject -- specifies the subject or topic of the encapsulated
"Message/CPIM" object
o Required -- specifies mandatory-to-recognize features
An XMPP-CPIM gateway MAY independently generate such headers based on
its own information (e.g., the datetime at which it received a
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
this memo.
5.1.9.2 PIDF Elements
PIDF specifies the existence of XML elements in addition to those
described above, but there is no exact analogue for those XML
elements in the core XMPP specifications. These include:
o <contact/> -- specifies an address (e.g., an im:, tel:, or mailto:
URI) at which one may communicate with the presentity; an
XMPP-CPIM gateway MAY include this element, in which case it
SHOULD set its value to the <user@host> of the XMPP sender,
prepended by the "im:" Instant Messaging URI scheme.
o <timestamp/> -- specifies the datetime at which the presence
information was sent; an XMPP-CPIM gateway MAY independently
generate this element based on its own information (e.g., the
datetime at which it received the 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 this memo.
5.2 Presence 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/
CPIM" objects with encapsulated "application/pidf+xml" objects to CPIM" objects with encapsulated "application/pidf+xml" objects to
XMPP presence stanzas. XMPP presence stanzas.
4.3.1 From Address Note: An XMPP-CPIM gateway MUST NOT map to an XMPP presence stanza a
"Message/CPIM" object whose encapsulated MIME object has a
Content-type other than "application/pidf+xml" (with the exception of
multi-part MIME objects as specified in [XMPP-E2E]).
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 'from'
attribute of an XMPP presence stanza. To map the CPIM 'From' header attribute of an XMPP presence stanza. To map the CPIM 'From' header
to the XMPP 'from' attribute, the gateway MUST remove the "im:" to the XMPP 'from' attribute, the gateway MUST remove the "im:"
Instant Messaging URI scheme from the front of the address and MUST Instant Messaging URI scheme from the front of the address and MUST
remove the CPIM "Formal-name" (if provided). remove the CPIM "Formal-name" (if provided).
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>
4.3.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.
Example: To Address Mapping Example: To Address Mapping
CPIM 'To' header CPIM 'To' header
To: Juliet Capulet <im:juliet@example.com> To: Juliet Capulet <im:juliet@example.com>
XMPP 'to' attribute XMPP 'to' attribute
<presence to='juliet@example.com/balcony'> <presence to='juliet@example.com/balcony'>
... ...
</presence> </presence>
4.3.3 CPIM 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 that information on to the XMPP recipient.
4.3.4 CPIM 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
that information on to the XMPP recipient. that information on to the XMPP recipient.
4.3.5 CPIM 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 that
information on to the XMPP recipient. information on to the XMPP recipient.
4.3.6 CPIM 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.
4.3.7 CPIM Required Headers 5.2.7 Required Headers
"Message/CPIM" objects MAY include an optional 'Required' header to "Message/CPIM" objects MAY include an optional 'Required' 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.
4.3.8 PIDF MIME Content-type 5.2.8 MIME Content-ID
As specified in [MSGFMT], a "Message/CPIM" object MAY contain any
arbitrary MIME content. However, support for arbitrary content types
is not a requirement in XMPP. An XMPP-CPIM gateway MUST NOT map to
an XMPP presence stanza a "Message/CPIM" object whose encapsulated
MIME object has a Content-type other than "application/pidf+xml"
(with the exception of multi-part MIME objects as specified in
[XMPP-E2E]).
4.3.9 PIDF 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 presence stanza's 'id' attribute but is NOT REQUIRED to value of the presence stanza's 'id' attribute, but this is OPTIONAL.
do so.
Example: Content-ID for Encapsulated Object Example: Content-ID for Encapsulated Object
MIME header MIME header
Content-ID: <123456789@example.net> Content-ID: <123456789@example.net>
XMPP 'id' attribute (OPTIONAL) XMPP 'id' attribute (OPTIONAL)
<presence id='123456789@example.net'> <presence id='123456789@example.net'>
... ...
</presence> </presence>
4.3.10 PIDF Basic Presence Status 5.2.9 Basic Presence Status
The basic presence status types defined in PIDF are OPEN and CLOSED. The basic presence status types defined in PIDF are OPEN and CLOSED.
The PIDF basic presence status of OPEN maps to an XMPP presence The PIDF basic presence status of OPEN maps to an XMPP presence
stanza that possesses no 'type' attribute (indicating default stanza that possesses no 'type' attribute (indicating default
availability). The PIDF basic presence status of CLOSED maps to an availability). The PIDF basic presence status of CLOSED maps to an
XMPP presence stanza that possesses a 'type' attribute with a value XMPP presence stanza that possesses a 'type' attribute with a value
of "unavailable". of "unavailable".
Example: OPEN Presence Example: OPEN Presence
skipping to change at page 24, line 13 skipping to change at page 23, line 39
<status> <status>
<basic>closed</basic> <basic>closed</basic>
</status> </status>
</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'/>
4.3.11 PIDF 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
correspond to the defined values of the XMPP <show/> element ('away', correspond 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'); as soon as values are specified for
extended status states in the 'urn:ietf:params:xml:ns:pidf:im' extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
namespace, the PIDF values will be mapped to the relevant XMPP namespace, the PIDF values will be mapped to the relevant XMPP
values. values.
Example: Extended Status Information (provisional) Example: Extended Status Information (provisional)
skipping to change at page 24, line 43 skipping to change at page 24, line 25
<im:im>busy</im:im> <im:im>busy</im:im>
</status> </status>
</tuple> </tuple>
</presence> </presence>
XMPP <show/> element XMPP <show/> element
<presence from='romeo@example.net/orchard'> <presence from='romeo@example.net/orchard'>
<show>dnd</show> <show>dnd</show>
</presence> </presence>
4.3.12 PIDF Note Element 5.2.11 Note Element
A PIDF <tuple/> element may contain a <note/> child that provides a A PIDF <tuple/> element may contain a <note/> child that provides a
user-defined, natural-language description of the sender's detailed user-defined, natural-language description of the sender's detailed
availability state. The PIDF <note/> element maps to the XMPP availability state. The PIDF <note/> element maps to the XMPP
<status/> element. <status/> element.
Example: Note Element Example: Note Element
PIDF <note/> element PIDF <note/> element
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
skipping to change at page 25, line 33 skipping to change at page 25, line 12
<show>dnd</show> <show>dnd</show>
<status>Wooing Juliet</status> <status>Wooing Juliet</status>
</presence> </presence>
A PIDF document with zero tuples MAY contain one or more <note/> A PIDF document with zero tuples MAY contain one or more <note/>
elements as direct children of the PIDF <presence/> element. There elements as direct children of the PIDF <presence/> element. There
is no mapping of such a PIDF document to an XMPP presence stanza; an is no mapping of such a PIDF document to an XMPP presence stanza; an
entity on the non-XMPP side of an XMPP-CPIM gateway SHOULD NOT send entity on the non-XMPP side of an XMPP-CPIM gateway SHOULD NOT send
such a PIDF document to an XMPP recipient if possible, and an such a PIDF document to an XMPP recipient if possible, and an
XMPP-CPIM gateway MUST NOT map such a PIDF document to an XMPP XMPP-CPIM gateway MUST NOT map such a PIDF document to an XMPP
presence stanza (see Zero Resources (Section 5.4.2)). presence stanza (see Zero Resources (Section 6.3.2)).
4.3.13 PIDF Contact Element 5.2.12 Contact Element
The core XMPP specification does not include syntax for specifying A PIDF document may contain a <contact/> element specifying the URI
the URL of a contact address, since the contact address is implicit of an address at which the principal can be contacted (e.g., an im:,
in the 'from' attribute of the XMPP presence stanza. Therefore, if tel:, or mailto: URI). The core XMPP specification does not include
an XMPP-CPIM gateway receives a "Message/CPIM" object with syntax for specifying the URI of a contact address, since the contact
encapsulated PIDF object that contains a <contact/> element, it address is implicit in the 'from' attribute of the XMPP presence
SHOULD NOT pass the XML character data of the <contact/> element on stanza. Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM"
to the XMPP recipient. However, the gateway MAY map the 'priority' object with encapsulated PIDF object that contains a <contact/>
element as specified in the following section. element, it SHOULD NOT pass the XML character data of the <contact/>
element on to the XMPP recipient. (However, see Inclusion of
Complete PIDF Document (Section 5.2.15) below.)
Example: PIDF Contact Element Example: PIDF Contact Element
PIDF <contact/> element PIDF <contact/> element
<?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'
entity='pres:romeo@example.net'> entity='pres:romeo@example.net'>
<tuple id='orchard'> <tuple id='orchard'>
... ...
<contact>im:romeo@example.net</contact> <contact>im:romeo@example.net</contact>
</tuple> </tuple>
</presence> </presence>
XMPP presence stanza XMPP presence stanza
<presence from='romeo@example.net/orchard'/> <presence from='romeo@example.net/orchard'/>
4.3.14 Presence Priority 5.2.13 Presence Priority
The <contact/> child of the PIDF <tuple/> element MAY possess a The <contact/> child of the PIDF <tuple/> element MAY possess a
'priority' attribute whose value is a decimal number between zero and 'priority' attribute whose value is a decimal number between zero and
one (with a maximum of three decimal places). The value of this one (with a maximum of three decimal places). The value of this
attribute MAY be mapped to the <priority/> child element of an XMPP attribute MAY be mapped to the <priority/> child element of an XMPP
presence stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority presence stanza. An XMPP-CPIM gateway MUST NOT map PIDF priority
values to negative values of the XMPP <priority/> element. If an values to negative values of the XMPP <priority/> element. If an
XMPP-CPIM gateway maps these values, it SHOULD treat PIDF XMPP-CPIM gateway maps these values, it SHOULD treat PIDF
priority='0' as XMPP <priority>0</priority> and PIDF priority='1' as priority='0' as XMPP <priority>0</priority> and PIDF priority='1' as
<priority>127</priority>, mapping intermediate values appropriately <priority>127</priority>, mapping intermediate values appropriately
so that they are unique (e.g., PIDF priorities between 0.001 and so that they are unique (e.g., PIDF priorities between 0.001 and
0.007 to XMPP priority 1, PIDF priorities between 0.008 and 0.015 to 0.007 to XMPP priority 1, PIDF priorities between 0.008 and 0.015 to
XMPP priority 2, and so on up through mapping PIDF priorities between XMPP priority 2, and so on up through mapping PIDF priorities between
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).
4.3.15 PIDF 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 that information on to the XMPP recipient.
5. XMPP-CPIM Gateway as Presence Service 5.2.15 Inclusion of Complete PIDF Document
Certain PIDF elements do not map to XMPP presence stanza syntax
(e.g., the XML character data of the <contact/> element). However,
an XMPP client may be able to handle such information by parsing a
native PIDF document. To make this possible, an XMPP-CPIM gateway
MAY include the complete PIDF document as a child element of the
presence stanza, as described in [XMPP-PIDF]. If an XMPP client does
not understand this extended data, it naturally MUST ignore it.
6. XMPP-CPIM Gateway as Presence Service
[CPP] defines semantics for an abstract presence service. An [CPP] defines semantics for an abstract presence service. An
XMPP-CPIM gateway MAY function as such a presence service, and if so XMPP-CPIM gateway MAY function as such a presence service, and if so
an XMPP entity can use defined XMPP syntax to interact with the an XMPP entity can use defined XMPP syntax to interact with the
gateway's presence service. Because [PIDF] does not specify syntax gateway's presence service. Because [PIDF] does not specify syntax
for semantic operations such as subscribe, this section defines only for semantic operations such as subscribe, this section defines only
the XMPP interactions with the presence service offered by an the XMPP interactions with the presence service offered by an
XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF. XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF.
(Note: Detailed information about XMPP presence services can be found (Note: Detailed information about XMPP presence services can be found
in [XMPP-IM]; as much as possible, an XMPP-CPIM gateway SHOULD in [XMPP-IM]; as much as possible, an XMPP-CPIM gateway SHOULD
implement the syntax, semantics, and server business rules defined implement the syntax, semantics, and server business rules defined
therein.) therein.)
5.1 Requesting a Subscription 6.1 Requesting a Subscription
If an XMPP entity wants to subscribe to the presence information of a If an XMPP entity wants to subscribe to the presence information of a
non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
presence stanza of type "subscribe" to the target presentity. The presence stanza of type "subscribe" to the target presentity. The
syntax mapping is as follows: syntax mapping is as follows:
o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
"watcher parameter" field (pres:user@host). The XMPP-CPIM gateway "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the MUST append the "pres:" Presence URI scheme to the front of the
address. address.
skipping to change at page 27, line 16 skipping to change at page 27, line 9
If an XMPP entity wants to subscribe to the presence information of a If an XMPP entity wants to subscribe to the presence information of a
non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
presence stanza of type "subscribe" to the target presentity. The presence stanza of type "subscribe" to the target presentity. The
syntax mapping is as follows: syntax mapping is as follows:
o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
"watcher parameter" field (pres:user@host). The XMPP-CPIM gateway "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the MUST append the "pres:" Presence URI scheme to the front of the
address. address.
o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
"target parameter" field (pres:user@host). The XMPP-CPIM gateway "target parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the MUST append the "pres:" Presence URI scheme to the front of the
address. address.
o There is no XMPP mapping for the CPP "duration parameter", since o There is no XMPP mapping for the CPP "duration parameter", since
XMPP subscriptions are active until they have been explicitly XMPP subscriptions are active until they have been explicitly
"unsubscribed" (see Subscription Durations (Section 5.3)). "unsubscribed".
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field. field.
If the target presentity approves the subscription request (through If the target presentity approves the subscription request (through
whatever protocol it uses to interact with the gateway), the whatever protocol it uses to interact with the gateway), the
XMPP-CPIM gateway MUST return a presence stanza of type "subscribed" XMPP-CPIM gateway MUST return a presence stanza of type "subscribed"
to the XMPP entity and notify the XMPP entity of the target's current to the XMPP entity and notify the XMPP entity of the target's current
available presence. Thereafter, until the subscription is cancelled, available presence. Thereafter, until the subscription is cancelled,
the gateway MUST notify the subscribing XMPP entity every time the the gateway MUST notify the subscribing XMPP entity every time the
target's presence information changes. target's presence information changes.
If the target presentity denies the subscription request, the If the target presentity denies the subscription request, the
XMPP-CPIM gateway MUST return a presence stanza of type XMPP-CPIM gateway MUST return a presence stanza of type
"unsubscribed" to the XMPP entity and MUST NOT invoke the notify "unsubscribed" to the XMPP entity and MUST NOT invoke the notify
operation. operation.
In addition to the approval and denial cases, one of the following In addition to the approval and denial cases, one of the following
exceptions MAY occur: exceptions may occur:
o The target parameter (XMPP "to" address) does not refer to a valid o The target parameter (XMPP "to" address) does not refer to a valid
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.
5.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:
o The CPP "watcher parameter" field (pres:user@host) MUST be mapped o The CPP "watcher parameter" field (pres:user@host) MUST be mapped
skipping to change at page 28, line 24 skipping to change at page 28, line 11
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:
o The CPP "watcher parameter" field (pres:user@host) MUST be mapped o The CPP "watcher parameter" field (pres:user@host) MUST be mapped
to the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway to the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway
MUST remove the "pres:" Presence URI scheme from the front of the MUST remove the "pres:" Presence URI scheme from the front of the
address. address.
o The CPP "target parameter" field (pres:user@host) MUST be mapped o The CPP "target parameter" field (pres:user@host) MUST be mapped
to the XMPP 'to' attribute (user@host). The XMPP-CPIM gateway to the XMPP 'to' attribute (user@host). The XMPP-CPIM gateway
MUST remove the "pres:" Presence URI scheme from the front of the MUST remove the "pres:" Presence URI scheme from the front of the
address. address.
o There is no XMPP mapping for the CPP "duration parameter", since o There is no XMPP mapping for the CPP "duration parameter", since
XMPP subscriptions are active until they have been explicitly XMPP subscriptions are active until they have been explicitly
"unsubscribed" (see Subscription Durations (Section 5.3)). "unsubscribed".
o The CPP "TransID" field SHOULD be mapped to the XMPP 'id'
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" attribute.
field.
If the target XMPP entity approves the subscription request, it MUST If the target XMPP entity approves the subscription request, it MUST
send a presence stanza of type "subscribed" to the watcher send a presence stanza of type "subscribed" to the watcher
presentity. The XMPP-CPIM gateway MUST then notify the watcher presentity. The XMPP-CPIM gateway MUST then notify the watcher
presentity of the target XMPP entity's current available presence. presentity of the target XMPP entity's current available presence.
Thereafter, until the subscription is cancelled, the gateway MUST Thereafter, until the subscription is cancelled, the gateway MUST
notify the watcher presentity every time the target's presence notify the watcher presentity every time the target's presence
information changes. information changes.
If the target XMPP entity denies the subscription request, it MUST If the target XMPP entity denies the subscription request, it MUST
skipping to change at page 29, line 7 skipping to change at page 28, line 39
If the target XMPP entity denies the subscription request, it MUST If the target XMPP entity denies the subscription request, it MUST
send a presence stanza of type "unsubscribed" to the watcher send a presence stanza of type "unsubscribed" to the watcher
presentity. The XMPP-CPIM gateway MUST NOT invoke the notify presentity. The XMPP-CPIM gateway MUST NOT invoke the notify
operation. operation.
In addition to the approval and denial cases, one of the following In addition to the approval and denial cases, one of the following
exceptions MAY occur: exceptions MAY occur:
o The target parameter (XMPP "to" address) does not refer to a valid o The target parameter (XMPP "to" address) does not refer to a valid
XMPP entity XMPP entity
o Access control rules do not permit the watcher presentity to o Access control rules do not permit the watcher presentity to
subscribe to the target XMPP entity subscribe to the target 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 watcher presentity and the target XMPP operation between the watcher presentity and the target XMPP
entity entity
If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform
the watcher presentity of failure. the watcher presentity of failure.
5.3 Subscription Durations
XMPP services assume that a subscription is active until it is XMPP services assume that a subscription is active until it is
explicitly terminated. With the exception of handling duration explicitly terminated. With the exception of handling duration
parameters whose value is zero, handling duration parameters will be parameters whose value is zero, handling duration parameters will be
highly dependent on the implementation and requirements of the highly dependent on the implementation and requirements of the
XMPP-CPIM gateway. Since there are no explicit requirements for XMPP-CPIM gateway. Since there are no explicit requirements for
supporting a "duration parameter" specified in either [IMP-MODEL] or supporting a "duration parameter" specified in either [IMP-MODEL] or
[IMP-REQS], duration parameter mapping is a local issue that falls [IMP-REQS], duration parameter mapping is a local issue that falls
outside the scope of this memo. outside the scope of this memo. However, an XMPP-CPIM gateway MAY
keep track of the duration parameter if received from an entity on
the non-XMPP service and delete the subscription after that duration
parameter expires.
5.4 The Notify Operation 6.3 The Notify Operation
An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the
presence information associated with an XMPP entity or CPP presentity presence information associated with an XMPP entity or CPP presentity
changes and there are subscribers to that information on the other changes and there are subscribers to that information on the other
side of the gateway. The syntax mapping for presence information side of the gateway. The syntax mapping for presence information
related to a notify operation is defined under Mapping for Presence related to a notify operation is defined under Mapping for Presence
(Section 4). (Section 5).
5.4.1 Multiple Resources 6.3.1 Multiple Resources
Semantically, PIDF contains the notion of multiple presence "tuples". Semantically, PIDF contains the notion of multiple presence "tuples".
Normally, a PIDF document will contain at least one tuple but MAY Normally, a PIDF document will contain at least one tuple but MAY
contain more than one tuple (or zero tuples, for which see next contain more than one tuple (or zero tuples, for which see next
section). In the terminology of XMPP, each tuple would map to section). In the terminology of XMPP, each tuple would map to
presence information for a separate resource. However, XMPP does not presence information for a separate resource. However, XMPP does not
include the ability to send presence information about more than one include the ability to send presence information about more than one
resource at a time, since the resource that generates the presence resource at a time, since the resource that generates the presence
information is contained in the 'from' address of a presence stanza. information is contained in the 'from' address of a presence stanza.
Therefore, an XMPP-CPIM gateway that acts as a presence service Therefore, an XMPP-CPIM gateway that acts as a presence service
skipping to change at page 30, line 18 skipping to change at page 30, line 5
in the availability status of the device or application associated in the availability status of the device or application associated
with that tuple ID. with that tuple ID.
In the interest of complying with the PIDF recommendation to provide In the interest of complying with the PIDF recommendation to provide
information about multiple "resources" in multiple tuples rather than information about multiple "resources" in multiple tuples rather than
in multiple PIDF documents, an XMPP-CPIM gateway SHOULD include in multiple PIDF documents, an XMPP-CPIM gateway SHOULD include
information about all of an XMPP user's resources in one PIDF information about all of an XMPP user's resources in one PIDF
document (with one tuple for each resource), even if the availability document (with one tuple for each resource), even if the availability
status of only one resource has changed. status of only one resource has changed.
5.4.2 Zero Resources 6.3.2 Zero Resources
A PIDF document may contain zero tuples. For example: A PIDF document may contain zero tuples. For example:
PIDF Document with Zero Tuples PIDF Document with Zero Tuples
<presence entity='pres:juliet@example.com' <presence entity='pres:juliet@example.com'
xmlns='urn:ietf:params:xml:ns:pidf'/> xmlns='urn:ietf:params:xml:ns:pidf'/>
Because (1) the 'entity' attribute of a PIDF <presence/> element maps Because (1) the 'entity' attribute of a PIDF <presence/> element maps
to the <user@host> portion of an XMPP address and (2) the 'id' to the <user@host> portion of an XMPP address and (2) the 'id'
attribute of a PIDF <tuple/> element maps to the resource identifier attribute of a PIDF <tuple/> element maps to the resource identifier
portion of an XMPP address, a PIDF document that contains zero tuples portion of an XMPP address, a PIDF document that contains zero tuples
would provide presence information about a <user@host> rather than a would provide presence information about a <user@host> rather than a
<user@host/resource> when mapped to XMPP. However, the notion of <user@host/resource> when mapped to XMPP. Although the notion of
presence about a user rather than a user's resources is meaningless presence notifications about a mere user rather than one of the
in the XMPP context. Therefore, an XMPP-CPIM gateway MUST NOT map a user's resources is nearly meaningless in the XMPP context, an
PIDF document with zero tuples into an XMPP presence stanza, and MUST XMPP-CPIM gateway SHOULD map a PIDF document with zero tuples to an
NOT generate such a PIDF document when receiving a presence stanza XMPP presence stanza whose 'from' address is the user@host of the
from an XMPP entity (i.e., all PIDF documents generated by the non-XMPP entity. However, an XMPP-CPIM gateway MUST NOT generate a
gateway MUST contain at least one <tuple/> element). PIDF document with zero <tuple/> children when receiving a presence
stanza from an XMPP entity (i.e., all PIDF documents communicated by
the gateway to a non-XMPP service MUST contain at least one <tuple/>
element).
5.5 Unsubscribing 6.4 Unsubscribing
If an XMPP entity wants to unsubscribe from the presence of a If an XMPP entity wants to unsubscribe from the presence of a
non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
presence stanza of type "unsubscribe" to the target presentity. The presence stanza of type "unsubscribe" to the target presentity. The
syntax mapping is as follows: syntax mapping is as follows:
o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
"watcher parameter" field (pres:user@host). The XMPP-CPIM gateway "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST append the "pres:" Presence URI scheme to the front of the MUST append the "pres:" Presence URI scheme to the front of the
address. address.
skipping to change at page 31, line 21 skipping to change at page 31, line 9
field. field.
If the target parameter (XMPP "to" address) does not refer to a valid If the target parameter (XMPP "to" address) does not refer to a valid
presentity, the XMPP-CPIM gateway MUST return an <item-not-found/> presentity, the XMPP-CPIM gateway MUST return an <item-not-found/>
stanza error to the XMPP entity. stanza error to the XMPP entity.
Upon receiving the presence stanza of type "unsubscribe" from the Upon receiving the presence stanza of type "unsubscribe" from the
XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
notifications to the XMPP entity. notifications to the XMPP entity.
5.6 Cancelling a Subscription 6.5 Cancelling a Subscription
If an XMPP entity wants to cancel a non-XMPP presentity's If an XMPP entity wants to cancel a non-XMPP presentity's
subscription to the entity's presence through an XMPP-CPIM gateway, subscription to the entity's presence through an XMPP-CPIM gateway,
it MUST send a presence stanza of type "unsubscribed" to the target it MUST send a presence stanza of type "unsubscribed" to the target
presentity. The syntax mapping is as follows: presentity. The syntax mapping is as follows:
o The CPP "watcher parameter" field (pres:user@host) MUST be mapped o The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
to the XMPP 'from' attribute (user@host). The XMPP-CPIM gateway "watcher parameter" field (pres:user@host). The XMPP-CPIM gateway
MUST remove the "pres:" Presence URI scheme from the front of the MUST add the "pres:" Presence URI scheme to the front of the
address. address.
o The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
o The CPP "target parameter" field (pres:user@host) MUST be mapped "target parameter" field (pres:user@host). The XMPP-CPIM gateway
to the XMPP 'to' attribute (user@host). The XMPP-CPIM gateway MUST add the "pres:" Presence URI scheme to the front of the
MUST remove the "pres:" Presence URI scheme from the front of the
address. address.
o The CPP "duration parameter" MUST be set to zero. o The CPP "duration parameter" MUST be set to zero.
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field. field.
Upon receiving the presence stanza of type "unsubscribed" from the Upon receiving the presence stanza of type "unsubscribed" from the
XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
notifications to the watcher presentity. notifications to the watcher presentity.
6. Internationalization Considerations
6.1 Addresses
Although XMPP enables full internationalization of XMPP addresses
(see [XMPP-CORE]), there is no guarantee that non-XMPP addresses can
include characters other than [US-ASCII]. If an XMPP user attempts to
communicate with a non-XMPP user through an XMPP-CPIM gateway, the
XMPP user SHOULD NOT assume that the non-XMPP service supports fully
internationalized addresses.
6.2 Character Encodings
The following rules apply to the mapping of character encodings
(charsets):
1. A gateway SHOULD map a "Message/CPIM" object whose charset is
"US-ASCII" or "UTF-8".
2. A gateway SHOULD NOT map a "Message/CPIM" object whose charset is
other than "US-ASCII" or "UTF-8".
7. Security Considerations 7. Security Considerations
Detailed security considerations for instant messaging and presence Detailed security considerations for instant messaging and presence
protocols are given in [IMP-REQS], specifically in Sections 5.1 protocols are given in [IMP-REQS], specifically in Sections 5.1
through 5.4. through 5.4.
This document specifies methods for exchanging instant messages and This document specifies methods for exchanging instant messages and
presence information through a gateway that implements [CPIM] and presence information through a gateway that implements [CPIM] and
[CPP]. Such a gateway MUST be compliant with the minimum security [CPP]. Such a gateway MUST be compliant with the minimum security
requirements of the instant messaging and presence protocols with requirements of the instant messaging and presence protocols with
skipping to change at page 33, line 22 skipping to change at page 32, line 31
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant [MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant
Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08 Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08
(work in progress), January 2003. (work in progress), January 2003.
[PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W.
and J. Peterson, "CPIM Presence Information Data Format", and J. Peterson, "CPIM Presence Information Data Format",
draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
[STRINGPREP]
Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("STRINGPREP")", RFC 3454,
December 2002.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[URL-GUIDE]
Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
"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", RFC 2279, January 1998.
[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-20 (work in Protocol (XMPP): Core", draft-ietf-xmpp-core-22 (work in
progress), November 2003. progress), January 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-06 (work in progress), November 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-19 (work in progress), November 2003. draft-ietf-xmpp-im-21 (work in progress), January 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.
[XMPP-PIDF]
Saint-Andre, P., "Transporting Presence Information Data
Format (PIDF) over the Extensible Messaging and Presence
Protocol (XMPP)", draft-saintandre-xmpp-pidf-00 (work in
progress), February 2004.
Author's Address Author's Address
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-02 A.1 Changes from draft-ietf-xmpp-cpim-03
o Removed references to UTF-16. o Addressed feedback from WG Chairs.
A.2 Changes from draft-ietf-xmpp-cpim-02
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.2 Changes from draft-ietf-xmpp-cpim-01 A.3 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.3 Changes from draft-ietf-xmpp-cpim-00 A.4 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
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
skipping to change at page 35, line 29 skipping to change at page 35, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 108 change blocks. 
382 lines changed or deleted 327 lines changed or added

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