{"@attributes":{"ipr":"full3978","number":"3922","category":"std","docName":"RFC 3922"},"front":{"title":"Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)","author":{"@attributes":{"initials":"P.","surname":"Saint-Andre","fullname":"Peter Saint-Andre"},"organization":"Jabber Software Foundation","address":{"email":"stpeter@jabber.org"}},"date":{"@attributes":{"year":"2004","month":"October"}},"area":"Applications","workgroup":"XMPP Working Group","keyword":["RFC","Request for Comments","I-D","Internet-Draft","XMPP","Extensible Messaging and Presence Protocol","Jabber","IM","Instant Messaging","Presence","CPIM","Common Presence and Instant Messaging","XML","Extensible Markup Language"],"abstract":{"t":"This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications."}},"middle":{"section":[{"@attributes":{"title":"Introduction","anchor":"intro"},"section":[{"@attributes":{"title":"Overview","anchor":"intro-overview"},"t":["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 .  This framework is commonly called Common Presence and Instant Messaging or \"CPIM\".  The CPIM family of specifications include a  (also called CPIM), a , a , and a .  (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 (, ) 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 .  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:","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 ."],"figure":{"artwork":{}}},{"@attributes":{"title":"Terminology","anchor":"intro-terminology"},"t":["This memo inherits vocabulary defined in .  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 .  Terms such as ENTITY, NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE IDENTIFIER, MESSAGE STANZA, and PRESENCE STANZA are used in the same meaning as defined therein."]},{"@attributes":{"title":"Conventions Used in this Document","anchor":"intro-conventions"},"t":"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 ."}]},{"@attributes":{"title":"Approach","anchor":"approach"},"t":["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 ; instead,  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  content-types: \"Message\/CPIM\" for messages () and \"application\/pidf+xml\" for presence ().  The syntax of \"Message\/CPIM\" objects is similar to but stricter than that defined in , and provides the ability to include arbitrary .  By contrast, each \"application\/pidf+xml\" object is a complete XML document whose structure is defined by an XML schema.","The approach taken herein is to specify mappings from XMPP elements and attributes to the headers and MIME formats defined by  and  in order to comply with the semantics defined by  and .  Naturally, mappings in the opposite direction are provided as well."]},{"@attributes":{"title":"Address Mapping","anchor":"addr"},"section":[{"@attributes":{"title":"Overview","anchor":"addr-overview"},"t":["Address mapping may be required since the address formats used to identify XMPP entities (specified in ) are different from those used to identify instant inboxes (the im: URI scheme specified in ) and presentities (the pres: URI scheme specified in ).  In particular, different characters are allowed in im: and pres: URIs than are allowed in XMPP addresses:",{"list":{"@attributes":{"style":"symbols"},"t":["The following  characters are allowed in im:\/pres: URIs but not in XMPP addresses: #26; (&), #27; ('), and #2f; (\/).","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)."]},{"@attributes":{"title":"XMPP to CPIM","anchor":"addr-xmpp"},"t":["The following is a high-level algorithm for mapping an XMPP address to an im: or pres: URI:",{"list":{"@attributes":{"style":"numbers"},"t":["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)","Apply Nodeprep profile of  (as specified in ) for canonicalization (OPTIONAL)","Translate #26; to &, #27; to ', and #2f; to \/ respectively","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 ","Combine resulting local-part with mapped hostname to form local@domain address","Prepend with 'im:' scheme (for XMPP <message\/> stanzas) or 'pres:' scheme (for XMPP <presence\/> stanzas)"]}}]},{"@attributes":{"title":"CPIM to XMPP","anchor":"addr-cpim"},"t":["The following is a high-level algorithm for mapping an im: or pres: URI to an XMPP address:",{"list":{"@attributes":{"style":"numbers"},"t":["Remove URI scheme","Split at the first '@' character into local-part and hostname (mapping the latter is out of scope)","Translate %hexhex to equivalent octets as described in Section 2.2.5 of ","Treat result as a UTF-8 string","Translate & to #26;, ' to #27;, and \/ to #2f respectively","Apply Nodeprep profile of  (as specified in ) for canonicalization (OPTIONAL)","Recombine local-part with mapped hostname to form local@domain address"]}}]}]},{"@attributes":{"title":"Syntax Mapping of Instant Messages","anchor":"im"},"t":"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 .","section":[{"@attributes":{"title":"Message Syntax Mapping from XMPP to CPIM Specifications","anchor":"im-syntax-xmpp"},"t":["This section defines the mapping of syntax primitives from XMPP message stanzas to \"Message\/CPIM\" objects with encapsulated text content.","Note: As specified in , the default Content-type of a MIME object is \"Content-type: text\/plain; charset=us-ascii\".  Because XMPP uses the  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\"."],"section":[{"@attributes":{"title":"From Address","anchor":"im-syntax-xmpp-from"},"t":"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 .  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).","figure":{"preamble":"Example: From Address Mapping","artwork":{}}},{"@attributes":{"title":"To Address","anchor":"im-syntax-xmpp-to"},"t":"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).","figure":{"preamble":"Example: To Address Mapping","artwork":{}}},{"@attributes":{"title":"Stanza ID","anchor":"im-syntax-xmpp-id"},"t":"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."},{"@attributes":{"title":"Message Type","anchor":"im-syntax-xmpp-type"},"t":"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."},{"@attributes":{"title":"Message Thread","anchor":"im-syntax-xmpp-thread"},"t":"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."},{"@attributes":{"title":"Message Subject","anchor":"im-syntax-xmpp-subject"},"t":"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 '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.","figure":{"preamble":"Example: Subject Mapping","artwork":{}}},{"@attributes":{"title":"Message Body","anchor":"im-syntax-xmpp-body"},"t":"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.","figure":{"preamble":"Example: Message Body","artwork":{}}},{"@attributes":{"title":"Message Extensions","anchor":"im-syntax-xmpp-extensions"},"t":"As defined in , 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 , 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."},{"@attributes":{"title":"Gateway-Generated CPIM Syntax","anchor":"im-syntax-xmpp-gen"},"t":["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:",{"list":{"@attributes":{"style":"symbols"},"t":["cc -- specifies the address of an entity that is to receive a \"courtesy copy\" of the message (i.e., a non-primary addressee)","DateTime -- specifies the datetime at which the message was sent","NS -- specifies the namespace of a feature extension","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."]}]},{"@attributes":{"title":"Message Syntax Mapping from CPIM Specifications to XMPP","anchor":"im-syntax-cpim"},"t":"This section defines the mapping of syntax primitives from \"Message\/CPIM\" objects with encapsualted text content to XMPP message stanzas.","section":[{"@attributes":{"title":"From Address","anchor":"im-syntax-cpim-from"},"t":"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).","figure":{"preamble":"Example: From Address Mapping","artwork":{}}},{"@attributes":{"title":"To Address","anchor":"im-syntax-cpim-to"},"t":"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 \"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.","figure":{"preamble":"Example: To Address Mapping","artwork":{}}},{"@attributes":{"title":"Courtesy Copy","anchor":"im-syntax-cpim-cc"},"t":"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."},{"@attributes":{"title":"DateTime Header","anchor":"im-syntax-cpim-datetime"},"t":"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."},{"@attributes":{"title":"Message Subject","anchor":"im-syntax-cpim-subject"},"t":"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.","figure":{"preamble":"Example: Subject Mapping","artwork":{}}},{"@attributes":{"title":"Header Extensions","anchor":"im-syntax-cpim-header"},"t":"\"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."},{"@attributes":{"title":"Require Header","anchor":"im-syntax-cpim-require"},"t":"\"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."},{"@attributes":{"title":"MIME Content-ID","anchor":"im-syntax-cpim-contentid"},"t":"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 .  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.","figure":{"preamble":"Example: Content-ID for Encapsulated Object","artwork":{}}},{"@attributes":{"title":"Message Body","anchor":"im-syntax-cpim-body"},"t":["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.","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 , 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."],"figure":{"preamble":"Example: Message Body","artwork":{}}},{"@attributes":{"title":"Gateway-Generated XMPP Syntax","anchor":"im-syntax-cpim-gen"},"t":"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."}]}]},{"@attributes":{"title":"Syntax Mapping of Presence Information","anchor":"pres"},"t":"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  object in order to comply with the presence semantics defined by .","section":[{"@attributes":{"title":"Presence Syntax Mapping from XMPP to CPIM Specifications","anchor":"pres-syntax-xmpp"},"t":["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 , the default Content-type of a MIME object is \"Content-type: text\/plain; charset=us-ascii\".  Because XMPP uses the  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\"."],"section":[{"@attributes":{"title":"From Address","anchor":"pres-syntax-xmpp-from"},"t":["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 .  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).","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.","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."],"figure":[{"preamble":"Example: From Address Mapping","artwork":{}},{"preamble":"Example: From Address Mapping (PIDF)","artwork":{}},{"preamble":"Example: Resource Identifier Mapping","artwork":{}}]},{"@attributes":{"title":"To Address","anchor":"pres-syntax-xmpp-to"},"t":"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 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).","figure":{"preamble":"Example: To Address Mapping","artwork":{}}},{"@attributes":{"title":"Stanza ID","anchor":"pres-syntax-xmpp-id"},"t":"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."},{"@attributes":{"title":"Presence Type","anchor":"pres-syntax-xmpp-type"},"t":"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  \"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 .","figure":[{"preamble":"Example: Available Presence","artwork":{}},{"preamble":"Example: Unavailable Presence","artwork":{}}]},{"@attributes":{"title":"Show Element","anchor":"pres-syntax-xmpp-show"},"t":"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.","figure":{"preamble":"Example: Show Element","artwork":{}}},{"@attributes":{"title":"Status Element","anchor":"pres-syntax-xmpp-status"},"t":"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.","figure":{"preamble":"Example: Status Element","artwork":{}}},{"@attributes":{"title":"Presence Priority","anchor":"pres-syntax-xmpp-priority"},"t":"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 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).","figure":{"preamble":"Example: Presence Priority","artwork":{}}},{"@attributes":{"title":"Presence Extensions","anchor":"pres-syntax-xmpp-extensions"},"t":"As defined in , 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 , 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."},{"@attributes":{"title":"Gateway-Generated CPIM and PIDF Syntax","anchor":"pres-syntax-xmpp-gen"},"section":[{"@attributes":{"title":"CPIM Message Headers","anchor":"pres-syntax-xmpp-gen-cpim"},"t":["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:",{"list":{"@attributes":{"style":"symbols"},"t":["cc -- specifies the address of an entity that is to receive a \"courtesy copy\" of the presence information (i.e., a non-primary addressee)","DateTime -- specifies the datetime at which the presence information was sent","NS -- specifies the namespace of a feature extension","Subject -- specifies the subject or topic of the encapsulated \"Message\/CPIM\" object","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."]},{"@attributes":{"title":"PIDF Elements","anchor":"pres-syntax-xmpp-gen-pidf"},"t":["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:",{"list":{"@attributes":{"style":"symbols"},"t":["<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.","<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."]}}]}]}]},{"@attributes":{"title":"Presence Syntax Mapping from CPIM Specifications to XMPP","anchor":"pres-syntax-cpim"},"t":["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 )."],"section":[{"@attributes":{"title":"From Address","anchor":"pres-syntax-cpim-from"},"t":"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 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.","figure":[{"preamble":"Example: From Address Mapping","artwork":{}},{"preamble":"Example: Resource Identifier Mapping","artwork":{}}]},{"@attributes":{"title":"To Address","anchor":"pres-syntax-cpim-to"},"t":"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.","figure":{"preamble":"Example: To Address Mapping","artwork":{}}},{"@attributes":{"title":"Courtesy Copy","anchor":"pres-syntax-cpim-cc"},"t":"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."},{"@attributes":{"title":"DateTime Header","anchor":"pres-syntax-cpim-datetime"},"t":"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."},{"@attributes":{"title":"Subject Header","anchor":"pres-syntax-cpim-subject"},"t":"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."},{"@attributes":{"title":"Header Extensions","anchor":"pres-syntax-cpim-header"},"t":"\"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."},{"@attributes":{"title":"Require Header","anchor":"pres-syntax-cpim-require"},"t":"\"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."},{"@attributes":{"title":"MIME Content-ID","anchor":"pres-syntax-cpim-contentid"},"t":"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 .  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.","figure":{"preamble":"Example: Content-ID for Encapsulated Object","artwork":{}}},{"@attributes":{"title":"Basic Presence Status","anchor":"pres-syntax-cpim-basic"},"t":"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\".","figure":[{"preamble":"Example: OPEN Presence","artwork":{}},{"preamble":"Example: CLOSED Presence","artwork":{}}]},{"@attributes":{"title":"Extended Status Information","anchor":"pres-syntax-cpim-ext"},"t":"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.","figure":{"preamble":"Example: Extended Status Information (provisional)","artwork":{}}},{"@attributes":{"title":"Note Element","anchor":"pres-syntax-cpim-note"},"t":["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.","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 )."],"figure":{"preamble":"Example: Note Element","artwork":{}}},{"@attributes":{"title":"Contact Element","anchor":"pres-syntax-cpim-contact"},"t":"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\/> element, it SHOULD NOT pass the XML character data of the <contact\/> element on to the XMPP recipient.  (However, see  below.)","figure":{"preamble":"Example: PIDF Contact Element","artwork":{}}},{"@attributes":{"title":"Presence Priority","anchor":"pres-syntax-cpim-priority"},"t":"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)."},{"@attributes":{"title":"Timestamp Element","anchor":"pres-syntax-cpim-timestamp"},"t":"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."},{"@attributes":{"title":"Inclusion of Complete PIDF Document","anchor":"pres-syntax-cpim-include"},"t":"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 .  If an XMPP client does not understand this extended data, it naturally MUST ignore it."}]}]},{"@attributes":{"title":"XMPP-CPIM Gateway as Presence Service","anchor":"service"},"t":{"xref":[{"@attributes":{"target":"CPP"}},{"@attributes":{"target":"PIDF"}},{"@attributes":{"target":"XMPP-IM"}}]},"section":[{"@attributes":{"title":"Requesting a Subscription","anchor":"service-request"},"t":["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:",{"list":{"@attributes":{"style":"symbols"},"t":["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.","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.","There is no XMPP mapping for the CPP \"duration parameter\", since XMPP subscriptions are active until they have been explicitly \"unsubscribed\".","The XMPP 'id' attribute SHOULD be mapped to the CPP \"TransID\" field."]}},"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:",{"list":{"@attributes":{"style":"symbols"},"t":["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.","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.","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."]},{"@attributes":{"title":"Receiving a Subscription Request","anchor":"service-receive"},"t":["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:",{"list":{"@attributes":{"style":"symbols"},"t":["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.","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.","There is no XMPP mapping for the CPP \"duration parameter\", since XMPP subscriptions are active until they have been explicitly \"unsubscribed\".","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:",{"list":{"@attributes":{"style":"symbols"},"t":["The target parameter (XMPP \"to\" address) does not refer to a valid XMPP entity","Access control rules do not permit the watcher presentity to subscribe to the target XMPP entity","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.","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  or , 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."]},{"@attributes":{"title":"The Notify Operation","anchor":"service-notify"},"t":"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 .","section":[{"@attributes":{"title":"Multiple Resources","anchor":"service-notify-multiple"},"t":["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 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."]},{"@attributes":{"title":"Zero Resources","anchor":"service-notify-zero"},"t":["A PIDF document may contain zero tuples.  For example:","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)."],"figure":{"preamble":"PIDF Document with Zero Tuples","artwork":{}}}]},{"@attributes":{"title":"Unsubscribing","anchor":"service-unsubscribe"},"t":["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:",{"list":{"@attributes":{"style":"symbols"},"t":["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.","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.","The CPP \"duration parameter\" MUST be set to zero.","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."]},{"@attributes":{"title":"Cancelling a Subscription","anchor":"service-cancel"},"t":["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:",{"list":{"@attributes":{"style":"symbols"},"t":["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.","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.","The CPP \"duration parameter\" MUST be set to zero.","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."]}]},{"@attributes":{"title":"Security Considerations","anchor":"security"},"t":["Detailed security considerations for instant messaging and presence protocols are given in , specifically in Sections 5.1 through 5.4.","This document specifies methods for exchanging instant messages and presence information through a gateway that implements  and .  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 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 ."]}]},"back":{"references":[{"@attributes":{"title":"Normative References"},"reference":[{"@attributes":{"anchor":"CPIM"},"front":{"title":"Common Profile for Instant Messaging (CPIM)","author":{"@attributes":{"initials":"J.","surname":"Peterson","fullname":"J. Peterson"},"organization":{}},"date":{"@attributes":{"year":"2004","month":"August"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"3860"}},"format":{"@attributes":{"type":"TXT","octets":"26486","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc3860.txt"}}},{"@attributes":{"anchor":"CPP"},"front":{"title":"Common Profile for Presence (CPP)","author":{"@attributes":{"initials":"J.","surname":"Peterson","fullname":"J. Peterson"},"organization":{}},"date":{"@attributes":{"year":"2004","month":"August"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"3859"}},"format":{"@attributes":{"type":"TXT","octets":"30537","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc3859.txt"}}},{"@attributes":{"anchor":"IMP-MODEL","target":"http:\/\/www.ietf.org\/rfc\/rfc2778.txt"},"front":{"title":"A Model for Presence and Instant Messaging","author":[{"@attributes":{"initials":"M.","surname":"Day","fullname":"Mark Day"},"organization":"SightPath, Inc.","address":{"email":"mday@alum.mit.edu"}},{"@attributes":{"initials":"J.","surname":"Rosenberg","fullname":"Jonathan Rosenberg"},"organization":"dynamicsoft","address":{"email":"jdrosen@dynamicsoft.com"}},{"@attributes":{"initials":"H.","surname":"Sugano","fullname":"Hiroyasu Sugano"},"organization":"Fujitsu Laboratories Ltd.","address":{"email":"suga@flab.fujitsu.co.jp"}}],"date":{"@attributes":{"month":"February","year":"2000"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"2778"}}},{"@attributes":{"anchor":"IMP-REQS"},"front":{"title":"Instant Messaging \/ Presence Protocol Requirements","author":[{"@attributes":{"initials":"M.","surname":"Day","fullname":"Mark Day"},"organization":"SightPath, Inc.","address":{"postal":{"street":"135 Beaver Street","city":"Waltham","region":"MA","code":"02452","country":"US"},"phone":{},"email":"mday@alum.mit.edu"}},{"@attributes":{"initials":"S.","surname":"Aggarwal","fullname":"Sonu Aggarwal"},"organization":"Microsoft Corporation","address":{"postal":{"street":"One Microsoft Way","city":"Redmond","region":"WA","code":"98052","country":"US"},"phone":{},"email":"sonuag@microsoft.com"}},{"@attributes":{"initials":"J.","surname":"Vincent","fullname":"Jesse Vincent"},"organization":"Into Networks, Inc.","address":{"postal":{"street":"150 Cambridgepark Drive","city":"Cambridge","region":"MA","code":"02140","country":"US"},"phone":{},"email":"jesse@intonet.com"}}],"date":{"@attributes":{"month":"February","year":"2000"}},"abstract":{"t":["Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet.  Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g.  \"online\" or \"offline\") of other users.  Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.","Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors.  The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and\/or   presence can interoperate across the Internet.  This document defines a minimal set of requirements that IMPP must meet."]}},"seriesInfo":{"@attributes":{"name":"RFC","value":"2779"}}},{"@attributes":{"anchor":"MIME"},"front":{"title":"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies","author":[{"@attributes":{"initials":"N.","surname":"Freed","fullname":"Ned Freed"},"organization":"Innosoft International, Inc.","address":{"postal":{"street":"1050 East Garvey Avenue South","city":"West Covina","region":"CA","code":"91790","country":"US"},"phone":"+1 818 919 3600","facsimile":"+1 818 919 3614","email":"ned@innosoft.com"}},{"@attributes":{"initials":"N.S.","surname":"Borenstein","fullname":"Nathaniel S.  Borenstein"},"organization":"First Virtual Holdings","address":{"postal":{"street":"25 Washington Avenue","city":"Morristown","region":"NJ","code":"07960","country":"US"},"phone":"+1 201 540 8967","facsimile":"+1 201 993 3032","email":"nsb@nsb.fv.com"}}],"date":{"@attributes":{"month":"November","year":"1996"}},"abstract":{"t":["STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text.  This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for","(1)   textual message bodies in character sets other than US-ASCII,","(2)   an extensible set of different formats for non-textual message bodies,","(3)   multi-part message bodies, and","(4)   textual header information in character sets other than US-ASCII.","These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them.  Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.","This initial document specifies the various headers used to describe the structure of MIME messages.  The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types.  The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields.  The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities.  The fifth and final document, RFC 2049, describes MIME conformance\n  criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.","These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342.  An appendix in RFC 2049 describes differences and changes from previous versions."]}},"seriesInfo":{"@attributes":{"name":"RFC","value":"2045"}}},{"@attributes":{"anchor":"MSGFMT"},"front":{"title":"Common Presence and Instant Messaging (CPIM): Message Format","author":[{"@attributes":{"initials":"G.","surname":"Klyne","fullname":"G. Klyne"},"organization":{}},{"@attributes":{"initials":"D.","surname":"Atkins","fullname":"D. Atkins"},"organization":{}}],"date":{"@attributes":{"year":"2004","month":"August"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"3862"}},"format":{"@attributes":{"type":"TXT","octets":"56133","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc3862.txt"}}},{"@attributes":{"anchor":"PIDF"},"front":{"title":"Presence Information Data Format (PIDF)","author":[{"@attributes":{"initials":"H.","surname":"Sugano","fullname":"H. Sugano"},"organization":{}},{"@attributes":{"initials":"S.","surname":"Fujimoto","fullname":"S. Fujimoto"},"organization":{}},{"@attributes":{"initials":"G.","surname":"Klyne","fullname":"G. Klyne"},"organization":{}},{"@attributes":{"initials":"A.","surname":"Bateman","fullname":"A. Bateman"},"organization":{}},{"@attributes":{"initials":"W.","surname":"Carr","fullname":"W. Carr"},"organization":{}},{"@attributes":{"initials":"J.","surname":"Peterson","fullname":"J. Peterson"},"organization":{}}],"date":{"@attributes":{"year":"2004","month":"August"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"3863"}},"format":{"@attributes":{"type":"TXT","octets":"56956","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc3863.txt"}}},{"@attributes":{"anchor":"STRINGPREP"},"front":{"title":"Preparation of Internationalized Strings (\"stringprep\")","author":[{"@attributes":{"initials":"P.","surname":"Hoffman","fullname":"P.  Hoffman"},"organization":{}},{"@attributes":{"initials":"M.","surname":"Blanchet","fullname":"M.  Blanchet"},"organization":{}}],"date":{"@attributes":{"month":"December","year":"2002"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"3454"}},"format":{"@attributes":{"type":"TXT","octets":"138684","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc3454.txt"}}},{"@attributes":{"anchor":"TERMS"},"front":{"title":"Key words for use in RFCs to Indicate Requirement Levels","author":{"@attributes":{"initials":"S.","surname":"Bradner","fullname":"Scott Bradner"},"organization":"Harvard University","address":{"postal":{"street":["1350 Mass.  Ave.","Cambridge","MA 02138"]},"phone":"- +1 617 495 3864","email":"-"}},"date":{"@attributes":{"month":"March","year":"1997"}},"area":"General","keyword":"keyword","abstract":{"t":["In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  Authors who follow these guidelines should incorporate this phrase near the beginning of their document: \n              \n            ","Note that the force of these words is modified by the requirement level of the document in which they are used."]}},"seriesInfo":[{"@attributes":{"name":"BCP","value":"14"}},{"@attributes":{"name":"RFC","value":"2119"}}]},{"@attributes":{"anchor":"URL-GUIDE"},"front":{"title":"Guidelines for new URL Schemes","author":[{"@attributes":{"initials":"L.","surname":"Masinter","fullname":"Larry Masinter"},"organization":"Xerox Corporation, Palo Alto Research Center","address":{"postal":{"street":"3333 Coyote Hill Road","city":"Palo Alto","region":"CA","code":"94304","country":"US"},"email":"masinter@parc.xerox.com"}},{"@attributes":{"initials":"H.","surname":"Alvestrand","fullname":"Harald Tveit Alvestrand"},"organization":"Maxware","address":{"postal":{"street":"N-7005 Trondheim","city":"Pirsenteret","region":{},"code":{},"country":"NO"},"phone":"+47 73 545700","email":"harald.alvestrand@maxware.no"}},{"@attributes":{"initials":"D.","surname":"Zigmond","fullname":"Dan Zigmond"},"organization":"WebTV Networks, Inc.","address":{"postal":{"street":"305 Lytton Avenue","city":"Palo Alto","region":"CA","code":"94301","country":"US"},"phone":"+1 650 614 6071","email":"djz@corp.webtv.net"}},{"@attributes":{"initials":"R.","surname":"Petke","fullname":"Rich Petke"},"organization":"UUNET Technologies","address":{"postal":{"street":["5000 Britton Road","P. O. Box 5000"],"city":"Hilliard","region":"OH","code":"43026-5000","country":"US"},"phone":"+1 614 723 4157","facsimile":"+1 614 723 8407","email":"rpetke@wcom.net"}}],"date":{"@attributes":{"month":"November","year":"1999"}},"abstract":{"t":"A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. This document provides guidelines for the definition of new URL schemes."}},"seriesInfo":{"@attributes":{"name":"RFC","value":"2718"}},"format":{"@attributes":{"type":"TXT","octets":"19208","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc2718.txt"}}},{"@attributes":{"anchor":"US-ASCII"},"front":{"title":"ASCII format for network interchange","author":{"@attributes":{"initials":"V.","surname":"Cerf","fullname":"Vint Cerf"},"organization":"University California Los Angeles (UCLA)"},"date":{"@attributes":{"month":"October","day":"16","year":"1969"}},"abstract":{"t":"For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0."}},"seriesInfo":{"@attributes":{"name":"RFC","value":"20"}},"format":{"@attributes":{"type":"TXT","octets":"18504","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc20.txt"}}},{"@attributes":{"anchor":"UTF-8"},"front":{"title":"UTF-8, a transformation format of ISO 10646","author":{"@attributes":{"initials":"F.","surname":"Yergeau","fullname":"F. Yergeau"},"organization":{}},"date":{"@attributes":{"month":"November","year":"2003"}}},"seriesInfo":[{"@attributes":{"name":"STD","value":"63"}},{"@attributes":{"name":"RFC","value":"3629"}}],"format":{"@attributes":{"type":"TXT","octets":"33856","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc3629.txt"}}},{"@attributes":{"anchor":"XMPP-CORE"},"front":{"title":"Extensible Messaging and Presence Protocol (XMPP): Core","author":{"@attributes":{"initials":"P.","surname":"Saint-Andre","fullname":"P. Saint-Andre"},"organization":"Jabber Software Foundation"},"date":{"@attributes":{"year":"2004","month":"October"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"3920"}},"format":{"@attributes":{"type":"TXT","octets":"194313","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc3920.txt"}}},{"@attributes":{"anchor":"XMPP-E2E"},"front":{"title":"End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)","author":{"@attributes":{"initials":"P.","surname":"Saint-Andre","fullname":"P. Saint-Andre"},"organization":"Jabber Software Foundation"},"date":{"@attributes":{"year":"2004","month":"October"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"3923"}},"format":{"@attributes":{"type":"TXT","octets":"51828","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc3923.txt"}}},{"@attributes":{"anchor":"XMPP-IM"},"front":{"title":"Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence","author":{"@attributes":{"initials":"P.","surname":"Saint-Andre","fullname":"P. Saint-Andre"},"organization":"Jabber Software Foundation"},"date":{"@attributes":{"year":"2004","month":"October"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"3921"}},"format":{"@attributes":{"type":"TXT","octets":"217527","target":"ftp:\/\/ftp.isi.edu\/in-notes\/rfc3921.txt"}}}]},{"@attributes":{"title":"Informative References"},"reference":[{"@attributes":{"anchor":"RFC2822"},"front":{"title":"Internet Message Format","author":{"@attributes":{"initials":"P.","surname":"Resnick","fullname":"P.  Resnick"},"organization":{}},"date":{"@attributes":{"month":"April","year":"2001"}}},"seriesInfo":{"@attributes":{"name":"RFC","value":"2822"}}},{"@attributes":{"anchor":"MIMETYPES"},"front":{"title":"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types","author":[{"@attributes":{"initials":"N.","surname":"Freed","fullname":"Ned Freed"},"organization":"Innosoft International, Inc.","address":{"postal":{"street":"1050 East Garvey Avenue South","city":"West Covina","region":"CA","code":"91790","country":"US"},"phone":"+1 818 919 3600","facsimile":"+1 818 919 3614","email":"ned@innosoft.com"}},{"@attributes":{"initials":"N.","surname":"Borenstein","fullname":"Nathaniel S.  Borenstein"},"organization":"First Virtual Holdings","address":{"postal":{"street":"25 Washington Avenue","city":"Morristown","region":"NJ","code":"07960","country":"US"},"phone":"+1 201 540 8967","facsimile":"+1 201 993 3032","email":"nsb@nsb.fv.com"}}],"date":{"@attributes":{"month":"November","year":"1996"}},"abstract":{"t":["STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text.  This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for","(1)   textual message bodies in character sets other than US-ASCII,","(2)   an extensible set of different formats for non-textual message bodies,","(3)   multi-part message bodies, and","(4)   textual header information in character sets other than US-ASCII.","These documents are based on earlier work documented in RFC 934, STD 11 and RFC 1049, but extends and revises them.  Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.","The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages.  This second document defines the general structure of the MIME media typing sytem and defines an initial set of media types.  The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields.  The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities.  The fifth and final document, RFC 2049, describes MIME\n   conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.","These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342.  An appendix in RFC 2049 describes differences and changes from previous versions."]}},"seriesInfo":{"@attributes":{"name":"RFC","value":"2046"}}},{"@attributes":{"anchor":"XMPP-PIDF"},"front":{"title":"Transporting Presence Information Data Format (PIDF) over the Extensible Messaging and Presence Protocol (XMPP)","author":{"@attributes":{"initials":"P.","surname":"Saint-Andre","fullname":"P. Saint-Andre"},"organization":"Jabber Software Foundation"},"date":{"@attributes":{"month":"February","year":"2004"}}},"seriesInfo":{"@attributes":{"name":"Internet-Draft","value":"draft-saintandre-xmpp-pidf-00"}},"format":{"@attributes":{"type":"TXT","target":"http:\/\/www.ietf.org\/internet-drafts\/draft-saintandre-xmpp-pidf-00.txt"}}}]}]}}