RFC3922 日本語訳
3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) toCommon Presence and Instant Messaging (CPIM). P. Saint-Andre. October 2004. (Format: TXT=70790 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Saint-Andre Request for Comments: 3922 Jabber Software Foundation Category: Standards Track October 2004
コメントを求めるワーキンググループP.サンアンドレ要求をネットワークでつないでください: 3922年のおしゃべりソフトウェア財団カテゴリ: 標準化過程2004年10月
Mapping the Extensible Messaging and Presence Protocol (XMPP) to
Common Presence and Instant Messaging (CPIM)
広げることができるメッセージングと存在プロトコル(XMPP)を一般的な存在とインスタントメッセージングに写像します。(CPIM)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications.
このメモはExtensible Messagingと、Presenceプロトコル(XMPP)とCommon PresenceとInstant Messaging(CPIM)仕様の間のマッピングについて説明します。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 .3 3にアプローチしてください。 マッピング. . . . . . . . . . . . . . . . . . . . . . . 4 4を扱ってください。 インスタントメッセージ. . . . . . . . . . . . . . 5 5に関する構文マッピング。 存在情報. . . . . . . . . . . . 13 6に関する構文マッピング。 存在サービス. . . . . . . . . . . . 26 7としてのXMPP-CPIMゲートウェイ。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 31 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 32作者のアドレスの.33の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 34
Saint-Andre Standards Track [Page 1] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[1ページ]。
1. Introduction
1. 序論
1.1. Overview
1.1. 概要
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".)
Instant MessagingとPresence(IMPP)作業部会はインスタントメッセージング(IM)の中の相互運用性と[IMP-REQS]と共に対応である存在システムのために抽象的なフレームワークを定義しました。 このフレームワークは一般的にCommon PresenceとInstant Messagingか"CPIM"と呼ばれます。 仕様のCPIMファミリーはInstant Messaging[CPIM]のためのCommon Profile(また、CPIMと呼ばれる)、PresenceのためのCommon Profile[CPP]、CPIM Message Format[MSGFMT]、およびCommon Presence情報Data Format[PIDF]を入れます。 (注意: 混乱、Common Presence、およびInstant Messagingを防ぐのはここに「CPIM仕様」にまとめて言及されますが、Instant MessagingのためのCommon Profileは"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:
このメモはどのようにのExtensible MessagingとPresenceプロトコル[XMPP-CORE]について説明するか、CPIM仕様に含まれた抽象モデルへの[XMPP-IM)地図、主にXMPPサービスと[IMP-REQS]に従う非XMPPサービスの間のゲートウェイを設立する目的のために。 ここに「XMPP-CPIMゲートウェイ」と呼ばれたそのようなゲートウェイは、1つのサービスのプロトコルを解釈して、もう片方のサービスのプロトコルにそれらを翻訳するために設立されるかもしれません。 私たちは以下のこの関係を想像できます:
+-------------+ +-------------+ +------------+
| | | | | |
| XMPP | | XMPP-CPIM | | Non-XMPP |
| Service | <----> | Gateway | <----> | Service |
| | | | | |
+-------------+ +-------------+ +------------+
+-------------+ +-------------+ +------------+ | | | | | | | XMPP| | XMPP-CPIM| | 非XMPP| | サービス| <、-、-、--、>| ゲートウェイ| <、-、-、--、>| サービス| | | | | | | +-------------+ +-------------+ +------------+
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.
このメモはXMPPと非XMPPプロトコルの間でCPIM仕様で翻訳されるゲートウェイのそばで使用のためのマッピングを定義します。 そのようなゲートウェイは非XMPPサーバ(ネイティブの書式はCPIM仕様で定義されるかもしれない)のネットワークの中間的ホップではなく、XMPPと非XMPPプロトコルの間のひたむきな翻訳者です。そこでは、CPIM仕様がプロトコルが織り込むことの目的のために翻訳される一般的な書式を定義します。
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].
ここに定義されたマッピングは終わりから終わりへのセキュリティのために暗号化されないか、または署名されないインスタントメッセージと存在情報に適用されます。 サービスかXMPP-CPIMゲートウェイを通したXMPPサービスからの安全なコミュニケーションの情報について、[2XMPP EのE]を参照してください。
Saint-Andre Standards Track [Page 2] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[2ページ]。
1.2. Terminology
1.2. 用語
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.
このメモは[IMP-MODEL]で定義されたボキャブラリーを引き継ぎます。 CLOSEDや、INSTANT INBOXや、INSTANT MESSAGEや、オープンや、PRESENCE SERVICEや、PRESENTITYや、SUBSCRIPTIONや、WATCHERなどの用語はそこに定義されるのと同じ意味で使用されます。
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.
また、このメモは[XMPP-CORE]で定義されたボキャブラリーを引き継ぎます。 ENTITYや、NODE IDENTIFIERや、DOMAIN IDENTIFIERや、RESOURCE IDENTIFIERや、MESSAGE STANZAや、PRESENCE STANZAなどの用語はそこに定義されるのと同じ意味で使用されます。
1.3. Conventions Used in this Document
1.3. このDocumentのコンベンションUsed
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].
大文字で書かれたキーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[用語]で説明されるように本書では解釈されることであるべきですか?
2. Approach
2. アプローチ
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.
XMPPとCPIMは明瞭に外国の技術です。 したがって、XMPPとCPIM仕様で定義された抽象構文の間で写像しながら、注意を中に入れなければなりません。
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).
根では、XMPPはネットワークのどんな2つの終点の間のストリーミングのXML要素(「スタンザ」と呼ばれる)のためのデータトランスポート・プロトコルです。 メッセージと存在スタンザは、XMPPで定義された2つのコアデータ要素であり、IMユーザの間でインスタントメッセージと存在情報を交換するのにしばしば使用されます(XMLの固有の伸展性は、アプリケーションが他の目的にこれらのスタンザタイプの一般意味論を使用するのを可能にしますが)。 XMPPは[MIME]に基づいていません。 代わりに、[XMPP-CORE]はメッセージと存在スタンザの両方のためにXML schemasを定義します(例えば、メッセージスタンザの<ボディー/>子供は通常、人間のユーザによって読まれることを意図するXMLキャラクタデータを含みます)。
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.
CPIM仕様は2つ[MIME]のcontent typeを通してインスタントメッセージングと存在のための一般的な形式を提供します: メッセージへの「メッセージ/CPIM」([MSGFMT])と存在の「アプリケーション/pidf+xml。」([PIDF]) 「メッセージ/CPIM」オブジェクトの構文は、[RFC2822]で定義されたそれより同様ですが、厳しく、任意のMIMEメディアタイプ[MIMETYPES]を含む能力を提供します。 対照的に、それぞれの「アプリケーション/pidf+xml」オブジェクトは構造がXML図式によって定義される完全なXMLドキュメントです。
Saint-Andre Standards Track [Page 3] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[3ページ]。
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.
ここに取られたアプローチは[CPIM]と[CPP]によって定義される意味論に応じるために[MSGFMT]と[PIDF]によって定義されたXMPP要素と属性からヘッダーとMIME書式までマッピングを指定することです。 また、当然、逆方向へのマッピングを提供します。
3. Address Mapping
3. アドレス・マッピング
3.1. Overview
3.1. 概要
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:
XMPP実体を特定するのに使用される([XMPP-CORE]では、指定されます)アドレス形式が即時の受信トレイを特定するのに使用されるものと異なっているのでアドレス・マッピングが必要であるかもしれない、(不-、: URI体系は[CPIM)とpresentities(pres: [CPP]で指定されたURI体系)で指定しました。 特に、異なったキャラクタが許容されている、不-、: pres: URI、XMPPアドレスに許容されているより:
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.
o 以下の[米国のASCII]のキャラクタが許容されている、不-、: /はpresされます: URIにもかかわらず、どんなXMPPアドレスでも、そうしません: #26; (&), #27; ('), #2f。 (/) o Manyの非米国のASCII(明確にUTF-8)キャラクタはXMPPアドレスに許容されていますが、中に許容されていない、不-、: /はpresされます: XMPPが国際化している地方の部分アドレスを許容して以来のURI。
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
3.2. CPIMへのXMPP
The following is a high-level algorithm for mapping an XMPP address to an im: or pres: URI:
↓これがXMPPアドレスを写像するためのハイレベルのアルゴリズムである、不-、: 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)
1. ノード識別子(地方の部分; ステップのままで残る際に説明されたマッピング)、ドメイン識別子(範囲の外にホスト名;マッピングがある)、およびリソース識別子への分裂XMPPアドレス(接続; 特定のデバイスのための特許説明書の作成書か交差しているシステム相互運用性のためにこれを捨てます)
2. Apply Nodeprep profile of [STRINGPREP] (as specified in
[XMPP-CORE]) for canonicalization (OPTIONAL)
2. canonicalizationのために[STRINGPREP]([XMPP-CORE]で指定されるように)のNodeprepプロフィールを適用してください。(任意)です。
3. Translate #26; to &, #27; to ', and #2f; to / respectively
3. #26、を翻訳してください。 #27。 ''#2fに。 /、それぞれ
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]
4. 各バイトのために、コネはバイトであるなら$*_~+が次に、セクション2.2.5で説明される%hexhexへの変化と等しいセットA-Za-z0-9ではありませんか?[URLガイド]
Saint-Andre Standards Track [Page 4] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[4ページ]。
5. Combine resulting local-part with mapped hostname to form
local@domain address
5. 結果として起こる地方の部分を写像しているホスト名に結合して、 local@domain アドレスを形成してください。
6. Prepend with 'im:' scheme (for XMPP <message/> stanzas) or
'pres:' scheme (for XMPP <presence/> stanzas)
6. Prependする、'、不-、: '体系(XMPP<メッセージ/>スタンザのための)か'pres: '計画してください。(XMPP<存在/>スタンザのための)
3.3. CPIM to XMPP
3.3. XMPPへのCPIM
The following is a high-level algorithm for mapping an im: or pres: URI to an XMPP address:
↓これがマッピングのためのハイレベルのアルゴリズムである、不-、: pres: XMPPアドレスへのURI:
1. Remove URI scheme
1. URI体系を取り除いてください。
2. Split at the first '@' character into local-part and hostname
(mapping the latter is out of scope)
2. 最初の'@'キャラクタでは、ローカルの部分とホスト名に分けられます。(範囲の外に後者を写像するのがあります)
3. Translate %hexhex to equivalent octets as described in Section
2.2.5 of [URL-GUIDE]
3. セクション2.2.5で説明される同等な八重奏にhexhexな%を翻訳します。[URLガイド]
4. Treat result as a UTF-8 string
4. UTF-8ストリングとして結果を扱ってください。
5. Translate & to #26;, ' to #27;, and / to #2f respectively
5. 翻訳、#26; '#27、に;、#2fへの/、それぞれ'
6. Apply Nodeprep profile of [STRINGPREP] (as specified in
[XMPP-CORE]) for canonicalization (OPTIONAL)
6. canonicalizationのために[STRINGPREP]([XMPP-CORE]で指定されるように)のNodeprepプロフィールを適用してください。(任意)です。
7. Recombine local-part with mapped hostname to form local@domain
address
7. 写像しているホスト名と地方の部分を再結合させて、 local@domain アドレスを形成してください。
4. Syntax Mapping of Instant Messages
4. インスタントメッセージに関する構文マッピング
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].
このセクションはSHOULDがインスタントメッセージを写像する「メッセージ/CPIM」を使用するXMPPサービスと非XMPPが調整するゲートウェイが[CPIM]によって定義されるインスタントメッセージング意味論に応じるためにカプセル化されたテキスト内容の運搬人としてどう反対するかを説明します。
4.1. Message Syntax Mapping from XMPP to CPIM Specifications
4.1. XMPPからCPIMまで仕様を写像するメッセージ構文
This section defines the mapping of syntax primitives from XMPP message stanzas to "Message/CPIM" objects with encapsulated text content.
このセクションはカプセル化されたテキスト内容でXMPPメッセージスタンザから「メッセージ/CPIM」オブジェクトまで構文基関数に関するマッピングを定義します。
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
以下に注意してください。 MIMEオブジェクトに関するデフォルト文書内容が[MIME]で指定されるように指定される、「文書内容:」 テキスト/平野。 「charsetが私たちと等しい、-、ASCII、」 XMPPが排他的に[UTF-8]文字符号化を使用するので、XMPP-CPIMゲートウェイによって生成されたカプセル化されたMIMEオブジェクトはセットしなければなりません。
Saint-Andre Standards Track [Page 5] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[5ページ]。
"Content-type" MUST be set to "text/plain" and the charset MUST be set to "utf-8".
「テキスト/平野」に「文書内容」を設定しなければなりません、そして、charsetは「utf-8インチ」に用意ができなければなりません。
4.1.1. From Address
4.1.1. アドレスから
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).
XMPPメッセージスタンザの'from'属性は「メッセージ/CPIM」の'From'ヘッダーにオブジェクトを写像します。 送付者のサーバがXMPPでは、押し込むか、“from"アドレスを有効にして、または full <user@host/resource に値を設定する、gt;、認証とリソース結合の間、[XMPP-CORE]で定義されるようにクライアントとサーバの間で交渉されます。 したがって、XMPP-CPIMゲートウェイが送付者のXMPPサーバから form <user@host/resource の“from"アドレスを含むメッセージスタンザを受け取るために望んでいる、gt。 XMPPメッセージスタンザの'from'属性をaの'From'ヘッダーに写像するために、オブジェクト、ゲートウェイがリソース識別子を取り除かなければならないという「メッセージ/CPIM」が追加しなければならない、「不-、:、」 即時のMessaging URIは、アドレスの前部に計画して、送付者のためにCPIM「正式名」を含むかもしれません(知られているなら)。
Example: From Address Mapping
例: アドレス・マッピングから
XMPP 'from' attribute
<message from='juliet@example.com/balcony'>
...
</message>
XMPP 'from'が=' juliet@example.com/balcony 'からの<メッセージを結果と考える、gt;、… </メッセージ>。
CPIM 'From' header
From: Juliet Capulet <im:juliet@example.com>
CPIM 'From'ヘッダーFrom: ジュリエットキャピュレット<、不-、: juliet@example.com 、gt。
4.1.2. To Address
4.1.2. アドレスに
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).
XMPPメッセージスタンザの'to'属性は「メッセージ/CPIM」の'To'ヘッダーにオブジェクトを写像します。 XMPPでは、送付者SHOULDはメッセージスタンザの'to'属性を含んでいて、メッセージが配送のために別のユーザに意図するなら、それを含まなければなりません。 その結果、XMPP-CPIMゲートウェイが送付者のXMPPサーバから form <user@host の“to"アドレスを含むメッセージスタンザを受け取るために望んでいる、gt;、または、<ユーザ@host/リソース>。 XMPPメッセージスタンザの'to'属性をaの'To'ヘッダーに写像するために、オブジェクト、ゲートウェイがリソース識別子を取り除かなければならないという「メッセージ/CPIM」(含まれているなら)が追加しなければならない、「不-、:、」 即時のMessaging URIは、アドレスの前部に計画して、受取人のためにCPIM「正式名」を含むかもしれません(知られているなら)。
Saint-Andre Standards Track [Page 6] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[6ページ]。
Example: To Address Mapping
例: アドレス・マッピングに
XMPP 'to' attribute
<message to='romeo@example.net/orchard'>
...
</message>
XMPP 'to'が' romeo@example.net/orchard 'と等しい<メッセージを結果と考える、gt;、… </メッセージ>。
CPIM 'To' header
To: Romeo Montague <im:romeo@example.net>
CPIM 'To'ヘッダーTo: ロメオモンターグ<、不-、: romeo@example.net 、gt。
4.1.3. Stanza ID
4.1.3. スタンザ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.
XMPPメッセージスタンザには、'イド'属性があるかもしれません。(それは、スタンザを追跡する目的のための送付アプリケーションで使用されて、MIMEコンテントIDヘッダーによって定義されるようにグローバルにユニークな識別子ではありません)。 XMPP'イド'属性に、MIMEコンテントIDヘッダーと同じ意味がなくて、それはSHOULD NOTです。そのヘッダーに写像されてください。 'イド'が特有であることが知られて(例えば、それがXMPPサーバで特有であると生成されて、その事実がXMPP-CPIMゲートウェイが知られているなら)、次に、それはSHOULDです。しかしながら、非常に写像されます。
4.1.4. Message Type
4.1.4. メッセージタイプ
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.
XMPPメッセージスタンザには、'タイプ'属性があるかもしれません。(それは、メッセージの会話の関係を得るのに送付アプリケーションで使用されます)。 「メッセージ/CPIM」ヘッダー、一般的なMIME機能、またはカプセル化されたテキスト内容へのXMPP'タイプ'属性について写像してはいけません。 したがって、XMPP-CPIMゲートウェイによって受け取られたXMPPスタンザが'タイプ'属性を持っているなら、ゲートウェイSHOULDは提供された値を無視します。
4.1.5. Message Thread
4.1.5. メッセージスレッド
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.
XMPPメッセージスタンザはメッセージが位置している会話スレッドを指定する<スレッド/>子供要素を含むかもしれません。 「メッセージ/CPIM」ヘッダー、一般的なMIME機能、またはカプセル化されたテキスト内容へのXMPP<スレッド/>要素について写像してはいけません。 したがって、XMPP-CPIMゲートウェイによって受け取られたXMPPメッセージスタンザが<スレッド/>子供要素を含んでいるなら、ゲートウェイSHOULDは提供された値を無視します。
4.1.6. Message Subject
4.1.6. メッセージ対象
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
XMPPメッセージスタンザは<対象/>子供要素を含むかもしれません。 含まれているなら、それは「メッセージ/CPIM」の'受けることがある'ヘッダーにオブジェクトを写像します。 「メッセージ/CPIM」オブジェクトの'受けることがある'ヘッダー、SHOULDが単に値へのXMPP<対象/>要素に関するXMLキャラクタデータを写像するゲートウェイにXMPP<対象/>要素を写像します。
Saint-Andre Standards Track [Page 7] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[7ページ]。
'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.
''ヘッダーをかけてください。 <対象/>要素は対象が書かれている言語を指定する'xml: lang'属性を含むかもしれません。 ''xml: lang'属性を提供するなら、ヘッダーの後に'; langはタグと等しい'という名前とコロンを含んでいることによって、それを写像しなければなりません。(そこでは、'タグ'が'xml: lang'属性の値です)。
Example: Subject Mapping
例: 対象のマッピング
XMPP <subject/> element
<subject>Hi!</subject>
<subject xml:lang='cz'>Ahoj!</subject>
XMPP<対象/>の要素の<の対象の>Hi!</対象の>の<の対象のxml: langは'cz'>Ahoj!</対象>'と等しいです。
CPIM 'Subject' header
Subject: Hi!
Subject:;lang=cz Ahoj!
CPIM'対象'ヘッダーSubject: こんにちは! Subject:; lang=cz Ahoj!
4.1.7. Message Body
4.1.7. メッセージ本体
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.
XMPPメッセージスタンザの<ボディー/>子供原理は、メッセージのプライマリ意味を提供するのに使用されます。 XMPP<ボディー/>要素に関するXMLキャラクタデータはテキストメッセージ内容をカプセル化するのに写像します。
Example: Message Body
例: メッセージ本体
XMPP message <body/>
<message>
<body>Wherefore art thou, Romeo?</body>
</message>
XMPPメッセージ<ボディー/><メッセージ><ボディー>Wherefore芸術、なんじ、ロメオ?</ボディー></メッセージ>。
Encapsulated MIME text content
Content-type: text/plain; charset=utf-8
Content-ID: <123456789@example.net>
テキストのカプセル化されたMIME内容文書内容: テキスト/平野。 charset=utf-8コンテントID: <123456789@example.net>。
Wherefore art thou, Romeo?
いわれ芸術、なんじ、ロメオ--
4.1.8. Message Extensions
4.1.8. メッセージ拡張子
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.
[XMPP-CORE]で定義されるように、XMPPメッセージスタンザはコアメッセージスタンザの意味論について補うか、または敷衍するためにどんな名前空間でも「広げられた」内容を含むかもしれません。 [2XMPP EのE]で定義される'つぼ:ietf:params:xml:ナノ秒: xmpp-e2e'名前空間、XMPP-CPIMゲートウェイのそばで適切な拡張情報以外に、SHOULDはそのような情報を無視して、ゲートウェイに意図している受取人にそれを通しません。 そのような情報のための写像は定義されません。
Saint-Andre Standards Track [Page 8] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[8ページ]。
4.1.9. Gateway-Generated CPIM Syntax
4.1.9. ゲートウェイで発生しているCPIM構文
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:
CPIMは上で説明されたものに加えた「メッセージ/CPIM」ヘッダーの存在を指定しますが、コアXMPP仕様にはそれらのヘッダーのためのどんな正確なアナログもありません。 これらは:
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
o cc--、指定、メッセージ(すなわち、非プライマリの受け取り人)o DateTimeの「礼儀コピー」を受けることになっている実体のアドレス--o NSがメッセージに送られたdatetimeは指定します--、指定、aの名前空間は拡大o Requireを特集します--認識するために義務的な特徴を指定します。
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.
XMPP-CPIMゲートウェイは独自にそれ自身の情報(例えば、それがXMPP実体からメッセージスタンザを受け取ったdatetime)に基づいているか、または中核でないXMPP拡張子でコード化されたデータに基づくそのようなヘッダーを生成するかもしれませんが、このメモのための範囲の外にそうするための規則があります。
4.2. Message Syntax Mapping from CPIM Specifications to XMPP
4.2. 仕様をCPIMからXMPPに写像するメッセージ構文
This section defines the mapping of syntax primitives from "Message/CPIM" objects with encapsualted text content to XMPP message stanzas.
このセクションはencapsualtedテキスト内容がある「メッセージ/CPIM」オブジェクトからXMPPメッセージスタンザまで構文基関数に関するマッピングを定義します。
4.2.1. From Address
4.2.1. アドレスから
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).
XMPPメッセージスタンザの'from'属性への「メッセージ/CPIM」というオブジェクト地図の'From'ヘッダー。 CPIM 'From'ヘッダーをXMPP 'from'属性に写像するために、ゲートウェイが取り外されなければならない、「不-、:、」 即時のMessaging URIは、アドレスの前部から計画して、CPIM「正式名」を取り除かなければなりません(提供するなら)。
Example: From Address Mapping
例: アドレス・マッピングから
CPIM 'From' header
From: Romeo Montague <im:romeo@example.net>
CPIM 'From'ヘッダーFrom: ロメオモンターグ<、不-、: romeo@example.net 、gt。
XMPP 'from' attribute
<message from='romeo@example.net'>
...
</message>
XMPP 'from'が=' romeo@example.net 'からの<メッセージを結果と考える、gt;、… </メッセージ>。
4.2.2. To Address
4.2.2. アドレスに
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
XMPPメッセージスタンザの'to'属性への「メッセージ/CPIM」というオブジェクト地図の'To'ヘッダー。 CPIM 'To'ヘッダーをXMPP 'to'属性に写像するために、ゲートウェイが取り外されなければならない、「不-、:、」 即時のMessaging URIは、アドレスの前部から計画して、CPIMを取り外さなければなりません。
Saint-Andre Standards Track [Page 9] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[9ページ]。
"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.
「正式名。」(提供するなら) ゲートウェイにXMPP実体で使用中のリソース識別子に関する知識があるなら、ゲートウェイはリソース識別子をアドレスに追加するかもしれません。
Example: To Address Mapping
例: アドレス・マッピングに
CPIM 'To' header
To: Juliet Capulet <im:juliet@example.com>
CPIM 'To'ヘッダーTo: ジュリエットキャピュレット<、不-、: juliet@example.com 、gt。
XMPP 'to' attribute
<message to='juliet@example.com/balcony'>
...
</message>
XMPP 'to'が' juliet@example.com/balcony 'と等しい<メッセージを結果と考える、gt;、… </メッセージ>。
4.2.3. Courtesy Copy
4.2.3. 礼儀コピー
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.
コアXMPP仕様は「礼儀コピー」(非プライマリの受け取り人)をメッセージスタンザに指定するための構文を含んでいません。 したがって、XMPP-CPIMゲートウェイが「メッセージ/CPIM」オブジェクトを受けるなら、それは'cc'ヘッダーを含んでいて、それは情報がそのヘッダーにXMPP受取人に含んだSHOULD NOTパスです。
4.2.4. DateTime Header
4.2.4. DateTimeヘッダー
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.
コアXMPP仕様はメッセージスタンザが送られたdatetimeを指定するための構文を含んでいません。 したがって、XMPP-CPIMゲートウェイが「メッセージ/CPIM」オブジェクトを受けるなら、それは'DateTime'ヘッダーを含んでいて、それは情報がそのヘッダーにXMPP受取人に含んだSHOULD NOTパスです。
4.2.5. Message Subject
4.2.5. メッセージ対象
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.
XMPPメッセージスタンザの<対象/>子供原理への「メッセージ/CPIM」というオブジェクト地図の'受けることがある'ヘッダー。 XMPP<対象/>要素にCPIM'対象'ヘッダーを写像するために、ゲートウェイSHOULDは単にXMPP<対象/>要素に関するXMLキャラクタデータに'受けることがある'ヘッダーの値を写像します。 '受けることがある'ヘッダーは対象が書かれている"lang"を指定するかもしれません。 '"lang"情報を提供するなら、'xml: lang'属性の値がストリングで供給された「タグ」値である<対象/>要素の'xml: lang'属性にそれを写像しなければならない'; langはタグの'CPIM'対象の後に包含'であるヘッダー名とコロンと等しいです。
Saint-Andre Standards Track [Page 10] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[10ページ]。
Example: Subject Mapping
例: 対象のマッピング
CPIM 'Subject' header
Subject: Hi!
Subject:;lang=cz Ahoj!
CPIM'対象'ヘッダーSubject: こんにちは! Subject:; lang=cz Ahoj!
XMPP <subject/> element
<subject>Hi!</subject>
<subject xml:lang='cz'>Ahoj!</subject>
XMPP<対象/>の要素の<の対象の>Hi!</対象の>の<の対象のxml: langは'cz'>Ahoj!</対象>'と等しいです。
4.2.6. Header Extensions
4.2.6. ヘッダー拡大
"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.
「メッセージ/CPIM」オブジェクトは、特徴拡張子の名前空間を指定するために任意の'NS'ヘッダーを含むかもしれません。 XMPP-CPIMゲートウェイはXMPP受取人にとって終えたそのようなヘッダーを渡してはいけません、そして、そのようなヘッダーのための写像は定義されません。
4.2.7. Require Header
4.2.7. ヘッダーを必要としてください。
"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.
「メッセージ/CPIM」オブジェクトは、認識するために義務的な特徴を指定するために任意の'必要'ヘッダーを含むかもしれません。 一般に、含まれていて、ヘッダーがそうするそのようなものは、アプリケーションが特定のヘッダーか(2)によって指定された機能性を理解するために必要とする受信が、何らかの非ヘッダー意味論が、メッセージ(例えば、"Locale.MustRenderKanji")のコンテンツを理解するために受信アプリケーションで実装される必要であるのを示すと(1)への非XMPP送付アプリケーションで主張します。 XMPP-CPIMゲートウェイ自体よりむしろアプリケーションを受け取るXMPPは認識するために義務的な特徴に要求されるでしょう、したがって、ゲートウェイがアプリケーションを受け取りながら、XMPPの能力に関する詳細な知識なしで'必要'ヘッダーを適切に扱うことができません。 したがって、1つを含んでいるか、または以上が「メッセージ/CPIM」オブジェクトのヘッダーを'必要である'ならXMPP-CPIMゲートウェイSHOULDが非XMPP送付アプリケーションに警告か誤りを返すのは適切に見えます。 警告か誤りの正確な本質は、外国システムによって使用される非XMPP技術の本質によって、ここに定義されません。 その上、XMPPへの'必要'ヘッダーかXMPP拡張子に関するどんなマッピングも実装、または、将来の仕様に残されます。
4.2.8. MIME Content-ID
4.2.8. MIMEコンテント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.
XMPPは[MIME]における指定されるとしてのコンテントID MIMEヘッダーのために定義されるグローバルにユニークなIDをキャプチャする要素か属性を含んでいません。 XMPP-CPIMゲートウェイがコンテントIDを含んでいるMIMEオブジェクトを受けるなら、メッセージスタンザの'イド'属性の値としてコンテントIDを提供するかもしれませんが、これはOPTIONALです。
Saint-Andre Standards Track [Page 11] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[11ページ]。
Example: Content-ID for Encapsulated Object
例: カプセル化オブジェクトのためのコンテントID
MIME header
Content-ID: <123456789@example.net>
MIMEヘッダーコンテントID: <123456789@example.net>。
XMPP 'id' attribute (OPTIONAL)
<message id='123456789@example.net'>
...
</message>
XMPP'イド'属性(OPTIONAL)<メッセージイド=' 123456789@example.net '、gt;、… </メッセージ>。
4.2.9. Message Body
4.2.9. メッセージ本体
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.
カプセル化されたMIMEオブジェクトの文書内容が「テキスト/明瞭である」なら、カプセル化されたテキストメッセージ内容はXMPPメッセージスタンザの<ボディー/>子供原理に関するキャラクタデータをXMLに写像します。
Example: Message Body
例: メッセージ本体
Encapsulated MIME text content
Content-type: text/plain; charset=utf-8
Content-ID: <123456789@example.net>
テキストのカプセル化されたMIME内容文書内容: テキスト/平野。 charset=utf-8コンテントID: <123456789@example.net>。
Wherefore art thou?
いわれ芸術、なんじ--
XMPP message <body/>
<message id='123456789@example.net'>
<body>Wherefore art thou?</body>
</message>
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 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.
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
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.
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
Saint-Andre Standards Track [Page 12] RFC 3922 XMPP to CPIM October 2004
5. Syntax Mapping of Presence Information
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].
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
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.
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".
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
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).
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
Example: From Address Mapping
XMPP 'from' attribute
<presence from='juliet@example.com/balcony'>
...
</presence>
XMPP 'from' attribute <presence from='juliet@example.com/balcony'> ... </presence>
CPIM 'From' header
From: Juliet Capulet <im:juliet@example.com>
CPIM 'From' header From: Juliet Capulet <im:juliet@example.com>
Saint-Andre Standards Track [Page 13] RFC 3922 XMPP to CPIM October 2004
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.
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)
Example: From Address Mapping (PIDF)
XMPP 'from' attribute
<presence from='juliet@example.com/balcony'>
...
</presence>
XMPP 'from' attribute <presence from='juliet@example.com/balcony'> ... </presence>
PIDF 'entity' attribute
<presence entity='pres:juliet@example.com'>
...
</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.
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
Example: Resource Identifier Mapping
XMPP 'from' attribute
<presence from='juliet@example.com/balcony'>
...
</presence>
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>
PIDF 'id' for <tuple/> <presence entity='pres:juliet@example.com'> <tuple id='balcony'> ... </tuple> </presence>
5.1.2. To Address
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
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
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).
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
Example: To Address Mapping
XMPP 'to' attribute
<presence to='romeo@example.net/orchard'>
...
</presence>
XMPP 'to' attribute <presence to='romeo@example.net/orchard'> ... </presence>
CPIM 'To' header
To: Romeo Montague <im:romeo@example.net>
CPIM 'To' header To: Romeo Montague <im:romeo@example.net>
5.1.3. Stanza ID
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.
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
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).
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
Example: Available Presence
XMPP available presence
<presence from='juliet@example.com/balcony'/>
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'>
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
Saint-Andre Standards Track [Page 15] RFC 3922 XMPP to CPIM October 2004
<tuple id='balcony'>
<status>
<basic>open</basic>
</status>
</tuple>
</presence>
<tuple id='balcony'> <status> <basic>open</basic> </status> </tuple> </presence>
Example: Unavailable Presence
Example: Unavailable Presence
XMPP unavailable presence
<presence from='juliet@example.com/balcony' type='unavailable'/>
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>
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
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.
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
Example: Show Element
XMPP <show/> element
<presence from='juliet@example.com/balcony'>
<show>away</show>
</presence>
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>
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
Saint-Andre Standards Track [Page 16] RFC 3922 XMPP to CPIM October 2004
<im:im>away</im:im>
</status>
</tuple>
</presence>
<im:im>away</im:im> </status> </tuple> </presence>
5.1.6. Status Element
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.
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
Example: Status Element
XMPP <status/> element
<presence from='juliet@example.com/balcony'>
<show>away</show>
<status>retired to the chamber</status>
</presence>
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>
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
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
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
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).
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
Example: Presence Priority
XMPP <status/> element
<presence from='juliet@example.com/balcony'>
<priority>13</priority>
</presence>
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>
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
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.
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. Gateway-Generated CPIM and PIDF Syntax
5.1.9.1. CPIM Message Headers
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:
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 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 DateTime -- specifies the datetime at which the presence information was sent
o NS -- specifies the namespace of a feature extension
o NS -- specifies the namespace of a feature extension
Saint-Andre Standards Track [Page 18] RFC 3922 XMPP to CPIM October 2004
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 Subject -- specifies the subject or topic of the encapsulated "Message/CPIM" object
o Require -- specifies mandatory-to-recognize features
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.
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
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:
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 <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.
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
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.
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]).
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
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
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
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.
gateway MUST remove the "im:" Instant Messaging URI scheme from the front of the address and MUST remove the CPIM "Formal-name" (if provided) in order to generate the <user@host> portion of the XMPP 'from' attribute, then add a '/' character followed by the value of the PIDF <tuple/> element's 'id' attribute.
Example: From Address Mapping
Example: From Address Mapping
CPIM 'From' header
From: Romeo Montague <im:romeo@example.net>
CPIM 'From' header From: Romeo Montague <im:romeo@example.net>
XMPP 'from' attribute
<presence from='romeo@example.net'>
...
</presence>
XMPP 'from' attribute <presence from='romeo@example.net'> ... </presence>
Example: Resource Identifier Mapping
Example: Resource Identifier Mapping
XMPP 'from' attribute
<presence from='juliet@example.com/balcony'>
...
</presence>
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>
PIDF 'id' for <tuple/> <presence entity='pres:juliet@example.com'> <tuple id='balcony'> ... </tuple> </presence>
5.2.2. To Address
5.2.2. To Address
The 'To' header of a "Message/CPIM" object maps to the 'to' attribute 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.
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
Saint-Andre Standards Track [Page 20] RFC 3922 XMPP to CPIM October 2004
Example: To Address Mapping
Example: To Address Mapping
CPIM 'To' header
To: Juliet Capulet <im:juliet@example.com>
CPIM 'To' header To: Juliet Capulet <im:juliet@example.com>
XMPP 'to' attribute
<presence to='juliet@example.com/balcony'>
...
</presence>
XMPP 'to' attribute <presence to='juliet@example.com/balcony'> ... </presence>
5.2.3. Courtesy Copy
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.
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
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.
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
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.
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
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.
"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
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.
"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
Saint-Andre Standards Track [Page 21] RFC 3922 XMPP to CPIM October 2004
5.2.8. MIME Content-ID
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.
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
Example: Content-ID for Encapsulated Object
MIME header
Content-ID: <123456789@example.net>
MIME header Content-ID: <123456789@example.net>
XMPP 'id' attribute (OPTIONAL)
<presence id='123456789@example.net'>
...
</presence>
XMPP 'id' attribute (OPTIONAL) <presence id='123456789@example.net'> ... </presence>
5.2.9. Basic Presence Status
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".
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
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>
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'/>
XMPP available presence <presence from='romeo@example.net/orchard'/>
Saint-Andre Standards Track [Page 22] RFC 3922 XMPP to CPIM October 2004
Saint-Andre Standards Track [Page 22] RFC 3922 XMPP to CPIM October 2004
Example: CLOSED Presence
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>
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'/>
XMPP unavailable presence <presence from='romeo@example.net/orchard' type='unavailable'/>
5.2.10. Extended Status Information
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.
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)
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>
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>
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
Saint-Andre Standards Track [Page 23] RFC 3922 XMPP to CPIM October 2004
5.2.11. Note Element
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.
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
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>
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>
=' romeo@example.net/orchard 'からのXMPP<状態/>要素<存在、gt;、<ショー>dnd</ショー><状態>Wooingジュリエット</状態></存在>。
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)).
tuplesがないPIDFドキュメントはPIDF<存在/>要素のダイレクト子供として1つ以上の<注意/>要素を含むかもしれません。 そのようなPIDFドキュメントについてXMPP存在スタンザに写像してはいけません。 できれば、XMPP-CPIMゲートウェイSHOULD NOTの非XMPP側面の上の実体はそのようなPIDFドキュメントをXMPP受取人に送ります、そして、XMPP-CPIMゲートウェイはそのようなPIDFドキュメントをXMPP存在スタンザに写像してはいけません(Zero Resources(セクション6.3.2)を見てください)。
5.2.12. Contact Element
5.2.12. 連絡要素
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/>
PIDFドキュメントが校長に連絡できるアドレスのURIを指定する<接触/>要素を含むかもしれない、(例えば、不-、:、mailto: tel:、またはURI、) コアXMPP仕様は連絡先のURIを指定するための構文を含んでいません、連絡先がXMPP存在スタンザの'from'属性で暗黙であるので。 したがって、XMPP-CPIMゲートウェイが要約のPIDF物で「メッセージ/CPIM」物を受けるなら、それは<接触/>を含んでいます。
Saint-Andre Standards Track [Page 24] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[24ページ]。
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.)
要素、それ、SHOULD NOTは<接触/>要素に関するXMLキャラクタデータをXMPP受取人に渡します。 (しかしながら、以下のComplete PIDF Document(セクション5.2.15)のInclusionを見てください。)
Example: PIDF Contact Element
例: PIDF連絡要素
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>
PIDF<接触/>要素<--xmlバージョン= '1.0'='UTF-8'をコード化しますか?><存在xmlnsが'つぼ:ietf:params: xml:ナノ秒:pidf'実体='pres: romeo@example.net 'と等しい、gt;、<tupleイド='果樹園'>…' <接触>、不-、: romeo@example.net 、lt;、/接触></tupleな></存在>。
XMPP presence stanza
<presence from='romeo@example.net/orchard'/>
=' romeo@example.net/orchard '/からのXMPP存在スタンザ<存在、gt。
5.2.13. Presence Priority
5.2.13. 存在優先権
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).
PIDF<tuple/>要素の<接触/>子供には、値がゼロと1(少数第最大3位がある)の間の10進数である'優先権'属性があるかもしれません。 この属性の値はXMPP存在スタンザの<優先権/>子供原理に写像されるかもしれません。 XMPP-CPIMゲートウェイはXMPP<優先権/>要素の負の数にPIDF優先順位の値を写像してはいけません。 <優先権>127</優先権>としてのXMPP<優先権としてXMPP-CPIMゲートウェイがこれらの値を写像して、それがSHOULD御馳走のPIDF優先権='0'であるという>0</優先権>とPIDF優先権='1'であるなら; 彼らがユニークである(例えば、XMPP優先権1への0.001と0.007の間のPIDFプライオリティ、XMPP優先権2への0.008と0.015の間のPIDFプライオリティXMPP優先権126への0.992〜0.999にPIDFプライオリティを写像するのによるなど; これが例専用であり、正確なマッピングがXMPP-CPIMゲートウェイのそばで決定することに注意する)ように、適切に中間的値を写像します。
5.2.14. Timestamp Element
5.2.14. タイムスタンプ要素
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.
コアXMPP仕様は存在スタンザが送られたdatetimeかタイムスタンプを指定するための構文を含んでいません。 したがって、XMPP-CPIMゲートウェイが要約のPIDF物で「メッセージ/CPIM」物を受けるなら、それは<タイムスタンプ/>要素を含んでいます、それ。SHOULD NOTは<タイムスタンプ/>要素に関するXMLキャラクタデータをXMPP受取人に渡します。
Saint-Andre Standards Track [Page 25] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[25ページ]。
5.2.15. Inclusion of Complete PIDF Document
5.2.15. 完全なPIDFドキュメントの包含
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.
あるPIDF要素は(例えば、<接触/>要素に関するXMLキャラクタデータ)をXMPP存在スタンザ構文に写像しません。 しかしながら、XMPPクライアントは、固有のPIDFドキュメントを分析することによって、そのような情報を扱うことができるかもしれません。 これを可能にするように、XMPP-CPIMゲートウェイは存在スタンザの子供原理として完全なPIDFドキュメントを含むかもしれません、[XMPP-PIDF]で説明されるように。 XMPPクライアントがこの拡張データを理解していないなら、それは自然にそれを無視しなければなりません。
6. XMPP-CPIM Gateway as Presence Service
6. 存在サービスとしてのXMPP-CPIMゲートウェイ
[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.)
[CPP]は抽象的な存在サービスのために意味論を定義します。 XMPP-CPIMゲートウェイはそのような存在サービスとして機能するかもしれません、そして、そうだとすれば、XMPP実体はゲートウェイの存在サービスと対話するのに定義されたXMPP構文を使用できます。 [PIDF]が申し込むような意味操作のための構文を指定しないので、このセクションはそのようなXMPP構文に関する翻訳ではなく、XMPP-CPIMゲートウェイで提供する存在サービスとのXMPP相互作用だけをPIDFと定義します。 (注意: [XMPP-IM]でXMPP存在サービスの詳細な情報をできるだけ見つけることができます、構文、意味論、およびサーバビジネス規則がそこに定義したXMPP-CPIMゲートウェイSHOULD道具。)
6.1. Requesting a Subscription
6.1. 購読を要求します。
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:
XMPP実体がXMPP-CPIMゲートウェイを通して非XMPP presentityの存在情報に加入したいなら、それはタイプが目標に「申し込む」というpresentityの存在スタンザを送らなければなりません。 構文マッピングは以下の通りです:
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 CPP「ウォッチャーパラメタ」分野(pres: user@host )にXMPP 'from'属性( user@host )を写像しなければなりません。 XMPP-CPIMゲートウェイが追加しなければならない、「pres:」 アドレスの前部への存在URI計画。
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 CPP「目標パラメタ」分野(pres: user@host )にXMPP 'to'属性( user@host )を写像しなければなりません。 XMPP-CPIMゲートウェイが追加しなければならない、「pres:」 アドレスの前部への存在URI計画。
o There is no XMPP mapping for the CPP "duration parameter", since
XMPP subscriptions are active until they have been explicitly
"unsubscribed".
o CPPのために「持続時間パラメタ」を写像するXMPPが全くありません、それらが明らかに「外される」までXMPP購読が活発であるので。
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field.
o XMPP'イド'はSHOULDを結果と考えます。CPP"TransID"分野に写像されてください。
Saint-Andre Standards Track [Page 26] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[26ページ]。
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.
目標であるなら、presentityは購読要求(それがゲートウェイと対話するのに使用するどんなプロトコルを通した)を承認します、とXMPP-CPIMゲートウェイがXMPP実体に「申し込まれた」タイプの存在スタンザを返して、目標の現在の利用可能な存在のXMPP実体に通知しなければなりません。 その後、目標の存在情報が変化するときはいつも、購読が中止されるまで、ゲートウェイは申し込んでいるXMPP実体に通知しなければなりません。
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.
目的のpresentityが購読要求を否定するなら、XMPP-CPIMゲートウェイがタイプのスタンザがXMPP実体に「外し」て、呼び出してはいけない存在を返さなければならない、操作に通知してください。
In addition to the approval and denial cases, one of the following exceptions may occur:
承認と否定ケースに加えて、以下の例外の1つは起こるかもしれません:
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 目標パラメタ(XMPP “to"アドレス)は有効なpresentityについて言及しません。 この例外が起こるなら、XMPP-CPIMゲートウェイは見つけられなかった<の品目/>スタンザ誤りをXMPP実体に返さなければなりません。
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 アクセス制御規則は、実体が目標に加入することを許可しません。 この例外が起こるなら、XMPP-CPIMゲートウェイは/>スタンザ誤りがXMPP実体に禁じられた<を返さなければなりません。
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.
o 先在の購読が存在するか、または進行中では、XMPP実体と目標presentityの間の操作を申し込んでください。 この例外が起こるなら、XMPP-CPIMゲートウェイSHOULDは<闘争/>スタンザ誤りをXMPP実体に返します。
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.
XMPPサービスは、それが明らかに終えられるまで購読が活発であると仮定します。 しかしながら、非XMPPサービスは限られた持続時間の購読を実行するかもしれません。(XMPP購読の恒久的をまねるために定期的に持続時間をリフレッシュしなければなりません)。 したがって、送るゲートウェイがそのようなものが必要があるかもしれないXMPPからCPIMはそれへのXMPP実体を代表して非XMPP実体にリフレッシュします。購読は期限が切れません。 そのようなものがリフレッシュするかどうかが必要です。ゲートウェイが翻訳されているCPIM意識している非XMPPサービスで実行されて、固有のプロトコルによります。
6.2. Receiving a Subscription Request
6.2. 購読要求を受け取ります。
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:
非XMPP presentityがXMPP-CPIMゲートウェイを通してXMPP実体の存在情報に加入したいなら、購読を要求するためにゲートウェイと対話するのに使用するどんなプロトコルも使用しなければなりません。 そして、ローカルのアクセス規則を条件として、ゲートウェイは「申し込タイプ」の存在スタンザを非XMPPウォッチャーからXMPP実体に送らなければなりません。 構文マッピングは以下の通りです:
Saint-Andre Standards Track [Page 27] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[27ページ]。
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 CPP「ウォッチャーパラメタ」分野(pres: user@host )をXMPP 'from'属性( user@host )に写像しなければなりません。 XMPP-CPIMゲートウェイが取り外されなければならない、「pres:」 アドレスの前部からの存在URI計画。
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 CPP「目標パラメタ」分野(pres: user@host )をXMPP 'to'属性( user@host )に写像しなければなりません。 XMPP-CPIMゲートウェイが取り外されなければならない、「pres:」 アドレスの前部からの存在URI計画。
o There is no XMPP mapping for the CPP "duration parameter", since
XMPP subscriptions are active until they have been explicitly
"unsubscribed".
o CPPのために「持続時間パラメタ」を写像するXMPPが全くありません、それらが明らかに「外される」までXMPP購読が活発であるので。
o The CPP "TransID" field SHOULD be mapped to the XMPP 'id'
attribute.
o CPP"TransID"はSHOULDをさばきます。XMPP'イド'属性に写像されてください。
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.
目標XMPP実体が購読要求を承認するなら、それはウォッチャーpresentityに「申し込まれた」タイプの存在スタンザを送らなければなりません。 そして、XMPP-CPIMゲートウェイは目標XMPP実体の現在の利用可能な存在についてウォッチャーpresentityに通知しなければなりません。 その後、目標の存在情報が変化するときはいつも、購読が中止されるまで、ゲートウェイはウォッチャーpresentityに通知しなければなりません。
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.
目標XMPP実体が購読要求を否定するなら、それはウォッチャーpresentityに「外された」タイプの存在スタンザを送らなければなりません。 XMPP-CPIMゲートウェイが呼び出してはいけない、操作に通知してください。
In addition to the approval and denial cases, one of the following exceptions MAY occur:
承認と否定ケースに加えて、以下の例外の1つは起こるかもしれません:
o The target parameter (XMPP "to" address) does not refer to a valid
XMPP entity
o 目標パラメタ(XMPP “to"アドレス)は有効なXMPP実体について言及しません。
o Access control rules do not permit the watcher presentity to
subscribe to the target XMPP entity
o アクセス制御規則は、ウォッチャーpresentityが目標XMPP実体に加入することを許可しません。
o There exists a pre-existing subscription or in-progress subscribe
operation between the watcher presentity and the target XMPP
entity
o 先在の購読が存在するか、または進行中では、ウォッチャーpresentityと目標XMPP実体の間の操作を申し込んでください。
If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform the watcher presentity of failure.
これらの例外のどれかが起こるなら、XMPP-CPIMゲートウェイは失敗についてウォッチャーpresentityに知らせなければなりません。
Saint-Andre Standards Track [Page 28] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[28ページ]。
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.
XMPPサービスは、それが明らかに終えられるまで購読が活発であると仮定します。 値がゼロである取り扱い持続時間パラメタを除いて、取り扱い持続時間パラメタはXMPP-CPIMゲートウェイの実現と要件に非常に依存するようになるでしょう。 [IMP-MODEL]か[IMP-REQS]のどちらかで指定された「持続時間パラメタ」を支持するためのどんな明白な要件もないので、持続時間パラメタマッピングはこのメモの範囲をそらせるローカルの問題です。 しかしながら、その持続時間パラメタが期限が切れた後に、XMPP-CPIMゲートウェイは、非XMPPサービスのときに実体から受け取るなら持続時間パラメタの動向をおさえて、購読を削除するかもしれません。
6.3. The Notify Operation
6.3. 操作に通知してください。
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).
XMPP-CPIMゲートウェイはXMPP実体かCPP presentityに関連している存在情報が変化して、それへの加入者がいるときはいつも、CPPが「操作に通知する」というゲートウェイの反対側の情報を呼び出します。 存在のためにMappingの下で定義されるaがPresence(セクション5)のために操作に通知する関連する情報を写像する構文。
6.3.1. Multiple Resources
6.3.1. 複数のリソース
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.
意味的に、PIDFは複数の存在"tuples"の概念を含んでいます。 通常、PIDFドキュメントは、少なくとも1tupleを含みますが、1tupleを含むかもしれません(tuplesのゼロを合わせてください)。tuplesに関して、次のセクションは見られます。 XMPPの用語では、各tupleは別々のリソースのための情報を存在に写像するでしょう。 しかしながら、XMPPは一度に1つ以上のリソースの存在情報を送る能力を含んでいません、存在情報を発生させるリソースが存在スタンザの'from'アドレスに含まれているので。 したがって、存在サービスSHOULDとして作動するXMPP-CPIMゲートウェイは複数のtuplesを含むPIDFドキュメントを複数のXMPP存在スタンザに分けました、そして、XMPPユーザに複数の接続リソースが現在あるなら、SHOULDは1通のPIDFドキュメント(複数のtuplesと)だけを作ります。
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.
必要性を超えたXMPPスタンザ、SHOULDが発生させるXMPP-CPIMゲートウェイを掛けないことのためにPIDF tupleに含まれた存在情報が装置の有用性状態の変化を伝えるだけであるか、そして、アプリケーションがそのtuple IDに関連づけたXMPP存在スタンザ。
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
複数のPIDFドキュメント、SHOULDが含むXMPP-CPIMゲートウェイでというよりむしろ複数のtuplesの複数の「リソース」の情報を提供するというPIDF推薦に従うことのために
Saint-Andre Standards Track [Page 29] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[29ページ]。
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.
1つのリソースだけの有用性状態が変化したとしてもPIDFが記録する(各リソースあたり1tupleで)1のXMPPユーザのリソースのすべての情報。
6.3.2. Zero Resources
6.3.2. リソースがありません。
A PIDF document may contain zero tuples. For example:
PIDFドキュメントはtuplesを全く含まないかもしれません。 例えば:
PIDF Document with Zero Tuples
PIDFはゼロでTuplesを記録します。
<presence entity='pres:juliet@example.com'
xmlns='urn:ietf:params:xml:ns:pidf'/>
<存在実体='pres: juliet@example.com 'xmlnsは'つぼ:ietf:params:xml:ナノ秒: 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).
(1) '実体'が the <user@host への要素地図をa PIDF<存在/>の結果と考える、gt;、(2) tuple/>要素がXMPPアドレスのリソース識別子部分、tuplesを全く含まないPIDFドキュメントに写像するPIDF<のXMPPアドレスと'イド'属性の部分が a <user@host の存在情報を提供するだろう、gt;、 a <user@host/resource よりむしろ、gt;、XMPPに写像されると。 ユーザのリソースの1つよりむしろ単なるユーザに関する存在通知の概念はほとんど無意味ですが、XMPP文脈、SHOULDがPIDFドキュメントを写像するXMPP-CPIMゲートウェイでは、'from'アドレスが非XMPP実体の user@host であるXMPP存在スタンザにtuplesのゼロを合わせてください。 しかしながら、XMPP実体から存在スタンザを受け取るとき、XMPP-CPIMゲートウェイはどんな<tuple/>子供と共にもPIDFドキュメントを作ってはいけません(非XMPPサービスへのゲートウェイによって伝えられたすなわちすべてのPIDFドキュメントが少なくとも1つの<tuple/>要素を含まなければなりません)。
6.4. Unsubscribing
6.4. 外します。
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:
XMPP実体が非XMPP presentityの存在からXMPP-CPIMゲートウェイまで外したいなら、それはタイプが目標に「外す」というpresentityの存在スタンザを送らなければなりません。 構文マッピングは以下の通りです:
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 CPP「ウォッチャーパラメタ」分野(pres: user@host )にXMPP 'from'属性( user@host )を写像しなければなりません。 XMPP-CPIMゲートウェイが追加しなければならない、「pres:」 アドレスの前部への存在URI計画。
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 CPP「目標パラメタ」分野(pres: user@host )にXMPP 'to'属性( user@host )を写像しなければなりません。 XMPP-CPIMゲートウェイが追加しなければならない、「pres:」 アドレスの前部への存在URI計画。
o The CPP "duration parameter" MUST be set to zero.
o CPP「持続時間パラメタ」をゼロに設定しなければなりません。
Saint-Andre Standards Track [Page 30] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[30ページ]。
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field.
o XMPP'イド'はSHOULDを結果と考えます。CPP"TransID"分野に写像されてください。
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.
目標パラメタ(XMPP “to"アドレス)が有効なpresentityについて言及しないなら、XMPP-CPIMゲートウェイは見つけられなかった<の品目/>スタンザ誤りをXMPP実体に返さなければなりません。
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.
XMPP実体、XMPP-CPIMゲートウェイからの「外してください」がそうしてはいけないタイプの存在スタンザを受け取ったら、さらなる存在通知をXMPP実体に送ってください。
6.5. Cancelling a Subscription
6.5. 定期講読契約を取り消します。
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:
XMPP実体がXMPP-CPIMゲートウェイを通して実体の存在の非XMPP presentityの購読を中止したいなら、それは目標presentityに「外された」タイプの存在スタンザを送らなければなりません。 構文マッピングは以下の通りです:
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 CPP「ウォッチャーパラメタ」分野(pres: user@host )にXMPP 'from'属性( user@host )を写像しなければなりません。 XMPP-CPIMゲートウェイが加えなければならない、「pres:」 アドレスの前部への存在URI計画。
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 CPP「目標パラメタ」分野(pres: user@host )にXMPP 'to'属性( user@host )を写像しなければなりません。 XMPP-CPIMゲートウェイが加えなければならない、「pres:」 合わせてください. ○ CPP「持続時間パラメタ」を設定しなければならないゼロアドレスの前部への存在URI計画。
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID"
field.
o XMPP'イド'はSHOULDを結果と考えます。CPP"TransID"分野に写像されてください。
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.
XMPP実体から「外された」タイプの存在スタンザを受け取ると、XMPP-CPIMゲートウェイはさらなる存在通知をウォッチャーpresentityに送ってはいけません。
7. Security Considerations
7. セキュリティ問題
Detailed security considerations for instant messaging and presence protocols are given in [IMP-REQS], specifically in Sections 5.1 through 5.4.
[IMP-REQS]と、特にセクション5.1〜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
このドキュメントは[CPIM]と[CPP]を実行するゲートウェイを通してインスタントメッセージと存在情報を交換するための方法を指定します。 そのようなゲートウェイはそれが連結するインスタントメッセージングと存在プロトコルの最小のセキュリティ要件で言いなりになっているに違いありません。 またRFC2779でのインスタントメッセージングと存在のモデルが導入するセキュリティへのゲートウェイの導入
Saint-Andre Standards Track [Page 31] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[31ページ]。
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].
いくつかの新しいリスク。 一般的な形式を支持する場合にだけ、特に、インスタントメッセージングとXMPP-CPIMゲートウェイを通して連結する存在ユーザエージェントの間の終わりから終わりへのセキュリティ資産(特に秘密性と保全)を提供できます。 これらの形式は[2XMPP EのE]で完全に指定されます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[CPIM] ピーターソン、J.、「インスタントメッセージング(CPIM)のための一般的なプロフィール」、RFC3860、2004年8月。
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC
3859, August 2004.
[CPP] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、2004年8月。
[IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February
2000.
2000年2月の[悪童モデル]日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent,
"Instant Messaging / Presence Protocol Requirements",
RFC 2779, February 2000.
[悪童-REQS]日、M.とAggarwalとS.とモーア、G.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、2000年2月のRFC2779。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[MIME]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August
2004.
[MSGFMT] Klyne、G.、およびD.アトキンス、「一般的な存在とインスタントメッセージング(CPIM):」 「メッセージ・フォーマット」、RFC3862、2004年8月。
[PIDF] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[PIDF] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、2004年8月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings (stringprep)", RFC 3454,
December 2002.
[STRINGPREP] ホフマンとP.とM.Blanchet、「国際化しているストリング(stringprep)の準備」、RFC3454、2002年12月。
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TERMS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[URL-GUIDE] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November
1999.
1999年11月の[URLガイド]MasinterとL.とAlvestrandとH.とZigmond、D.とR.Petke、「新しいURL Schemesのためのガイドライン」RFC2718。
Saint-Andre Standards Track [Page 32] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[32ページ]。
[US-ASCII] Cerf, V., "ASCII format for network interchange", RFC
20, October 1969.
[米国-ASCII] サーフ、V.、「ネットワーク置き換えのためのASCII書式」、RFC20、1969年10月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
[XMPP-CORE] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-コア] サンアンドレ、P.、エド、「広げることができるメッセージングと存在は(XMPP)について議定書の中で述べます」。 「コア」、RFC3920、2004年10月。
[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.
[2XMPP EのE] サンアンドレ、P.(エド)、「広げることができるメッセージングと存在における終わりから終わりへの調印と物の暗号化は(XMPP)について議定書の中で述べます」、RFC3923、2004年10月。
[XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and
Presence Protocol (XMPP): Instant Messaging and
Presence", RFC 3921, October 2004.
[XMPP、-、不-、]、サンアンドレ編、P.、「広げることができるメッセージングと存在は以下について議定書の中で述べ(XMPP)」。 「インスタントメッセージングと存在」、RFC3921、10月2004日
8.2. Informative References
8.2. 有益な参照
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[MIMETYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
解放された[MIMETYPES]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[XMPP-PIDF] Saint-Andre, P., "Transporting Presence Information
Data/Format (PIDF) over the Extensible Messaging and
Presence Protocol (XMPP)", Work in Progress, February
2004.
[XMPP-PIDF] 「広げることができるメッセージングと存在プロトコル(XMPP)の上で存在インフォメーション・データ/形式(PIDF)を輸送し」て、サンアンドレ、P.は進行中(2004年2月)で働いています。
Author's Address
作者のアドレス
Peter Saint-Andre Jabber Software Foundation
ピーターサンアンドレおしゃべりソフトウェア財団
EMail: stpeter@jabber.org
メール: stpeter@jabber.org
Saint-Andre Standards Track [Page 33] RFC 3922 XMPP to CPIM October 2004
サンアンドレ規格は2004年10月にRFC3922XMPPをCPIMに追跡します[33ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Saint-Andre Standards Track [Page 34]
サンアンドレ標準化過程[34ページ]
一覧
スポンサーリンク
