Movatterモバイル変換
[0]ホーム
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 Mapping3.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 stanzas) or 'pres:' scheme (for XMPP 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 address4. 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 theSaint-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 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. 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 ... CPIM 'From' header From: Juliet Capulet4.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 or. 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 ... CPIM 'To' header To: Romeo Montague4.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 child element to specify the conversation thread in which the message is situated. There is no mapping of an XMPP 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 child element, the gateway SHOULD ignore the value provided.4.1.6. Message Subject An XMPP message stanza MAY include a child element. If included, it maps to the 'Subject' header of a "Message/CPIM" object. To map the XMPP element to the 'Subject' header of a "Message/CPIM" object, the gateway SHOULD simply map the XML character data of the XMPP element to the value of theSaint-Andre Standards Track [Page 7] RFC 3922 XMPP to CPIM October 2004 'Subject' header. The 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 elementHi!Ahoj! CPIM 'Subject' header Subject: Hi! Subject:;lang=cz Ahoj!4.1.7. Message Body The child element of an XMPP message stanza is used to provide the primary meaning of the message. The XML character data of the XMPP element maps to the encapsulated text message content. Example: Message Body XMPP message Wherefore art thou, Romeo? 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 20044.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 XMPP 'from' attribute ...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 CPIMSaint-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 XMPP 'to' attribute ...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 child element of an XMPP message stanza. To map the CPIM 'Subject' header to the XMPP element, the gateway SHOULD simply map the value of the 'Subject' header to the XML character data of the XMPP 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 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 elementHi!Ahoj!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) ...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 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 Wherefore art thou?
[8]ページ先頭