doc: Add RFC documents

1 files changed, 1907 insertions, 0 deletions

diff --git a/doc/rfc/rfc3922.txt b/doc/rfc/rfc3922.txt
new file mode 100644
index 0000000..393ee7f
--- /dev/null
+++ b/doc/rfc/rfc3922.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group                                     P. Saint-Andre
+Request for Comments: 3922                    Jabber Software Foundation
+Category: Standards Track                                   October 2004
+
+
+    Mapping the Extensible Messaging and Presence Protocol (XMPP) to
+              Common Presence and Instant Messaging (CPIM)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This memo describes a mapping between the Extensible Messaging and
+   Presence Protocol (XMPP) and the Common Presence and Instant
+   Messaging (CPIM) specifications.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Approach . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Address Mapping  . . . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Syntax Mapping of Instant Messages . . . . . . . . . . . . . .  5
+   5.  Syntax Mapping of Presence Information . . . . . . . . . . . . 13
+   6.  XMPP-CPIM Gateway as Presence Service  . . . . . . . . . . . . 26
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre                 Standards Track                     [Page 1]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+1.  Introduction
+
+1.1.  Overview
+
+   The Instant Messaging and Presence (IMPP) Working Group has defined
+   an abstract framework for interoperability among instant messaging
+   (IM) and presence systems that are compliant with [IMP-REQS].  This
+   framework is commonly called Common Presence and Instant Messaging or
+   "CPIM".  The CPIM family of specifications include a Common Profile
+   for Instant Messaging [CPIM] (also called CPIM), a Common Profile for
+   Presence [CPP], a CPIM Message Format [MSGFMT], and a Common Presence
+   Information Data Format [PIDF].  (Note: To prevent confusion, Common
+   Presence and Instant Messaging is referred to herein collectively as
+   "the CPIM specifications", whereas the Common Profile for Instant
+   Messaging is referred to as "CPIM".)
+
+   This memo describes how the Extensible Messaging and Presence
+   Protocol ([XMPP-CORE], [XMPP-IM]) maps to the abstract model
+   contained in the CPIM specifications, mainly for the purpose of
+   establishing gateways between XMPP services and non-XMPP services
+   that conform to [IMP-REQS].  Such a gateway, referred to herein as an
+   "XMPP-CPIM gateway", may be established to interpret the protocols of
+   one service and translate them into the protocols of the other
+   service.  We can visualize this relationship as follows:
+
+     +-------------+        +-------------+        +------------+
+     |             |        |             |        |            |
+     |    XMPP     |        |  XMPP-CPIM  |        |  Non-XMPP  |
+     |   Service   | <----> |   Gateway   | <----> |  Service   |
+     |             |        |             |        |            |
+     +-------------+        +-------------+        +------------+
+
+   This memo defines a mapping for use by a gateway that translates
+   between XMPP and a non-XMPP protocol via the CPIM specifications.
+   Such a gateway is not an intermediate hop on a network of non-XMPP
+   servers (whose native formats may or may not be defined by the CPIM
+   specifications), but a dedicated translator between XMPP and a
+   non-XMPP protocol, where the CPIM specifications define the common
+   formats into which the protocols are translated for purposes of
+   interworking.
+
+   The mapping defined herein applies to instant messages and presence
+   information that are not encrypted or signed for end-to-end security.
+   For information about secure communications to or from an XMPP
+   service through an XMPP-CPIM gateway, refer to [XMPP-E2E].
+
+
+
+
+
+
+Saint-Andre                 Standards Track                     [Page 2]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+1.2.  Terminology
+
+   This memo inherits vocabulary defined in [IMP-MODEL].  Terms such as
+   CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE SERVICE,
+   PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same meaning as
+   defined therein.
+
+   This memo also inherits vocabulary defined in [XMPP-CORE].  Terms
+   such as ENTITY, NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE
+   IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same
+   meaning as defined therein.
+
+1.3.  Conventions Used in this Document
+
+   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [TERMS].
+
+2.  Approach
+
+   XMPP and CPIM are distinctly foreign technologies.  Therefore, care
+   must be taken in mapping between XMPP and the abstract syntax defined
+   by the CPIM specifications.
+
+   At root, XMPP is a data transport protocol for streaming XML elements
+   (called "stanzas") between any two endpoints on the network; message
+   and presence stanzas are two of the core data elements defined in
+   XMPP and are often used to exchange instant messages and presence
+   information between IM users (although the inherent extensibility of
+   XML enables applications to use the general semantics of these stanza
+   types for other purposes).  XMPP is not based on [MIME]; instead,
+   [XMPP-CORE] defines XML schemas for both message and presence stanzas
+   (for example, the <body/> child of a message stanza contains XML
+   character data that is usually intended to be read by a human user).
+
+   The CPIM specifications provide common formats for instant messaging
+   and presence through two [MIME] content-types: "Message/CPIM" for
+   messages ([MSGFMT]) and "application/pidf+xml" for presence ([PIDF]).
+   The syntax of "Message/CPIM" objects is similar to but stricter than
+   that defined in [RFC2822], and provides the ability to include
+   arbitrary MIME media types [MIMETYPES].  By contrast, each
+   "application/pidf+xml" object is a complete XML document whose
+   structure is defined by an XML schema.
+
+
+
+
+
+
+
+Saint-Andre                 Standards Track                     [Page 3]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   The approach taken herein is to specify mappings from XMPP elements
+   and attributes to the headers and MIME formats defined by [MSGFMT]
+   and [PIDF] in order to comply with the semantics defined by [CPIM]
+   and [CPP].  Naturally, mappings in the opposite direction are
+   provided as well.
+
+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 presentities (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]
+
+
+
+Saint-Andre                 Standards Track                     [Page 4]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   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
+   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
+   with the instant messaging semantics defined by [CPIM].
+
+4.1.  Message Syntax Mapping from XMPP to CPIM Specifications
+
+   This section defines the mapping of syntax primitives from XMPP
+   message stanzas to "Message/CPIM" objects with encapsulated text
+   content.
+
+   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
+
+
+
+
+
+Saint-Andre                 Standards Track                     [Page 5]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   "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'
+   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
+   <user@host/resource> negotiated between client and server during
+   authentication and resource binding as defined in [XMPP-CORE].  Thus
+   an XMPP-CPIM gateway will receive from the sender's XMPP server a
+   message stanza containing a "from" address of the form
+   <user@host/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 resource identifier, MUST append the "im:"  Instant
+   Messaging URI scheme to the front of the address, and MAY include a
+   CPIM "Formal-name" for the sender (if known).
+
+   Example: From Address Mapping
+
+   XMPP 'from' attribute
+     <message from='juliet@example.com/balcony'>
+       ...
+     </message>
+
+   CPIM 'From' header
+     From: Juliet Capulet <im:juliet@example.com>
+
+4.1.2.  To Address
+
+   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
+   'to' attribute on a message stanza, and MUST include it if the
+   message is intended for delivery to another user.  Thus an XMPP-CPIM
+   gateway will receive from the sender's XMPP server a message stanza
+   containing a "to" address of the form <user@host> or
+   <user@host/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 resource identifier (if included), MUST append the
+   "im:" Instant Messaging URI scheme to the front of the address, and
+   MAY include a CPIM "Formal-name" for the recipient (if known).
+
+
+
+
+
+
+
+
+
+
+Saint-Andre                 Standards Track                     [Page 6]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   Example: To Address Mapping
+
+   XMPP 'to' attribute
+     <message to='romeo@example.net/orchard'>
+       ...
+     </message>
+
+   CPIM 'To' header
+     To: Romeo Montague <im:romeo@example.net>
+
+4.1.3.  Stanza ID
+
+   An XMPP message stanza MAY possess an 'id' attribute, which is used
+   by the sending application for the purpose of tracking stanzas and is
+   not a globally-unique identifier such as is defined by the MIME
+   Content-ID header.  Because the XMPP 'id' attribute does not have the
+   same meaning as the MIME Content-ID header, it SHOULD NOT be mapped
+   to that header; however, if the 'id' is known to be unique (e.g., if
+   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.1.4.  Message Type
+
+   An XMPP message stanza MAY possess a 'type' attribute, which is used
+   by the sending application to capture the conversational context of
+   the message.  There is no mapping of an XMPP 'type' attribute to a
+   "Message/CPIM" header, common MIME features, or encapsulated text
+   content.  Therefore if an XMPP stanza received by an XMPP-CPIM
+   gateway possesses a 'type' attribute, the gateway SHOULD ignore the
+   value provided.
+
+4.1.5.  Message Thread
+
+   An XMPP message stanza MAY contain a <thread/> child element to
+   specify the conversation thread in which the message is situated.
+   There is no mapping of an XMPP <thread/> element to a "Message/CPIM"
+   header, common MIME features, or encapsulated text content. Therefore
+   if an XMPP message stanza received by an XMPP-CPIM gateway contains a
+   <thread/> child element, the gateway SHOULD ignore the value
+   provided.
+
+4.1.6.  Message Subject
+
+   An XMPP message stanza MAY include a <subject/> child element.  If
+   included, it maps to the 'Subject' header of a "Message/CPIM" object.
+   To map the XMPP <subject/> element to the 'Subject' header of a
+   "Message/CPIM" object, the gateway SHOULD simply map the XML
+   character data of the XMPP <subject/> element to the value of the
+
+
+
+Saint-Andre                 Standards Track                     [Page 7]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   'Subject' header.  The <subject/> element MAY include an 'xml:lang'
+   attribute specifying the language in which the subject is written. If
+   an 'xml:lang' attribute is provided, it MUST be mapped by including
+   ';lang=tag' after the header name and colon, where 'tag' is the value
+   of the 'xml:lang' attribute.
+
+   Example: Subject Mapping
+
+   XMPP <subject/> element
+     <subject>Hi!</subject>
+     <subject xml:lang='cz'>Ahoj!</subject>
+
+   CPIM 'Subject' header
+     Subject: Hi!
+     Subject:;lang=cz Ahoj!
+
+4.1.7.  Message Body
+
+   The <body/> child element of an XMPP message stanza is used to
+   provide the primary meaning of the message.  The XML character data
+   of the XMPP <body/> element maps to the encapsulated text message
+   content.
+
+   Example: Message Body
+
+   XMPP message <body/>
+     <message>
+       <body>Wherefore art thou, Romeo?</body>
+     </message>
+
+   Encapsulated MIME text content
+     Content-type: text/plain; charset=utf-8
+     Content-ID: <123456789@example.net>
+
+     Wherefore art thou, Romeo?
+
+4.1.8.  Message Extensions
+
+   As defined in [XMPP-CORE], an XMPP message stanza may contain
+   "extended" content in any namespace in order to supplement or extend
+   the semantics of the core message stanza.  With the exception of
+   extended information qualified by the
+   '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
+   through the gateway to the intended recipient.  No mapping for such
+   information is defined.
+
+
+
+
+
+Saint-Andre                 Standards Track                     [Page 8]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+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  Require -- 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/CPIM" objects with encapsualted text content to XMPP message
+   stanzas.
+
+4.2.1.  From Address
+
+   The 'From' header of a "Message/CPIM" object maps to the 'from'
+   attribute of an XMPP message stanza.  To map the CPIM 'From' header
+   to the XMPP 'from' attribute, the gateway MUST remove the "im:"
+   Instant Messaging URI scheme from the front of the address and MUST
+   remove the CPIM "Formal-name" (if provided).
+
+   Example: From Address Mapping
+
+   CPIM 'From' header
+     From: Romeo Montague <im:romeo@example.net>
+
+   XMPP 'from' attribute
+     <message from='romeo@example.net'>
+       ...
+     </message>
+
+4.2.2.  To Address
+
+   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
+   'to' attribute, the gateway MUST remove the "im:" Instant Messaging
+   URI scheme from the front of the address and MUST remove the CPIM
+
+
+
+Saint-Andre                 Standards Track                     [Page 9]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   "Formal-name" (if provided).  If the gateway possesses knowledge of
+   the resource identifier in use by the XMPP entity, the gateway MAY
+   append the resource identifier to the address.
+
+   Example: To Address Mapping
+
+   CPIM 'To' header
+     To: Juliet Capulet <im:juliet@example.com>
+
+   XMPP 'to' attribute
+     <message to='juliet@example.com/balcony'>
+       ...
+     </message>
+
+4.2.3.  Courtesy Copy
+
+   The core XMPP specification does not include syntax for specifying a
+   "courtesy copy" (non-primary addressee) for a message stanza.
+   Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
+   that contains a 'cc' header, it SHOULD NOT pass the information
+   contained in that header on to the XMPP recipient.
+
+4.2.4.  DateTime Header
+
+   The core XMPP specification does not include syntax for specifying
+   the datetime at which a message stanza was sent.  Therefore, if an
+   XMPP-CPIM gateway receives a "Message/CPIM" object that contains a
+   'DateTime' header, it SHOULD NOT pass the information contained in
+   that header on to the XMPP recipient.
+
+4.2.5.  Message 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' header to the XMPP <subject/> element, the gateway SHOULD
+   simply map the value of the 'Subject' header to the XML character
+   data of the XMPP <subject/> element.  The 'Subject' header MAY
+   specify the "lang" in which the subject is written.  If "lang"
+   information is provided, it MUST be mapped to the 'xml:lang'
+   attribute of the <subject/> element, where the value of the
+   'xml:lang' attribute is the "tag" value supplied in the string
+   ';lang=tag' included after the CPIM 'Subject' header name and colon.
+
+
+
+
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 10]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   Example: Subject Mapping
+
+   CPIM 'Subject' header
+     Subject: Hi!
+     Subject:;lang=cz Ahoj!
+
+   XMPP <subject/> element
+     <subject>Hi!</subject>
+     <subject xml:lang='cz'>Ahoj!</subject>
+
+4.2.6.  Header Extensions
+
+   "Message/CPIM" objects MAY include an optional 'NS' header to specify
+   the namespace of a feature extension.  An XMPP-CPIM gateway MUST NOT
+   pass such headers through to the XMPP recipient, and no mapping for
+   such headers is defined.
+
+4.2.7.  Require Header
+
+   "Message/CPIM" objects MAY include an optional 'Require' header to
+   specify mandatory-to-recognize features.  In general, such a header
+   would be included by the non-XMPP sending application to (1) insist
+   that the receiving application needs to understand functionality
+   specified by a particular header or (2) indicate that some non-header
+   semantics need to be implemented by the receiving application in
+   order to understand the contents of the message (e.g.,
+   "Locale.MustRenderKanji").  Because the mandatory-to-recognize
+   features would be required of the XMPP receiving application rather
+   than the XMPP-CPIM gateway itself, the gateway cannot properly handle
+   the 'Require' header without detailed knowledge about the
+   capabilities of the XMPP receiving application.  Therefore, it seems
+   appropriate that the XMPP-CPIM gateway SHOULD return a warning or
+   error to the non-XMPP sending application if it includes one or more
+   'Require' headers in a "Message/CPIM" object; the exact nature of the
+   warning or error will depend on the nature of the non-XMPP technology
+   used by the foreign system, and is not defined herein.  Furthermore,
+   any mapping of the 'Require' header into XMPP or an XMPP extension is
+   left up to the implementation or to a future specification.
+
+4.2.8.  MIME Content-ID
+
+   XMPP does not include an element or attribute that captures a
+   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
+   that includes a Content-ID, it MAY provide the Content-ID as the
+   value of the message stanza's 'id' attribute, but this is OPTIONAL.
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 11]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   Example: Content-ID for Encapsulated Object
+
+   MIME header
+     Content-ID: <123456789@example.net>
+
+   XMPP 'id' attribute (OPTIONAL)
+     <message id='123456789@example.net'>
+       ...
+     </message>
+
+4.2.9.  Message Body
+
+   If the Content-type of an encapsulated MIME object is "text/plain",
+   then the encapsulated text message content maps to the XML character
+   data of the <body/> child element of an XMPP message stanza.
+
+   Example: Message Body
+
+   Encapsulated MIME text content
+     Content-type: text/plain; charset=utf-8
+     Content-ID: <123456789@example.net>
+
+     Wherefore art thou?
+
+   XMPP message <body/>
+     <message id='123456789@example.net'>
+       <body>Wherefore art thou?</body>
+     </message>
+
+   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 MUST 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.
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 12]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+5.  Syntax Mapping of 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"
+   object as the bearer of an encapsulated [PIDF] object in order to
+   comply with the presence semantics defined by [CPP].
+
+5.1.  Presence Syntax Mapping from XMPP to CPIM Specifications
+
+   This section defines the mapping of syntax primitives from XMPP
+   presence stanzas to "Message/CPIM" objects with encapsulated
+   "application/pidf+xml" objects.
+
+   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'
+   header of a "Message/CPIM" object.  In XMPP, the sender's server
+   stamps or validates the "from" address and sets its value to the
+   <user@host/resource> negotiated between client and server during
+   authenticating and resource binding as defined in [XMPP-CORE].  Thus
+   an XMPP-CPIM gateway will receive from the sender's XMPP server a
+   presence stanza containing a "from" address of the form
+   <user@host/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 resource identifier, MUST append the "im:"
+   Instant Messaging URI scheme to the front of the address, and MAY
+   include a CPIM "Formal-name" for the sender (if known).
+
+   Example: From Address Mapping
+
+   XMPP 'from' attribute
+     <presence from='juliet@example.com/balcony'>
+       ...
+     </presence>
+
+   CPIM 'From' header
+     From: Juliet Capulet <im:juliet@example.com>
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 13]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   In addition, the 'from' attribute of an XMPP presence stanza maps to
+   the 'entity' attribute of a PIDF <presence/> root element.  To map
+   the XMPP 'from' attribute to the PIDF 'entity' attribute, the gateway
+   MUST remove the resource identifier and MUST append the "pres:"
+   Instant Messaging URI scheme to the front of the address.
+
+   Example: From Address Mapping (PIDF)
+
+   XMPP 'from' attribute
+     <presence from='juliet@example.com/balcony'>
+       ...
+     </presence>
+
+   PIDF 'entity' attribute
+     <presence entity='pres:juliet@example.com'>
+       ...
+     </presence>
+
+   Finally, an XMPP-CPIM gateway SHOULD map the resource identifier of
+   the XMPP address contained in the XMPP 'from' attribute to the 'id'
+   attribute of the PIDF <tuple/> child element.
+
+   Example: Resource Identifier Mapping
+
+   XMPP 'from' attribute
+     <presence from='juliet@example.com/balcony'>
+       ...
+     </presence>
+
+   PIDF 'id' for <tuple/>
+     <presence entity='pres:juliet@example.com'>
+       <tuple id='balcony'>
+         ...
+       </tuple>
+     </presence>
+
+5.1.2.  To Address
+
+   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'
+   attribute on a presence stanza, and MUST include it if the presence
+   stanza is intended for delivery directly to another user (presence
+   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 XMPP server a presence stanza containing a "to" address
+   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
+   "Message/CPIM" object, the gateway MUST remove the resource
+
+
+
+Saint-Andre                 Standards Track                    [Page 14]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   identifier (if included), MUST append the "im:" Instant Messaging URI
+   scheme to the front of the address, and MAY include a CPIM
+   "Formal-name" for the recipient (if known).
+
+   Example: To Address Mapping
+
+   XMPP 'to' attribute
+     <presence to='romeo@example.net/orchard'>
+       ...
+     </presence>
+
+   CPIM 'To' header
+     To: Romeo Montague <im:romeo@example.net>
+
+5.1.3.  Stanza ID
+
+   An XMPP presence stanza MAY possess an 'id' attribute, which is used
+   by the sending application for the purpose of tracking stanzas and is
+   not a globally-unique identifier such as is defined by the MIME
+   Content-ID header.  Because the XMPP 'id' attribute does not have the
+   same meaning as the MIME Content-ID header, it SHOULD NOT be mapped
+   to that header; however, if the 'id' is known to be unique (e.g., if
+   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.
+
+5.1.4.  Presence Type
+
+   An XMPP presence stanza MAY possess a 'type' attribute.  If no 'type'
+   attribute is included, the presence stanza indicates that the sender
+   is available; this state maps to the PIDF basic presence type of
+   OPEN.  If the 'type' attribute has a value of "unavailable", the
+   presence stanza indicates that the sender is no longer available;
+   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
+   value of "unavailable" correspond to the [CPP] "notify operation".
+   All other presence types are used to manage presence subscriptions or
+   probe for current presence; mappings for these other presence types
+   are defined under XMPP-CPIM Gateway as Presence Service (Section 6).
+
+   Example: Available Presence
+
+   XMPP available presence
+     <presence from='juliet@example.com/balcony'/>
+
+   PIDF basic presence (OPEN)
+     <?xml version='1.0' encoding='UTF-8'?>
+     <presence xmlns='urn:ietf:params:xml:ns:pidf'
+               entity='pres:juliet@example.com'>
+
+
+
+Saint-Andre                 Standards Track                    [Page 15]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+       <tuple id='balcony'>
+         <status>
+           <basic>open</basic>
+         </status>
+       </tuple>
+     </presence>
+
+   Example: Unavailable Presence
+
+   XMPP unavailable presence
+     <presence from='juliet@example.com/balcony' type='unavailable'/>
+
+   PIDF basic presence (CLOSED)
+     <?xml version='1.0' encoding='UTF-8'?>
+     <presence xmlns='urn:ietf:params:xml:ns:pidf'
+               entity='pres:romeo@example.net'>
+       <tuple id='balcony'>
+         <status>
+           <basic>closed</basic>
+         </status>
+       </tuple>
+     </presence>
+
+5.1.5.  Show Element
+
+   The <show/> child element of an XMPP presence stanza provides
+   additional information about the sender's availability.  The XML
+   character data of the XMPP <show/> element maps to extended <status/>
+   content in PIDF.  The defined values of the <show/> element are
+   'away', 'chat', 'dnd', and 'xa'; as soon as values are specified for
+   extended status states in the 'urn:ietf:params:xml:ns:pidf:im'
+   namespace, the XMPP values will be mapped to the PIDF values.
+
+   Example: Show Element
+
+   XMPP <show/> element
+     <presence from='juliet@example.com/balcony'>
+       <show>away</show>
+     </presence>
+
+   PIDF extended presence information
+     <?xml version='1.0' encoding='UTF-8'?>
+     <presence xmlns='urn:ietf:params:xml:ns:pidf'
+               xmlns:im='urn:ietf:params:xml:ns:pidf:im'
+               entity='pres:juliet@example.com'>
+       <tuple id='balcony'>
+         <status>
+           <basic>open</basic>
+
+
+
+Saint-Andre                 Standards Track                    [Page 16]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+           <im:im>away</im:im>
+         </status>
+       </tuple>
+     </presence>
+
+5.1.6.  Status Element
+
+   The <status/> child element of an XMPP presence stanza provides a
+   user-defined, natural-language description of the sender's detailed
+   availability state.  The XMPP <status/> element maps to the PIDF
+   <note/> child of the PIDF <tuple/> element.
+
+   Example: Status Element
+
+   XMPP <status/> element
+     <presence from='juliet@example.com/balcony'>
+       <show>away</show>
+       <status>retired to the chamber</status>
+     </presence>
+
+   PIDF <note/> element
+     <?xml version='1.0' encoding='UTF-8'?>
+     <presence xmlns='urn:ietf:params:xml:ns:pidf'
+               xmlns:im='urn:ietf:params:xml:ns:pidf:im'
+               entity='pres:juliet@example.com'>
+       <tuple id='balcony'>
+         <status>
+           <basic>open</basic>
+           <im:im>away</im:im>
+         </status>
+         <note>retired to the chamber</note>
+       </tuple>
+     </presence>
+
+5.1.7.  Presence Priority
+
+   An XMPP presence stanza MAY contain a <priority/> child element whose
+   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
+   the PIDF <tuple/> element.  If the value of the XMPP <priority/>
+   element is negative, an XMPP-CPIM gateway MUST NOT map the value. The
+   range of allowable values for the PIDF 'priority' attribute is any
+   decimal number from zero to one inclusive, with a maximum of three
+   decimal places.  If an XMPP-CPIM gateway maps these values, it SHOULD
+   treat XMPP <priority>0</priority> as PIDF priority='0' and XMPP
+   <priority>127</priority> as PIDF priority='1', mapping intermediate
+   values appropriately so that they are unique (e.g., XMPP priority 1
+   to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, and
+
+
+
+Saint-Andre                 Standards Track                    [Page 17]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   so on up through mapping XMPP priority 126 to PIDF priority 0.992;
+   note that this is an example only, and that the exact mapping shall
+   be determined by the XMPP-CPIM gateway).
+
+   Example: Presence Priority
+
+   XMPP <status/> element
+     <presence from='juliet@example.com/balcony'>
+       <priority>13</priority>
+     </presence>
+
+   PIDF <note/> 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 priority='0.102'>im:juliet@example.com</contact>
+       </tuple>
+     </presence>
+
+5.1.8.  Presence Extensions
+
+   As defined in [XMPP-CORE], an XMPP presence stanza may contain
+   "extended" content in any namespace in order to supplement or extend
+   the semantics of the core presence stanza.  With the exception of
+   extended information qualified by the
+   '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
+   through the gateway to the intended recipient.  No mapping for such
+   information is defined.
+
+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
+
+
+
+Saint-Andre                 Standards Track                    [Page 18]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   o  Subject -- specifies the subject or topic of the encapsulated
+      "Message/CPIM" object
+
+   o  Require -- 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/CPIM" objects with encapsulated "application/pidf+xml"
+   objects to XMPP presence stanzas.
+
+   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 <user@host>
+   portion of the 'from' attribute of an XMPP presence stanza, and the
+   'id' attribute of the PIDF <tuple/> child element maps to the
+   resource identifier portion XMPP 'from' attribute.  Therefore, to map
+   the CPIM and PIDF information to the XMPP 'from' attribute, the
+
+
+
+Saint-Andre                 Standards Track                    [Page 19]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   gateway MUST remove the "im:" Instant Messaging URI scheme from the
+   front of the address and MUST remove the CPIM "Formal-name" (if
+   provided) in order to generate the <user@host> portion of the XMPP
+   'from' attribute, then add a '/' character followed by the value of
+   the PIDF <tuple/> element's 'id' attribute.
+
+   Example: From Address Mapping
+
+   CPIM 'From' header
+     From: Romeo Montague <im:romeo@example.net>
+
+   XMPP 'from' attribute
+     <presence from='romeo@example.net'>
+       ...
+     </presence>
+
+   Example: Resource Identifier Mapping
+
+   XMPP 'from' attribute
+     <presence from='juliet@example.com/balcony'>
+       ...
+     </presence>
+
+   PIDF 'id' for <tuple/>
+     <presence entity='pres:juliet@example.com'>
+       <tuple id='balcony'>
+         ...
+       </tuple>
+     </presence>
+
+5.2.2.  To Address
+
+   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
+   'to' attribute, the gateway MUST remove the "im:" Instant Messaging
+   URI scheme from the front of the address and MUST remove the CPIM
+   "Formal-name" (if provided).  If the gateway possesses knowledge of
+   the resource identifier in use by the XMPP entity, the gateway MAY
+   append the resource identifier to the address.
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 20]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   Example: To Address Mapping
+
+   CPIM 'To' header
+     To: Juliet Capulet <im:juliet@example.com>
+
+   XMPP 'to' attribute
+     <presence to='juliet@example.com/balcony'>
+       ...
+     </presence>
+
+5.2.3.  Courtesy Copy
+
+   The core XMPP specification does not include syntax for specifying a
+   "courtesy copy" (non-primary addressee) for a presence stanza.
+   Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
+   with encapsulated PIDF object that contains a 'cc' header, it SHOULD
+   NOT pass the information contained in that header on to the XMPP
+   recipient.
+
+5.2.4.  DateTime Header
+
+   The core XMPP specification does not include syntax for specifying
+   the datetime at which a presence stanza was sent.  Therefore, if an
+   XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
+   PIDF object that contains a 'DateTime' header, it SHOULD NOT pass the
+   information contained in that header on to the XMPP recipient.
+
+5.2.5.  Subject Header
+
+   An XMPP presence stanza contains no information that can be mapped to
+   the 'Subject' header of a "Message/CPIM" object.  Therefore, if an
+   XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated
+   PIDF object that contains a 'Subject' header, it SHOULD NOT pass the
+   information contained in that header on to the XMPP recipient.
+
+5.2.6.  Header Extensions
+
+   "Message/CPIM" objects MAY include an optional 'NS' header to specify
+   the namespace of a feature extension.  An XMPP-CPIM gateway MUST NOT
+   pass such headers through to the XMPP recipient, and no mapping for
+   such headers is defined.
+
+5.2.7.  Require Header
+
+   "Message/CPIM" objects MAY include an optional 'Require' header to
+   specify mandatory-to-recognize features.  An XMPP-CPIM gateway MUST
+   NOT pass such headers through to the XMPP recipient, and no mapping
+   for such headers is defined.
+
+
+
+Saint-Andre                 Standards Track                    [Page 21]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+5.2.8.  MIME Content-ID
+
+   XMPP does not include an element or attribute that captures a
+   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
+   that includes a Content-ID, it MAY provide the Content-ID as the
+   value of the presence stanza's 'id' attribute, but this is OPTIONAL.
+
+   Example: Content-ID for Encapsulated Object
+
+   MIME header
+     Content-ID: <123456789@example.net>
+
+   XMPP 'id' attribute (OPTIONAL)
+     <presence id='123456789@example.net'>
+       ...
+     </presence>
+
+5.2.9.  Basic Presence Status
+
+   The basic presence status types defined in PIDF are OPEN and CLOSED.
+   The PIDF basic presence status of OPEN maps to an XMPP presence
+   stanza that possesses no 'type' attribute (indicating default
+   availability).  The PIDF basic presence status of CLOSED maps to an
+   XMPP presence stanza that possesses a 'type' attribute with a value
+   of "unavailable".
+
+   Example: OPEN Presence
+
+   PIDF basic presence (OPEN)
+     <?xml version='1.0' encoding='UTF-8'?>
+     <presence xmlns='urn:ietf:params:xml:ns:pidf'
+               entity='pres:romeo@example.net'>
+       <tuple id='orchard'>
+         <status>
+           <basic>open</basic>
+         </status>
+       </tuple>
+     </presence>
+
+   XMPP available presence
+     <presence from='romeo@example.net/orchard'/>
+
+
+
+
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 22]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   Example: CLOSED Presence
+
+   PIDF basic presence (CLOSED)
+     <?xml version='1.0' encoding='UTF-8'?>
+     <presence xmlns='urn:ietf:params:xml:ns:pidf'
+               entity='pres:romeo@example.net'>
+       <tuple id='orchard'>
+         <status>
+           <basic>closed</basic>
+         </status>
+       </tuple>
+     </presence>
+
+   XMPP unavailable presence
+     <presence from='romeo@example.net/orchard'
+               type='unavailable'/>
+
+5.2.10.  Extended Status Information
+
+   PIDF documents may contain extended <status/> content.  As of this
+   writing there are no pre-defined extended status states that can be
+   mapped to the defined values of the XMPP <show/> element ('away',
+   'chat', 'dnd', and 'xa').  Once PIDF extensions for such extended
+   status states are defined within the Internet Standards Process, a
+   gateway SHOULD map those extensions; however, any such mapping is out
+   of scope for this memo, since the relevant PIDF extensions have not
+   yet been defined.
+
+   Example: Extended Status Information (provisional)
+
+   PIDF extended presence information
+     <?xml version='1.0' encoding='UTF-8'?>
+     <presence xmlns='urn:ietf:params:xml:ns:pidf'
+               xmlns:im='urn:ietf:params:xml:ns:pidf:im'
+               entity='pres:romeo@example.net'>
+       <tuple id='orchard'>
+         <status>
+           <basic>open</basic>
+           <im:im>busy</im:im>
+         </status>
+       </tuple>
+     </presence>
+
+   XMPP <show/> element
+     <presence from='romeo@example.net/orchard'>
+       <show>dnd</show>
+     </presence>
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 23]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+5.2.11.  Note Element
+
+   A PIDF <tuple/> element may contain a <note/> child that provides a
+   user-defined, natural-language description of the sender's detailed
+   availability state.  The PIDF <note/> element maps to the XMPP
+   <status/> element.
+
+   Example: Note Element
+
+   PIDF <note/> element
+     <?xml version='1.0' encoding='UTF-8'?>
+     <presence xmlns='urn:ietf:params:xml:ns:pidf'
+               xmlns:im='urn:ietf:params:xml:ns:pidf:im'
+               entity='pres:romeo@example.net'>
+       <tuple id='orchard'>
+         <status>
+           <basic>open</basic>
+           <im:im>busy</im:im>
+         </status>
+         <note>Wooing Juliet</note>
+       </tuple>
+     </presence>
+
+   XMPP <status/> element
+     <presence from='romeo@example.net/orchard'>
+       <show>dnd</show>
+       <status>Wooing Juliet</status>
+     </presence>
+
+   A PIDF document with zero tuples MAY contain one or more <note/>
+   elements as direct children of the PIDF <presence/> element.  There
+   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
+   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
+   presence stanza (see Zero Resources (Section 6.3.2)).
+
+5.2.12.  Contact Element
+
+   A PIDF document may contain a <contact/> element specifying the URI
+   of an address at which the principal can be contacted (e.g., an im:,
+   tel:, or mailto: URI).  The core XMPP specification does not include
+   syntax for specifying the URI of a contact address, since the contact
+   address is implicit in the 'from' attribute of the XMPP presence
+   stanza.  Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM"
+   object with encapsulated PIDF object that contains a <contact/>
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 24]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   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
+
+   PIDF <contact/> element
+     <?xml version='1.0' encoding='UTF-8'?>
+     <presence xmlns='urn:ietf:params:xml:ns:pidf'
+               entity='pres:romeo@example.net'>
+       <tuple id='orchard'>
+         ...
+         <contact>im:romeo@example.net</contact>
+       </tuple>
+     </presence>
+
+   XMPP presence stanza
+     <presence from='romeo@example.net/orchard'/>
+
+5.2.13.  Presence Priority
+
+   The <contact/> child of the PIDF <tuple/> element MAY possess a
+   'priority' attribute whose value is a decimal number between zero and
+   one (with a maximum of three decimal places).  The value of this
+   attribute MAY be mapped to the <priority/> child element of an XMPP
+   presence stanza.  An XMPP-CPIM gateway MUST NOT map PIDF priority
+   values to negative values of the XMPP <priority/> element.  If an
+   XMPP-CPIM gateway maps these values, it SHOULD treat PIDF
+   priority='0' as XMPP <priority>0</priority> and PIDF priority='1' as
+   <priority>127</priority>, mapping intermediate values appropriately
+   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
+   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
+   only, and that the exact mapping shall be determined by the XMPP-CPIM
+   gateway).
+
+5.2.14.  Timestamp Element
+
+   The core XMPP specification does not include syntax for specifying
+   the datetime or timestamp at which a presence stanza was sent.
+   Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object
+   with encapsulated PIDF object that contains a <timestamp/> element,
+   it SHOULD NOT pass the XML character data of the <timestamp/> element
+   on to the XMPP recipient.
+
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 25]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+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
+   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
+   gateway's presence service.  Because [PIDF] does not specify syntax
+   for semantic operations such as subscribe, this section defines only
+   the XMPP interactions with the presence service offered by an
+   XMPP-CPIM gateway, not the translation of such XMPP syntax into PIDF.
+   (Note: Detailed information about XMPP presence services can be found
+   in [XMPP-IM]; as much as possible, an XMPP-CPIM gateway SHOULD
+   implement the syntax, semantics, and server business rules defined
+   therein.)
+
+6.1.  Requesting a Subscription
+
+   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
+   presence stanza of type "subscribe" to the target presentity.  The
+   syntax mapping is as follows:
+
+   o  The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
+      "watcher parameter" field (pres:user@host).  The XMPP-CPIM gateway
+      MUST append the "pres:" Presence URI scheme to the front of the
+      address.
+
+   o  The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
+      "target parameter" field (pres:user@host).  The XMPP-CPIM gateway
+      MUST append the "pres:" Presence URI scheme to the front of the
+      address.
+
+   o  There is no XMPP mapping for the CPP "duration parameter", since
+      XMPP subscriptions are active until they have been explicitly
+      "unsubscribed".
+
+   o  The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
+      field.
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 26]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   If the target presentity approves the subscription request (through
+   whatever protocol it uses to interact with the gateway), the
+   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
+   available presence.  Thereafter, until the subscription is cancelled,
+   the gateway MUST notify the subscribing XMPP entity every time the
+   target's presence information changes.
+
+   If the target presentity denies the subscription request, the
+   XMPP-CPIM gateway MUST return a presence stanza of type
+   "unsubscribed" to the XMPP entity and MUST NOT invoke the notify
+   operation.
+
+   In addition to the approval and denial cases, one of the following
+   exceptions may occur:
+
+   o  The target parameter (XMPP "to" address) does not refer to a valid
+      presentity; if this exception occurs, the XMPP-CPIM gateway MUST
+      return an <item-not-found/> stanza error to the XMPP entity.
+
+   o  Access control rules do not permit the entity to subscribe to the
+      target; if this exception occurs, the XMPP-CPIM gateway MUST
+      return a <forbidden/> stanza error to the XMPP entity.
+
+   o  There exists a pre-existing subscription or in-progress subscribe
+      operation between the XMPP entity and the target presentity; if
+      this exception occurs, the XMPP-CPIM gateway SHOULD return a
+      <conflict/> stanza error to the XMPP entity.
+
+   XMPP services assume that a subscription is active until it is
+   explicitly terminated.  However, non-XMPP services may implement
+   subscriptions of limited duration, which must be periodically
+   refreshed in order to mimic the permanence of XMPP subscriptions.
+   Therefore, an XMPP-to-CPIM gateway may need to send such refreshes to
+   the non-XMPP entity on behalf of the XMPP entity to that the
+   subscription does not expire.  Whether such refreshes are necessary
+   depends on the native protocol implemented by the CPIM-aware non-XMPP
+   service to which the gateway is translating.
+
+6.2.  Receiving a Subscription Request
+
+   If a non-XMPP presentity wants to subscribe to the presence
+   information of an XMPP entity through an XMPP-CPIM gateway, it MUST
+   use whatever protocol it uses to interact with the gateway in order
+   to request the subscription; subject to local access rules, 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
+   follows:
+
+
+
+Saint-Andre                 Standards Track                    [Page 27]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   o  The CPP "watcher parameter" field (pres:user@host) MUST be mapped
+      to the XMPP 'from' attribute (user@host).  The XMPP-CPIM gateway
+      MUST remove the "pres:" Presence URI scheme from the front of the
+      address.
+
+   o  The CPP "target parameter" field (pres:user@host) MUST be mapped
+      to the XMPP 'to' attribute (user@host).  The XMPP-CPIM gateway
+      MUST remove the "pres:" Presence URI scheme from the front of the
+      address.
+
+   o  There is no XMPP mapping for the CPP "duration parameter", since
+      XMPP subscriptions are active until they have been explicitly
+      "unsubscribed".
+
+   o  The CPP "TransID" field SHOULD be mapped to the XMPP 'id'
+      attribute.
+
+   If the target XMPP entity approves the subscription request, it MUST
+   send a presence stanza of type "subscribed" to the watcher
+   presentity.  The XMPP-CPIM gateway MUST then notify the watcher
+   presentity of the target XMPP entity's current available presence.
+   Thereafter, until the subscription is cancelled, the gateway MUST
+   notify the watcher presentity every time the target's presence
+   information changes.
+
+   If the target XMPP entity denies the subscription request, it MUST
+   send a presence stanza of type "unsubscribed" to the watcher
+   presentity.  The XMPP-CPIM gateway MUST NOT invoke the notify
+   operation.
+
+   In addition to the approval and denial cases, one of the following
+   exceptions MAY occur:
+
+   o  The target parameter (XMPP "to" address) does not refer to a valid
+      XMPP entity
+
+   o  Access control rules do not permit the watcher presentity to
+      subscribe to the target XMPP entity
+
+   o  There exists a pre-existing subscription or in-progress subscribe
+      operation between the watcher presentity and the target XMPP
+      entity
+
+   If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform
+   the watcher presentity of failure.
+
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 28]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   XMPP services assume that a subscription is active until it is
+   explicitly terminated.  With the exception of handling duration
+   parameters whose value is zero, handling duration parameters will be
+   highly dependent on the implementation and requirements of the
+   XMPP-CPIM gateway.  Since there are no explicit requirements for
+   supporting a "duration parameter" specified in either [IMP-MODEL] or
+   [IMP-REQS], duration parameter mapping is a local issue that falls
+   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.
+
+6.3.  The Notify Operation
+
+   An XMPP-CPIM gateway invokes the CPP "notify operation" whenever the
+   presence information associated with an XMPP entity or CPP presentity
+   changes and there are subscribers to that information on the other
+   side of the gateway.  The syntax mapping for presence information
+   related to a notify operation is defined under Mapping for Presence
+   (Section 5).
+
+6.3.1.  Multiple Resources
+
+   Semantically, PIDF contains the notion of multiple presence "tuples".
+   Normally, a PIDF document will contain at least one tuple but MAY
+   contain more than one tuple (or zero tuples, for which see next
+   section).  In the terminology of XMPP, each tuple would map to
+   presence information for a separate resource.  However, XMPP does not
+   include the ability to send presence information about more than one
+   resource at a time, since the resource that generates the presence
+   information is contained in the 'from' address of a presence stanza.
+   Therefore, an XMPP-CPIM gateway that acts as a presence service
+   SHOULD split a PIDF document that contains multiple tuples into
+   multiple XMPP presence stanzas, and SHOULD generate only one PIDF
+   document (with multiple tuples) if an XMPP user currently has
+   multiple connected resources.
+
+   In the interest of not multiplying XMPP stanzas beyond necessity, an
+   XMPP-CPIM gateway SHOULD generate an XMPP presence stanza only if the
+   presence information contained in a PIDF tuple communicates a change
+   in the availability status of the device or application associated
+   with that tuple ID.
+
+   In the interest of complying with the PIDF recommendation to provide
+   information about multiple "resources" in multiple tuples rather than
+   in multiple PIDF documents, an XMPP-CPIM gateway SHOULD include
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 29]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   information about all of an XMPP user's resources in one PIDF
+   document (with one tuple for each resource), even if the availability
+   status of only one resource has changed.
+
+6.3.2.  Zero Resources
+
+   A PIDF document may contain zero tuples.  For example:
+
+   PIDF Document with Zero Tuples
+
+     <presence entity='pres:juliet@example.com'
+               xmlns='urn:ietf:params:xml:ns:pidf'/>
+
+   Because (1) the 'entity' attribute of a PIDF <presence/> element maps
+   to the <user@host> portion of an XMPP address and (2) the 'id'
+   attribute of a PIDF <tuple/> element maps to the resource identifier
+   portion of an XMPP address, a PIDF document that contains zero tuples
+   would provide presence information about a <user@host> rather than a
+   <user@host/resource> when mapped to XMPP.  Although the notion of
+   presence notifications about a mere user rather than one of the
+   user's resources is nearly meaningless in the XMPP context, an
+   XMPP-CPIM gateway SHOULD map a PIDF document with zero tuples to an
+   XMPP presence stanza whose 'from' address is the user@host of the
+   non-XMPP entity.  However, an XMPP-CPIM gateway MUST NOT generate a
+   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).
+
+6.4.  Unsubscribing
+
+   If an XMPP entity wants to unsubscribe from the presence of a
+   non-XMPP presentity through an XMPP-CPIM gateway, it MUST send a
+   presence stanza of type "unsubscribe" to the target presentity.  The
+   syntax mapping is as follows:
+
+   o  The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
+      "watcher parameter" field (pres:user@host).  The XMPP-CPIM gateway
+      MUST append the "pres:" Presence URI scheme to the front of the
+      address.
+
+   o  The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
+      "target parameter" field (pres:user@host).  The XMPP-CPIM gateway
+      MUST append the "pres:" Presence URI scheme to the front of the
+      address.
+
+   o  The CPP "duration parameter" MUST be set to zero.
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 30]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   o  The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
+      field.
+
+   If the target parameter (XMPP "to" address) does not refer to a valid
+   presentity, the XMPP-CPIM gateway MUST return an <item-not-found/>
+   stanza error to the XMPP entity.
+
+   Upon receiving the presence stanza of type "unsubscribe" from the
+   XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
+   notifications to the XMPP entity.
+
+6.5.  Cancelling a Subscription
+
+   If an XMPP entity wants to cancel a non-XMPP presentity's
+   subscription to the entity's presence through an XMPP-CPIM gateway,
+   it MUST send a presence stanza of type "unsubscribed" to the target
+   presentity.  The syntax mapping is as follows:
+
+   o  The XMPP 'from' attribute (user@host) MUST be mapped to the CPP
+      "watcher parameter" field (pres:user@host).  The XMPP-CPIM gateway
+      MUST add the "pres:" Presence URI scheme to the front of the
+      address.
+
+   o  The XMPP 'to' attribute (user@host) MUST be mapped to the CPP
+      "target parameter" field (pres:user@host).  The XMPP-CPIM gateway
+      MUST add the "pres:" Presence URI scheme to the front of the
+      address.
+   o  The CPP "duration parameter" MUST be set to zero.
+
+   o  The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
+      field.
+
+   Upon receiving the presence stanza of type "unsubscribed" from the
+   XMPP entity, the XMPP-CPIM gateway MUST NOT send further presence
+   notifications to the watcher presentity.
+
+7.  Security Considerations
+
+   Detailed security considerations for instant messaging and presence
+   protocols are given in [IMP-REQS], specifically in Sections 5.1
+   through 5.4.
+
+   This document specifies methods for exchanging instant messages and
+   presence information through a gateway that implements [CPIM] and
+   [CPP].  Such a gateway MUST be compliant with the minimum security
+   requirements of the instant messaging and presence protocols with
+   which it interfaces.  The introduction of gateways to the security
+   model of instant messaging and presence in RFC 2779 also introduces
+
+
+
+Saint-Andre                 Standards Track                    [Page 31]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   some new risks.  In particular, end-to-end security properties
+   (especially confidentiality and integrity) between instant messaging
+   and presence user agents that interface through an XMPP-CPIM gateway
+   can be provided only if common formats are supported; these formats
+   are specified fully in [XMPP-E2E].
+
+8.  References
+
+8.1.  Normative References
+
+   [CPIM]       Peterson, J., "Common Profile for Instant Messaging
+                (CPIM)", RFC 3860, August 2004.
+
+   [CPP]        Peterson, J., "Common Profile for Presence (CPP)", RFC
+                3859, August 2004.
+
+   [IMP-MODEL]  Day, M., Rosenberg, J., and H. Sugano, "A Model for
+                Presence and Instant Messaging", RFC 2778, February
+                2000.
+
+   [IMP-REQS]   Day, M., Aggarwal, S., Mohr, G., and J. Vincent,
+                "Instant Messaging / Presence Protocol Requirements",
+                RFC 2779, February 2000.
+
+   [MIME]       Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+                Extensions (MIME) Part One: Format of Internet Message
+                Bodies", RFC 2045, November 1996.
+
+   [MSGFMT]     Klyne, G. and D. Atkins, "Common Presence and Instant
+                Messaging (CPIM): Message Format", RFC 3862, August
+                2004.
+
+   [PIDF]       Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
+                W., and J. Peterson, "Presence Information Data Format
+                (PIDF)", RFC 3863, August 2004.
+
+   [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
+                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.
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 32]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+   [US-ASCII]   Cerf, V., "ASCII format for network interchange", RFC
+                20, October 1969.
+
+   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", STD 63, RFC 3629, November 2003.
+
+   [XMPP-CORE]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
+                Protocol (XMPP): Core", RFC 3920, October 2004.
+
+   [XMPP-E2E]   Saint-Andre, P., Ed., "End-to-End Signing and Object
+                Encryption in the Extensible Messaging and Presence
+                Protocol (XMPP)", RFC 3923, October 2004.
+
+   [XMPP-IM]    Saint-Andre (ed.), P., "Extensible Messaging and
+                Presence Protocol (XMPP): Instant Messaging and
+                Presence", RFC 3921, October 2004.
+
+8.2.  Informative References
+
+   [RFC2822]    Resnick, P., Ed., "Internet Message Format", RFC 2822,
+                April 2001.
+
+   [MIMETYPES]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+                Extensions (MIME) Part Two: Media Types", RFC 2046,
+                November 1996.
+
+   [XMPP-PIDF]  Saint-Andre, P., "Transporting Presence Information
+                Data/Format (PIDF) over the Extensible Messaging and
+                Presence Protocol (XMPP)", Work in Progress, February
+                2004.
+
+Author's Address
+
+   Peter Saint-Andre
+   Jabber Software Foundation
+
+   EMail: stpeter@jabber.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 33]
+
+RFC 3922                      XMPP to CPIM                  October 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Saint-Andre                 Standards Track                    [Page 34]
+