[要約] RFC 3922は、XMPPとCPIMのマッピングに関するものであり、XMPPメッセージングとCPIMメッセージングの相互運用性を提供するためのガイドラインを提供しています。目的は、異なるプロトコル間のメッセージングシステムの統合を容易にし、インスタントメッセージングとプレゼンス情報の共有を効率的に行うことです。
Network Working Group P. Saint-Andre
Request for Comments: 3922 Jabber Software Foundation
Category: Standards Track October 2004
Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
拡張可能なメッセージングと存在プロトコル（XMPP）を共通の存在とインスタントメッセージング（CPIM）にマッピングする
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications.
このメモは、拡張可能なメッセージングと存在プロトコル（XMPP）と共通の存在とインスタントメッセージング（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
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".)
インスタントメッセージングとプレゼンス（IMPP）ワーキンググループは、[IMP-REQS]に準拠したインスタントメッセージング（IM）と存在システム間の相互運用性の抽象的なフレームワークを定義しました。このフレームワークは、一般的に共通の存在とインスタントメッセージングまたは「CPIM」と呼ばれます。仕様のCPIMファミリーには、インスタントメッセージング[CPIM]（CPIMとも呼ばれます）の共通プロファイル、存在の共通プロファイル[CPP]、CPIMメッセージ形式[MSGFMT]、および共通の存在情報データ形式[PIDF]が含まれます。（注：混乱を防ぐために、共通の存在感とインスタントメッセージングはここで「CPIM仕様」と総称されますが、インスタントメッセージングの共通プロファイルは「CPIM」と呼ばれます。）
This memo describes how the Extensible Messaging and Presence Protocol ([XMPP-CORE], [XMPP-IM]) maps to the abstract model contained in the CPIM specifications, mainly for the purpose of establishing gateways between XMPP services and non-XMPP services that conform to [IMP-REQS]. Such a gateway, referred to herein as an "XMPP-CPIM gateway", may be established to interpret the protocols of one service and translate them into the protocols of the other service. We can visualize this relationship as follows:
このメモは、主にXMPPサービスと非XMPPサービスの間にゲートウェイを確立する目的で、CPIM仕様に含まれる抽象モデルに拡張可能なメッセージと存在プロトコル（[XMPP-CORE]、[XMPP-IM]）がどのようにマップするかを説明しています。[inp-reqs]に準拠しています。このようなゲートウェイは、「XMPP-CPIMゲートウェイ」と呼ばれ、1つのサービスのプロトコルを解釈し、他のサービスのプロトコルに変換するために確立される場合があります。この関係を次のように視覚化できます。
+-------------+ +-------------+ +------------+
| | | | | |
| XMPP | | XMPP-CPIM | | Non-XMPP |
| Service | <----> | Gateway | <----> | Service |
| | | | | |
+-------------+ +-------------+ +------------+
This memo defines a mapping for use by a gateway that translates between XMPP and a non-XMPP protocol via the CPIM specifications. Such a gateway is not an intermediate hop on a network of non-XMPP servers (whose native formats may or may not be defined by the CPIM specifications), but a dedicated translator between XMPP and a non-XMPP protocol, where the CPIM specifications define the common formats into which the protocols are translated for purposes of interworking.
このメモは、CPIM仕様を介してXMPPと非XMPPプロトコルの間を変換するゲートウェイで使用するマッピングを定義します。このようなゲートウェイは、XMPP以外のサーバーのネットワーク（CPIM仕様によってネイティブ形式が定義される場合と定義されていない場合があります）の中間ホップではなく、XMPPと非XMPPプロトコルの間の専用の翻訳者です。プロトコルがインターワーキングの目的で翻訳される一般的な形式。
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サービスとの間での安全な通信の詳細については、[XMPP-E2E]を参照してください。
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]で定義された語彙を継承します。クローズド、インスタントインボックス、インスタントメッセージ、オープン、プレゼンスサービス、プレゼンテーション、サブスクリプション、ウォッチャーなどの用語は、そこに定義されているのと同じ意味で使用されます。
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]で定義された語彙も継承します。エンティティ、ノード識別子、ドメイン識別子、リソース識別子、メッセージスタンザ、存在スタンザなどの用語は、そこに定義されているのと同じ意味で使用されます。
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].
大文字のキーワード「必須」、「必要」、「必須」、「「shall」、「shall」、「shall "、" should "、" nove "、" becommended "、" may "、および" optional "）[用語]で説明されているように解釈されます。
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).
rootでは、XMPPは、ネットワーク上の任意の2つのエンドポイント間のXML要素（「スタンザ」と呼ばれる）をストリーミングするためのデータ輸送プロトコルです。メッセージと存在スタンザは、XMPPで定義されているコアデータ要素の2つであり、IMユーザー間でインスタントメッセージと存在情報を交換するためによく使用されます（ただし、XMLの固有の拡張性により、アプリケーションはこれらのスタンザタイプの一般的なセマンティクスを他の目的で使用できます）。XMPPは[MIME]に基づいていません。代わりに、[XMPP-Core]はメッセージと存在の両方のスタンザの両方のXMLスキーマを定義します（たとえば、Stanzaの<Body/>子には、通常、人間のユーザーが読むことを目的とする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]コンテンツタイプ：メッセージ（[MSGFMT]）の「メッセージ/CPIM」と存在の「アプリケーション/PIDF XML」の2つの[MIME]コンテンツタイプを介して、インスタントメッセージングと存在の一般的な形式を提供します（[PIDF]）。「メッセージ/cpim」オブジェクトの構文は、[rfc2822]で定義されているものよりも厳密ではありませんが、任意のmimeメディアタイプ[マイメタイプ]を含める機能を提供します。対照的に、各「アプリケーション/PIDF XML」オブジェクトは、構造がXMLスキーマによって定義される完全なXMLドキュメントです。
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]によって定義されたヘッダーおよびMIME形式へのXMPP要素と属性のマッピングを指定することです。当然、反対方向のマッピングも提供されます。
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]で指定）とは異なるため、インスタント受信トレイ（[CPIM]で指定されたIM：URIスキーム）およびプレゼンテーション（Pres：[CPP]で指定されたURIスキーム）。特に、XMPPアドレスで許可されているよりも、IM：およびpres：urisで異なる文字が許可されています。
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 次の[us-ascii]文字はim：/pres：urisで許可されていますが、xmppアドレスではありません：＃26;（＆）、＃27;（ '）、＃2f;（/）。o XMPPではXMPPアドレスで許可されていませんが、XMPPでは許可されていませんが、XMPPは国際化されたローカルパートアドレスを許可しているため、多くの非US-ASCII（具体的にはUTF-8）文字が許可されていません。
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).
注：このドキュメントでは、ローカルパートアドレスのみで許可されている文字について議論します（つまり、ドメイン名のマッピングは、このドキュメントの初期バージョンの範囲外ではありません。完全に国際化されたドメイン名の翻訳）。
The following is a high-level algorithm for mapping an XMPP address to an im: or pres: URI:
以下は、XMPPアドレスをIMにマッピングするための高レベルのアルゴリズムです：または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. 標準化に[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. 各バイトについて、バイトがセットA-ZA-Z0-9にない場合！$*。？
5. Combine resulting local-part with mapped hostname to form local@domain address
5. 結果のローカルパートをマッピングされたホスト名と組み合わせて、ローカル@ドメインアドレスを形成します
6. Prepend with 'im:' scheme (for XMPP <message/> stanzas) or 'pres:' scheme (for XMPP <presence/> stanzas)
6. 'im：'スキーム（xmpp <メッセージ/>スタンザの場合）または 'pres：' scheme（xmpp <fresence/> stanzas）をプレイする
The following is a high-level algorithm for mapping an im: or pres: URI to an XMPP address:
以下は、IMをマッピングするための高レベルのアルゴリズムです。
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. [url-guide]のセクション2.2.5で説明されているように、％hexhexを同等のオクテットに翻訳します
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. 標準化に[stringprep]（[xmpp-core]で指定）のnodeprepプロファイルを適用する（オプション）
7. Recombine local-part with mapped hostname to form local@domain address
7. マッピングされたホスト名でローカルパートを再結合して、ローカル@ドメインアドレスを形成する
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].
このセクションでは、[CPIM]で定義されたインスタントメッセージングセマンティクスを順守するために、「メッセージ/CPIM」オブジェクトを使用して「メッセージ/CPIM」オブジェクトを使用して、「メッセージ/CPIM」オブジェクトを使用してXMPPサービスと非XMPPサービス間のインスタントメッセージをマッピングする方法について説明します。
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オブジェクトのデフォルトのコンテンツタイプは「Content-Type：Text/Plain; charset = us-ascii」です。XMPPは独占的にエンコードする[UTF-8]文字を使用するため、XMPP-CPIMゲートウェイによって生成されたカプセル化されたMIMEオブジェクトは設定する必要があります。
"Content-type" MUST be set to "text/plain" and the charset MUST be set to "utf-8".
「コンテンツタイプ」は「テキスト/プレーン」に設定する必要があり、charSetは「UTF-8」に設定する必要があります。
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では、送信者のサーバーは「アドレス」をスタンプまたは検証し、[XMPP-Core]で定義されている認証とリソースバインディング中にクライアントとサーバーの間で交渉された完全な<user@host/resource>にその値を設定します。したがって、XMPP-CPIMゲートウェイは、送信者のXMPPサーバーから、フォームの「From」アドレス<user@host/resource>の「From」を含むメッセージを受け取ります。XMPPメッセージスタンザの「From」属性を「メッセージ/CPIM」オブジェクトの「From」ヘッダーにマッピングするには、ゲートウェイはリソース識別子を削除する必要があります。アドレス、および送信者のCPIM「フォーマル名」が含まれる場合があります（既知の場合）。
Example: From Address Mapping
例：アドレスマッピングから
XMPP 'from' attribute
<message from='juliet@example.com/balcony'>
...
</message>
CPIM 'From' header
From: Juliet Capulet <im:juliet@example.com>
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では、送信者はメッセージスタンザに「to」属性を含める必要があり、メッセージが別のユーザーへの配信を意図している場合はそれを含める必要があります。したがって、XMPP-CPIMゲートウェイは、送信者のXMPPサーバーから、フォームのアドレスを含むメッセージ<ユーザー@host>または<user@host/resource>を受け取ります。XMPPメッセージスタンザの「to」属性を「メッセージ/cpim」オブジェクトの 'to'ヘッダーにマッピングするには、ゲートウェイはリソース識別子を削除する必要があります（含まれる場合）、「IM：」インスタントメッセージングURIスキームを追加する必要がありますアドレスの前面に、および受信者のCPIM「フォーマル名」を含めることができます（既知の場合）。
Example: To Address Mapping
例：マッピングに対処する
XMPP 'to' attribute
<message to='romeo@example.net/orchard'>
...
</message>
CPIM 'To' header
To: Romeo Montague <im:romeo@example.net>
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メッセージStanzaは、Stanzasを追跡する目的で送信アプリケーションで使用される「ID」属性を所有している可能性があり、MIME Content-IDヘッダーによって定義されるようなグローバルな識別子ではありません。XMPP 'ID'属性はMIME Content-IDヘッダーと同じ意味を持たないため、そのヘッダーにマッピングしないでください。ただし、「ID」が一意であることが知られている場合（たとえば、XMPPサーバーによって一意に生成され、その事実はXMPP-CPIMゲートウェイで知られている場合）、そのようにマッピングする必要があります。
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メッセージStanzaには「タイプ」属性がある場合があります。これは、送信アプリケーションで使用され、メッセージの会話コンテキストをキャプチャするために使用されます。「メッセージ/CPIM」ヘッダー、一般的なMIME機能、またはカプセル化されたテキストコンテンツへのXMPP 'タイプ'属性のマッピングはありません。したがって、XMPP-CPIMゲートウェイで受信したXMPPスタンザが「タイプ」属性を持っている場合、ゲートウェイは提供される値を無視する必要があります。
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メッセージStanzaには、メッセージが位置する会話スレッドを指定する<スレッド/>子要素が含まれている場合があります。XMPP <スレッド/>要素の「メッセージ/CPIM」ヘッダー、一般的なMIME機能、またはカプセル化されたテキストコンテンツへのマッピングはありません。したがって、XMPP-CPIMゲートウェイによって受信されたXMPPメッセージStanzaに<スレッド/>子要素が含まれている場合、ゲートウェイは提供される値を無視する必要があります。
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」オブジェクトの「サブジェクト」ヘッダーにマップします。XMPP <件名/>要素を「メッセージ/CPIM」オブジェクトの「サブジェクト」ヘッダーにマッピングするには、ゲートウェイはXMPP <サブジェクト/>要素のXML文字データを単純にマッピングする必要があります。
'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 = tag'をヘッダー名とコロンの後に含めることでマッピングする必要があります。ここで、「タグ」は 'xml：lang'属性の値です。
Example: Subject Mapping
例：サブジェクトマッピング
XMPP <subject/> element
<subject>Hi!</subject>
<subject xml:lang='cz'>Ahoj!</subject>
CPIM 'Subject' header
Subject: Hi!
Subject:;lang=cz Ahoj!
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 <body/>要素のxml文字データ。
Example: Message Body
例：メッセージ本文
XMPP message <body/>
<message>
<body>Wherefore art thou, Romeo?</body>
</message>
Encapsulated MIME text content
Content-type: text/plain; charset=utf-8
Content-ID: <123456789@example.net>
Wherefore art thou, Romeo?
だから芸術、ロミオ？
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メッセージスタンザには、コアメッセージスタンザのセマンティクスを補足または拡張するために、任意の名前空間に「拡張」コンテンツが含まれる場合があります。[urn：ietf：params：xml：ns：xmpp-e2e '名前空間で[xmpp-e2e]で定義されている拡張情報を除き、xmpp-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」ヘッダーの存在を指定しますが、Core 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要求 - 必須の機能を指定する機能を指定します
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エンティティからメッセージスタンザを受け取ったデータ）または非コアXMPPエクステンションでエンコードされたデータに基づいて、そのようなヘッダーを独立して生成する場合がありますが、そうするためのルールはこのメモの範囲外。
This section defines the mapping of syntax primitives from "Message/CPIM" objects with encapsualted text content to XMPP message stanzas.
このセクションでは、「メッセージ/CPIM」オブジェクトからXMPPメッセージスタンザへの「メッセージ/CPIM」オブジェクトからの構文プリミティブのマッピングを定義します。
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メッセージStanzaの「From」属性に「メッセージ/CPIM」オブジェクトの「From」ヘッダー。「ヘッダー」からcpimを「xmpp」から「属性」にマッピングするには、ゲートウェイは「im：」インスタントメッセージングuriスキームをアドレスの前面から削除し、cpim "formal-name"（提供されている場合）を削除する必要があります。
Example: From Address Mapping
例：アドレスマッピングから
CPIM 'From' header
From: Romeo Montague <im:romeo@example.net>
XMPP 'from' attribute
<message from='romeo@example.net'>
...
</message>
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メッセージStanzaの「to」属性に「メッセージ/CPIM」オブジェクトの「To」ヘッダーをマップします。cpimを 'ヘッダーにxmppにマッピングするには、属性にマップするには、ゲートウェイはアドレスの前面から「im：」インスタントメッセージングuriスキームを削除し、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.
「フォーマル名」（提供されている場合）。GatewayがXMPPエンティティが使用しているリソース識別子の知識を持っている場合、ゲートウェイはリソース識別子をアドレスに追加する場合があります。
Example: To Address Mapping
例：マッピングに対処する
CPIM 'To' header
To: Juliet Capulet <im:juliet@example.com>
XMPP 'to' attribute
<message to='juliet@example.com/balcony'>
...
</message>
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ゲートウェイが「CC」ヘッダーを含む「メッセージ/CPIM」オブジェクトを受信した場合、そのヘッダーに含まれる情報をXMPP受信者に渡すべきではありません。
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.
Core XMPP仕様には、Stanzaが送信されたメッセージを指定するための構文は含まれていません。したがって、XMPP-CPIMゲートウェイが「DateTime」ヘッダーを含む「メッセージ/CPIM」オブジェクトを受信した場合、そのヘッダーに含まれる情報をXMPP受信者に渡すべきではありません。
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メッセージStanzaの<件名/>子要素に「メッセージ/CPIM」オブジェクトの「サブジェクト」ヘッダーをマップします。cpim 'サブジェクト'ヘッダーをXMPP <件名/>要素にマッピングするには、ゲートウェイは「サブジェクト」ヘッダーの値をXMPP <件名/>要素のXML文字データにマッピングする必要があります。「サブジェクト」ヘッダーは、被験者が書かれている「ラング」を指定する場合があります。「lang」情報が提供されている場合、<件名/>要素の「xml：lang」属性にマッピングする必要があります。ここで、 'xml：lang'属性は文字列に供給される「タグ」値です。; lang = tag 'cpim' subject 'ヘッダー名とコロンの後に含まれるタグ。
Example: Subject Mapping
例：サブジェクトマッピング
CPIM 'Subject' header
Subject: Hi!
Subject:;lang=cz Ahoj!
XMPP <subject/> element
<subject>Hi!</subject>
<subject xml:lang='cz'>Ahoj!</subject>
"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レシピエントに渡さないでください。そのようなヘッダーのマッピングは定義されていません。
"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.
「Message/CPIM」オブジェクトには、オプションの「要求」ヘッダーが含まれる場合があります。一般に、このようなヘッダーは、（1）へのアプリケーションを送信する非XMPPに含まれることに含まれます。受信アプリケーションは特定のヘッダーによって指定された機能を理解する必要があること、または（2）非ヘッダーのセマンティクスをによって実装する必要があることを示しています。メッセージの内容を理解するための受信アプリケーション（例： "locale.musternderkanji"）。XMPP-CPIMゲートウェイ自体ではなく、XMPP受信アプリケーションに必須の機能が必要になるため、XMPP受信アプリケーションの機能に関する詳細な知識なしに、ゲートウェイは「必要」ヘッダーを適切に処理できません。したがって、XMPP-CPIMゲートウェイは、「メッセージ/CPIM」オブジェクトに1つ以上の「要求」ヘッダーが含まれている場合、XMPPを送信するアプリケーションに警告またはエラーを返す必要があることが適切であると思われます。警告またはエラーの正確な性質は、外国システムが使用する非XMPPテクノロジーの性質に依存し、ここでは定義されていません。さらに、XMPPまたはXMPP拡張機能への「必要」ヘッダーのマッピングは、実装または将来の仕様に任されます。
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オブジェクトを受信した場合、Stanzaの「ID」属性のメッセージの値としてコンテンツIDを提供する場合がありますが、これはオプションです。
Example: Content-ID for Encapsulated Object
例：カプセル化されたオブジェクト用のContent-ID
MIME header
Content-ID: <123456789@example.net>
XMPP 'id' attribute (OPTIONAL)
<message id='123456789@example.net'>
...
</message>
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>
Wherefore art thou?
だからあなたはあなた？
XMPP message <body/>
<message id='123456789@example.net'>
<body>Wherefore art thou?</body>
</message>
If the Content-Type is not "text/plain", the XMPP-CPIM gateway MAY map the content to an XMPP extension but MUST NOT map it to the <body/> child of the XMPP message stanza, which is allowed to contain XML character data only. The only exception to this rule is a multi-part MIME object of the kind specified in [XMPP-E2E], which is to be mapped as described in that memo.
コンテンツタイプが「テキスト/プレーン」でない場合、XMPP-CPIMゲートウェイはコンテンツをXMPP拡張機能にマッピングできますが、XMPLの<ボディ/>子スタンザの<body/>子にマッピングしてはなりません。文字データのみ。このルールの唯一の例外は、[XMPP-E2E]で指定された種類のマルチパートMIMEオブジェクトです。これは、そのメモで説明されているようにマッピングされます。
If the charset is "US-ASCII" or "UTF-8", the gateway MUST map the "Message/CPIM" object; otherwise it SHOULD NOT.
charsetが「us-ascii」または「utf-8」の場合、ゲートウェイは「メッセージ/cpim」オブジェクトをマッピングする必要があります。それ以外の場合はそうすべきではありません。
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は、XMPPメッセージスタンザの「タイプ」属性の存在を指定します。これにより、送信者はメッセージの会話コンテキストを定義できます。CPIMには、この属性の正確なアナログはありません。XMPP-CPIMゲートウェイは、独自の情報に基づいて「タイプ」属性を個別に生成する場合がありますが、これはオプションであり、そうするためのルールはこのメモの範囲外です。
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].
このセクションでは、ゲートウェイが「メッセージ/CPIM」オブジェクトを使用してXMPPサービスと非XMPPサービス間の存在情報をマッピングする方法について説明します。]。
This section defines the mapping of syntax primitives from XMPP presence stanzas to "Message/CPIM" objects with encapsulated "application/pidf+xml" objects.
このセクションでは、XMPPの存在スタンザから、カプセル化された「アプリケーション/PIDF XML」オブジェクトを持つ「メッセージ/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 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".
注：[MIME]で指定されているように、MIMEオブジェクトのデフォルトのコンテンツタイプは「Content-Type：Text/Plain; charset = us-ascii」です。XMPPは[UTF-8]文字を独占的にコードする文字を使用し、PIDFは「アプリケーション/PIDF XML」MIMEタイプを指定するため、存在情報のためにXMPP-CPIMゲートウェイによって生成されたカプセル化されたMIMEオブジェクトは、「コンテンツタイプ」ヘッダーを設定する必要があります。そのオブジェクト。「コンテンツタイプ」は「アプリケーション/PIDF XML」に設定する必要があり、CharSetは「UTF-8」に設定する必要があります。
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).
XMPPの存在の「From」属性スタンザは、「メッセージ/CPIM」オブジェクトの「From」ヘッダーにマップします。XMPPでは、送信者のサーバーは「from」アドレスをスタンプまたは検証し、[XMPP-Core]で定義されている認証およびリソースバインディング中にクライアントとサーバーの間で交渉された<user@host/resource>にその値を設定します。したがって、XMPP-CPIMゲートウェイは、送信者のXMPPサーバーから、フォームのアドレスを含む存在スタンザを受け取ります<user@host/resource>。XMPPの存在スタンザの「From」属性を「メッセージ/CPIM」オブジェクトの「From」ヘッダーにマッピングするには、ゲートウェイはリソース識別子を削除する必要があります。アドレス、および送信者のCPIM「フォーマル名」が含まれる場合があります（既知の場合）。
Example: From Address Mapping
例：アドレスマッピングから
XMPP 'from' attribute
<presence from='juliet@example.com/balcony'>
...
</presence>
CPIM 'From' header
From: Juliet Capulet <im:juliet@example.com>
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.
さらに、XMPPの存在の「From」属性スタンザは、PIDF <infaction/>ルート要素の「エンティティ」属性にマップします。XMPP '属性をPIDF' Entity '属性にマッピングするには、ゲートウェイはリソース識別子を削除し、「pres：」インスタントメッセージングURIスキームをアドレスの前面に追加する必要があります。
Example: From Address Mapping (PIDF)
例：アドレスマッピング（PIDF）から
XMPP 'from' attribute
<presence from='juliet@example.com/balcony'>
...
</presence>
PIDF 'entity' attribute
<presence entity='pres:juliet@example.com'>
...
</presence>
Finally, an XMPP-CPIM gateway SHOULD map the resource identifier of the XMPP address contained in the XMPP 'from' attribute to the 'id' attribute of the PIDF <tuple/> child element.
最後に、XMPP-CPIMゲートウェイは、XMPP 'に含まれるXMPPアドレスのリソース識別子を、'属性からPIDF <tuple/>子要素の「ID」属性にマッピングする必要があります。
Example: Resource Identifier Mapping
例：リソース識別子マッピング
XMPP 'from' attribute
<presence from='juliet@example.com/balcony'>
...
</presence>
PIDF 'id' for <tuple/>
<presence entity='pres:juliet@example.com'>
<tuple id='balcony'>
...
</tuple>
</presence>
The 'to' attribute of an XMPP presence stanza maps to the 'To' header of a "Message/CPIM" object. In XMPP, the sender MAY include a 'to' attribute on a presence stanza, and MUST include it if the presence stanza is intended for delivery directly to another user (presence stanzas intended for broadcasting are stamped with a 'to' address by the sender's server). Thus an XMPP-CPIM gateway will receive from the sender's XMPP server a presence stanza containing a "to" address of the form <user@host> or <user@host/resource>. To map the 'to' attribute of an XMPP presence stanza to the 'To' header of a "Message/CPIM" object, the gateway MUST remove the resource identifier (if included), MUST append the "im:" Instant Messaging URI scheme to the front of the address, and MAY include a CPIM "Formal-name" for the recipient (if known).
XMPPの存在の「to」属性は、スタンザを「メッセージ/CPIM」オブジェクトの「to」ヘッダーにマッピングします。XMPPでは、送信者には存在スタンザに「to」属性を含めることができ、スタンザが別のユーザーに直接配信することを目的としている場合は、それを含める必要があります（放送用の存在スタンザには、送信者の「To」アドレスが刻印されていますサーバ）。したがって、XMPP-CPIMゲートウェイは、送信者のXMPPサーバーから、フォームのアドレスを含むスタンザを含む存在感を受け取ります<user@host>または<user@host/resource>。XMPPの存在スタンザの「to」属性を「メッセージ/cpim」オブジェクトの「to」ヘッダーにマッピングするには、ゲートウェイはリソース識別子（含まれている場合）を削除する必要があります。アドレスの前面に、および受信者のCPIM「フォーマル名」を含めることができます（既知の場合）。
Example: To Address Mapping
例：マッピングに対処する
XMPP 'to' attribute
<presence to='romeo@example.net/orchard'>
...
</presence>
CPIM 'To' header
To: Romeo Montague <im:romeo@example.net>
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.
XMPPの存在スタンザには、スタンザを追跡する目的で送信アプリケーションで使用される「ID」属性を所有する場合があり、MIME Content-IDヘッダーによって定義されるようなグローバルな識別子ではありません。XMPP 'ID'属性はMIME Content-IDヘッダーと同じ意味を持たないため、そのヘッダーにマッピングしないでください。ただし、「ID」が一意であることが知られている場合（たとえば、XMPPサーバーによって一意に生成され、その事実はXMPP-CPIMゲートウェイで知られている場合）、そのようにマッピングする必要があります。
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).
XMPPの存在スタンザには、「タイプ」属性がある場合があります。「タイプ」属性が含まれていない場合、スタンザの存在は、送信者が利用可能であることを示します。この状態は、PIDFの基本的な存在タイプのオープンタイプにマッピングします。「タイプ」属性に「利用できない」値がある場合、スタンザの存在は、送信者がもはや利用できなくなったことを示します。この状態は、閉じたPIDF基本的な存在タイプにマップします。したがって、「タイプ」属性と「タイプ」属性の両方が「cpp]「notify操作」に対応する「cpp]に対応する」の値に設定されています。他のすべての存在タイプは、現在の存在のための存在サブスクリプションまたはプローブを管理するために使用されます。これらの他の存在タイプのマッピングは、XMPP-CPIMゲートウェイの存在サービスとして定義されています（セクション6）。
Example: Available Presence
例：利用可能な存在
XMPP available presence
<presence from='juliet@example.com/balcony'/>
PIDF basic presence (OPEN)
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:juliet@example.com'>
<tuple id='balcony'>
<status>
<basic>open</basic>
</status>
</tuple>
</presence>
Example: Unavailable Presence
例：利用できない存在
XMPP unavailable presence
<presence from='juliet@example.com/balcony' type='unavailable'/>
PIDF basic presence (CLOSED)
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:romeo@example.net'>
<tuple id='balcony'>
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
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.
XMPPの存在感の<show/>子要素Stanzaは、送信者の可用性に関する追加情報を提供します。XMPP <show/>要素マップのxml文字データは、pidfの<ステータス/>コンテンツを拡張します。<show/>要素の定義された値は、「アウェイ」、「チャット」、「dnd」、および「xa」です。'urn：ietf：params：xml：ns：pidf：im' namespaceの拡張ステータス状態に対して値が指定されるとすぐに、XMPP値はPIDF値にマッピングされます。
Example: Show Element
例：要素を表示します
XMPP <show/> element
<presence from='juliet@example.com/balcony'>
<show>away</show>
</presence>
PIDF extended presence information
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:im='urn:ietf:params:xml:ns:pidf:im'
entity='pres:juliet@example.com'>
<tuple id='balcony'>
<status>
<basic>open</basic>
<im:im>away</im:im>
</status>
</tuple>
</presence>
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.
XMPPの存在感の<ステータス/>子要素Stanzaは、送信者の詳細な可用性状態のユーザー定義の自然言語の説明を提供します。xmpp <status/>要素は、pidf <note/> pidf <tuple/>要素の子にマップします。
Example: Status Element
例：ステータス要素
XMPP <status/> element
<presence from='juliet@example.com/balcony'>
<show>away</show>
<status>retired to the chamber</status>
</presence>
PIDF <note/> element
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:im='urn:ietf:params:xml:ns:pidf:im'
entity='pres:juliet@example.com'>
<tuple id='balcony'>
<status>
<basic>open</basic>
<im:im>away</im:im>
</status>
<note>retired to the chamber</note>
</tuple>
</presence>
An XMPP presence stanza MAY contain a <priority/> child element whose value is an integer between -128 and +127. The value of this element MAY be mapped to the 'priority' attribute of the <contact/> child of the PIDF <tuple/> element. If the value of the XMPP <priority/> element is negative, an XMPP-CPIM gateway MUST NOT map the value. The range of allowable values for the PIDF 'priority' attribute is any decimal number from zero to one inclusive, with a maximum of three decimal places. If an XMPP-CPIM gateway maps these values, it SHOULD treat XMPP <priority>0</priority> as PIDF priority='0' and XMPP <priority>127</priority> as PIDF priority='1', mapping intermediate values appropriately so that they are unique (e.g., XMPP priority 1 to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, and so on up through mapping XMPP priority 126 to PIDF priority 0.992; note that this is an example only, and that the exact mapping shall be determined by the XMPP-CPIM gateway).
XMPPの存在スタンザには、値が-128〜127の間の整数である<優先度/>子要素が含まれている場合があります。この要素の値は、pidf <tupleの<contact/>子の「優先度」属性にマッピングできます。/>要素。XMPP <Priority/>要素の値が負の場合、XMPP-CPIMゲートウェイは値をマップしてはなりません。PIDF「優先度」属性の許容値の範囲は、ゼロから1つの包括的数字まで、最大3つの小数点を持つ任意の10進数です。XMPP-CPIMゲートウェイがこれらの値をマッピングする場合、XMPP <Priority> 0 </Priority>をPIDF優先度= '0'として扱う必要があります</priority> 127 </priority>適切には、それらが一意であるように適切に（例：XMPP優先度1からPIDF優先度0.007、XMPP優先度2からPIDF優先度0.015など、XMPP優先度126をPIDF優先度0.992にマッピングすることにより、これは例のみであり、正確なマッピングは、XMPP-CPIMゲートウェイによって決定されます）。
Example: Presence Priority
例：存在の優先順位
XMPP <status/> element
<presence from='juliet@example.com/balcony'>
<priority>13</priority>
</presence>
PIDF <note/> element
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:juliet@example.com'>
<tuple id='balcony'>
...
<contact priority='0.102'>im:juliet@example.com</contact>
</tuple>
</presence>
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.
[XMPP-Core]で定義されているように、XMPPの存在スタンザには、コアプレゼンススタンザのセマンティクスを補足または拡張するために、任意の名前空間に「拡張」コンテンツが含まれる場合があります。[urn：ietf：params：xml：ns：xmpp-e2e '名前空間で[xmpp-e2e]で定義されている拡張情報を除き、xmpp-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」ヘッダーの存在を指定しますが、Core XMPP仕様にはそれらのヘッダーに正確なアナログはありません。これらには以下が含まれます：
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-存在情報の「礼儀コピー」を受け取ることになるエンティティの住所を指定します（つまり、非プリマリーの宛先）
o DateTime -- specifies the datetime at which the presence information was sent
o DateTime-存在情報が送信された日時を指定します
o NS -- specifies the namespace of a feature extension o Subject -- specifies the subject or topic of the encapsulated "Message/CPIM" object
o ns-機能拡張機能o主題の名前空間を指定します - カプセル化された「メッセージ/CPIM」オブジェクトの件名またはトピックを指定します
o Require -- specifies mandatory-to-recognize features
o 要求 - 必須の機能を指定します
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.
XMPP-CPIMゲートウェイは、独自の情報（たとえば、XMPPエンティティからスタンザを受け取ったデータタイムなど）に基づいて、または非コアXMPP拡張機能でエンコードされたデータに基づいて、そのようなヘッダーを独立して生成する場合がありますが、そうするためのルールはこのメモの範囲外。
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は、上記のXML要素に加えてXML要素の存在を指定しますが、Core XMPP仕様にはこれらのXML要素の正確な類似体はありません。これらには以下が含まれます：
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/> - アドレス（例：im：、tel：、：、mailto：uri）を指定します。XMPP-CPIMゲートウェイには、この要素が含まれる場合があります。この場合、「IM：」インスタントメッセージングURIスキームで前提されているXMPP送信者の<ユーザー@host>にその値を設定する必要があります。
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/> - 存在情報が送信されたデータタイムを指定します。XMPP-CPIMゲートウェイは、独自の情報（XMPPエンティティからスタンザの存在を受け取ったデータ）または非コアXMPP拡張でエンコードされたデータに基づいて、独自の情報（たとえば、XMPPエンティティからスタンザの存在を受け取ったデータタイム）に基づいて、この要素を個別に生成する場合がありますが、そうするためのルールはこのメモの範囲外。
This section defines the mapping of syntax primitives from "Message/CPIM" objects with encapsulated "application/pidf+xml" objects to XMPP presence stanzas.
このセクションでは、カプセル化された「アプリケーション/PIDF XML」オブジェクトを使用した「メッセージ/CPIM」オブジェクトからの構文プリミティブのマッピングをXMPP存在スタンザに定義します。
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]).
注：XMPP-CPIMゲートウェイは、カプセル化されたMIMEオブジェクトが「アプリケーション/PIDF XML」以外のコンテンツタイプを持っている「メッセージ/CPIM」オブジェクトをXMPPの存在にマッピングしてはなりません（マルチパートMIMEオブジェクトを除き、マルチパートMIMEオブジェクトを除き、[xmpp-e2e]で指定されています。
The 'From' header of a "Message/CPIM" object maps to the <user@host> portion of the 'from' attribute of an XMPP presence stanza, and the 'id' attribute of the PIDF <tuple/> child element maps to the resource identifier portion XMPP 'from' attribute. Therefore, to map the CPIM and PIDF information to the XMPP 'from' attribute, the gateway MUST remove the "im:" Instant Messaging URI scheme from the front of the address and MUST remove the CPIM "Formal-name" (if provided) in order to generate the <user@host> portion of the XMPP 'from' attribute, then add a '/' character followed by the value of the PIDF <tuple/> element's 'id' attribute.
「from」ヘッダー「message/cpim」オブジェクトのヘッダーは、xmpp存在の属性の「from」属性の<user@host>部分にマップされ、pidf <tuple/> child elementマップの「id」属性をマップします。リソース識別子への部分xmpp 'from'属性。したがって、CPIMおよびPIDF情報を「属性」からXMPP 'にマッピングするには、ゲートウェイは「IM：」インスタントメッセージングURIスキームをアドレスの前面から削除し、CPIM「フォーマル名」を削除する必要があります（提供されている場合）'属性からxmpp'の<user@host>部分を生成するには、 '/'文字を追加し、その後にpidf <tuple/> elementの 'id'属性の値を追加します。
Example: From Address Mapping
例：アドレスマッピングから
CPIM 'From' header
From: Romeo Montague <im:romeo@example.net>
XMPP 'from' attribute
<presence from='romeo@example.net'>
...
</presence>
Example: Resource Identifier Mapping
例：リソース識別子マッピング
XMPP 'from' attribute
<presence from='juliet@example.com/balcony'>
...
</presence>
PIDF 'id' for <tuple/>
<presence entity='pres:juliet@example.com'>
<tuple id='balcony'>
...
</tuple>
</presence>
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.
「メッセージ/CPIM」オブジェクトの「To」ヘッダーは、XMPPの存在スタンザの「to」属性にマップします。cpimを 'ヘッダーにxmpp'にマッピングするには、属性に、ゲートウェイは「im：」インスタントメッセージングuriスキームをアドレスの前面から削除し、cpim "formal-name"（提供されている場合）を削除する必要があります。GatewayがXMPPエンティティが使用しているリソース識別子の知識を持っている場合、ゲートウェイはリソース識別子をアドレスに追加する場合があります。
Example: To Address Mapping
例：マッピングに対処する
CPIM 'To' header
To: Juliet Capulet <im:juliet@example.com>
XMPP 'to' attribute
<presence to='juliet@example.com/balcony'>
...
</presence>
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.
Core XMPP仕様には、存在スタンザの「礼儀コピー」（非プリマリーの宛先）を指定するための構文は含まれていません。したがって、XMPP-CPIMゲートウェイが、「CC」ヘッダーを含むカプセル化されたPIDFオブジェクトを持つ「メッセージ/CPIM」オブジェクトを受信した場合、そのヘッダーに含まれる情報をXMPPレシピエントに渡すべきではありません。
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.
コアXMPP仕様には、スタンザが送信された存在データを指定するための構文は含まれていません。したがって、XMPP-CPIMゲートウェイが、「DateTime」ヘッダーを含むカプセル化されたPIDFオブジェクトを持つ「メッセージ/CPIM」オブジェクトを受信した場合、そのヘッダーに含まれる情報をXMPPレシピエントに渡すべきではありません。
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.
XMPPの存在スタンザには、「メッセージ/CPIM」オブジェクトの「サブジェクト」ヘッダーにマッピングできる情報は含まれていません。したがって、XMPP-CPIMゲートウェイが、「サブジェクト」ヘッダーを含むカプセル化されたPIDFオブジェクトを持つ「メッセージ/CPIM」オブジェクトを受信した場合、そのヘッダーに含まれる情報をXMPP受信者に渡すべきではありません。
"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レシピエントに渡さないでください。そのようなヘッダーのマッピングは定義されていません。
"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」オブジェクトには、オプションの「要求」ヘッダーが含まれる場合があります。XMPP-CPIMゲートウェイは、そのようなヘッダーをXMPPレシピエントに渡さないでください。そのようなヘッダーのマッピングは定義されていません。
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には、[MIME]で指定されているコンテンツID MIMEヘッダーに定義されているグローバルに一意のIDをキャプチャする要素または属性は含まれません。XMPP-CPIMゲートウェイがコンテンツIDを含むMIMEオブジェクトを受信した場合、Stanzaの「ID」属性の存在の値としてコンテンツIDを提供する場合がありますが、これはオプションです。
Example: Content-ID for Encapsulated Object
例：カプセル化されたオブジェクト用のContent-ID
MIME header
Content-ID: <123456789@example.net>
XMPP 'id' attribute (OPTIONAL)
<presence id='123456789@example.net'>
...
</presence>
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".
PIDFで定義されている基本的な存在ステータスタイプは、開いて閉じています。「タイプ」属性（デフォルトの可用性を示す）を持たないXMPP存在スタンザに対するオープンマップのPIDF基本的な存在ステータス。XMPPの存在マップのPIDF基本的な存在ステータスは、「Unabable」の値を持つ「タイプ」属性を備えたスタンザを備えています。
Example: OPEN Presence
例：オープンプレゼンス
PIDF basic presence (OPEN)
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:romeo@example.net'>
<tuple id='orchard'>
<status>
<basic>open</basic>
</status>
</tuple>
</presence>
XMPP available presence
<presence from='romeo@example.net/orchard'/>
Example: CLOSED Presence
例：閉じた存在
PIDF basic presence (CLOSED)
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
entity='pres:romeo@example.net'>
<tuple id='orchard'>
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
XMPP unavailable presence
<presence from='romeo@example.net/orchard'
type='unavailable'/>
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ドキュメントには、拡張<ステータス/>コンテンツが含まれる場合があります。この執筆時点では、XMPP <show/>要素（ 'away'、 'chat'、 'dnd'、 'xa'）の定義値にマッピングできる事前定義された拡張ステータス状態はありません。このような拡張ステータス状態のPIDF拡張機能がインターネット標準プロセス内で定義されると、ゲートウェイはそれらの拡張機能をマップする必要があります。ただし、関連するPIDF拡張機能がまだ定義されていないため、このようなマッピングはこのメモの範囲外です。
Example: Extended Status Information (provisional)
例：拡張ステータス情報（暫定）
PIDF extended presence information
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:im='urn:ietf:params:xml:ns:pidf:im'
entity='pres:romeo@example.net'>
<tuple id='orchard'>
<status>
<basic>open</basic>
<im:im>busy</im:im>
</status>
</tuple>
</presence>
XMPP <show/> element
<presence from='romeo@example.net/orchard'>
<show>dnd</show>
</presence>
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.
PIDF <Tuple/>要素には、送信者の詳細な可用性状態のユーザー定義の自然言語の説明を提供する<ノート/>子を含むことができます。pidf <note/>要素は、xmpp <status/>要素にマップします。
Example: Note Element
例：メモ要素
PIDF <note/> element
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:im='urn:ietf:params:xml:ns:pidf:im'
entity='pres:romeo@example.net'>
<tuple id='orchard'>
<status>
<basic>open</basic>
<im:im>busy</im:im>
</status>
<note>Wooing Juliet</note>
</tuple>
</presence>
XMPP <status/> element
<presence from='romeo@example.net/orchard'>
<show>dnd</show>
<status>Wooing Juliet</status>
</presence>
A PIDF document with zero tuples MAY contain one or more <note/> elements as direct children of the PIDF <presence/> element. There is no mapping of such a PIDF document to an XMPP presence stanza; an entity on the non-XMPP side of an XMPP-CPIM gateway SHOULD NOT send such a PIDF document to an XMPP recipient if possible, and an XMPP-CPIM gateway MUST NOT map such a PIDF document to an XMPP presence stanza (see Zero Resources (Section 6.3.2)).
ゼロタプルを備えたPIDFドキュメントには、PIDF <infaction/>要素の直接の子供として1つ以上の<注/>要素が含まれる場合があります。このようなPIDFドキュメントのマッピングはXMPPの存在スタンザにはマッピングはありません。XMPP-CPIMゲートウェイの非XMPP側のエンティティは、可能であればそのようなPIDFドキュメントをXMPP受信者に送信しないでください。XMPP-CPIMゲートウェイは、そのようなPIDFドキュメントをXMPPの存在スタンザにマッピングしてはなりません（ゼロリソースを参照してください（セクション6.3.2））。
A PIDF document may contain a <contact/> element specifying the URI of an address at which the principal can be contacted (e.g., an im:, tel:, or mailto: URI). The core XMPP specification does not include syntax for specifying the URI of a contact address, since the contact address is implicit in the 'from' attribute of the XMPP presence stanza. Therefore, if an XMPP-CPIM gateway receives a "Message/CPIM" object with encapsulated PIDF object that contains a <contact/> element, it SHOULD NOT pass the XML character data of the <contact/> element on to the XMPP recipient. (However, see Inclusion of Complete PIDF Document (Section 5.2.15) below.)
PIDFドキュメントには、プリンシパルに連絡できるアドレスのURIを指定する<contact/>要素が含まれている場合があります（例：im：、tel：、またはmailto：uri）。コアXMPP仕様には、連絡先アドレスのURIを指定するための構文は含まれていません。これは、連絡先アドレスがXMPPの存在スタンザの「From」属性に暗黙的であるためです。したがって、XMPP-CPIMゲートウェイが、<連絡先/>要素を含むカプセル化されたPIDFオブジェクトを持つ「メッセージ/CPIM」オブジェクトを受信した場合、XMPPレシピエントに<連絡先/>要素のXML文字データを渡すべきではありません。（ただし、以下の完全なPIDFドキュメント（セクション5.2.15）の含有を参照してください。）
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>
XMPP presence stanza
<presence from='romeo@example.net/orchard'/>
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/>要素の<contact/>子には、値がゼロから1つの間の小数の数値である（最大3桁の場所）「優先度」属性を所有している場合があります。この属性の値は、XMPPの存在スタンザの<優先度/>子要素にマッピングできます。XMPP-CPIMゲートウェイは、XMPP <Priority/>要素の負の値にPIDF優先度値をマッピングしてはなりません。XMPP-CPIMゲートウェイがこれらの値をマッピングする場合、XMPP <Priority> 0 </Priority>およびPIDF Priority = '1'としてPIDF Priority = '0'を<Priority> 127 </Priority>、中間値を適切にマッピングする必要がありますそれらが一意であるように（例：0.001から0.007からXMPP優先度1の間のPIDF優先順位、0.008から0.015からXMPP優先度2の間のPIDF優先順位、および0.992から0.999からXMPPの優先度126;例のみであり、正確なマッピングはXMPP-CPIMゲートウェイによって決定されることです）。
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.
Core XMPP仕様には、スタンザが送信された存在感のあるDateTimeまたはタイムスタンプを指定するための構文は含まれていません。したがって、XMPP-CPIMゲートウェイが、<タイムスタンプ/>要素を含むカプセル化されたPIDFオブジェクトを持つ「メッセージ/CPIM」オブジェクトを受信した場合、XMPPレシピエントに<タイムスタンプ/>要素のXML文字データを渡すべきではありません。
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要素は、XMPPの存在スタンザ構文にマッピングされません（例：<contact/>要素のXML文字データ）。ただし、XMPPクライアントは、ネイティブPIDFドキュメントを解析することにより、そのような情報を処理できる場合があります。これを可能にするために、XMPP-CPIMゲートウェイには、[XMPP-PIDF]で説明されているように、スタンザの存在の子要素として完全なPIDFドキュメントを含めることができます。XMPPクライアントがこの拡張データを理解していない場合、当然それを無視する必要があります。
[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構文を使用してGatewayの存在感サービスと対話できます。[PIDF]は購読などのセマンティック操作の構文を指定していないため、このセクションでは、このようなXMPP構文のPIDFへの翻訳ではなく、XMPP-CPIMゲートウェイによって提供される存在サービスとのXMPP相互作用のみを定義します。（注：XMPPプレゼンスサービスに関する詳細情報は[XMPP-IM]にあります。可能な限り、XMPP-CPIMゲートウェイは、そこに定義されている構文、セマンティクス、およびサーバービジネスルールを実装する必要があります。）
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プレゼンテーションの存在情報を購読したい場合、ターゲットプレゼンティに「サブスクライブ」タイプのスタンザを送信する必要があります。構文マッピングは次のとおりです。
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 XMPP 'from'属性（user@host）は、cpp "watcherパラメーター"フィールド（pres：user@host）にマッピングする必要があります。XMPP-CPIMゲートウェイは、「Pres： "Presence 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 XMPP 'to'属性（user@host）は、CPP "ターゲットパラメーター"フィールド（pres：user@host）にマッピングする必要があります。XMPP-CPIMゲートウェイは、「Pres： "Presence URIスキームをアドレスの前面に追加する必要があります。
o There is no XMPP mapping for the CPP "duration parameter", since XMPP subscriptions are active until they have been explicitly "unsubscribed".
o XMPPサブスクリプションは明示的に「登録解除」されるまでアクティブになるため、CPP「持続時間パラメーター」のXMPPマッピングはありません。
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" field.
o XMPP 'ID'属性は、CPP「TransID」フィールドにマッピングする必要があります。
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.
ターゲットプレゼンティがサブスクリプションリクエストを承認した場合（ゲートウェイと対話するために使用するプロトコルを介して）、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.
ターゲットの表示がサブスクリプション要求を拒否した場合、XMPP-CPIMゲートウェイはXMPPエンティティに「登録されていない」タイプの存在スタンザを返す必要があり、Notify操作を呼び出さないでください。
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 "" address）は、有効なプレゼンテーションを参照しません。この例外が発生した場合、XMPP-CPIMゲートウェイは<item-found/> stanzaエラーを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エンティティに<Forbidden/> Stanzaエラーを返す必要があります。
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エンティティとターゲットプレゼンテーションの間に、既存のサブスクリプションまたは進行中のサブスクライブ操作が存在します。この例外が発生した場合、XMPP-CPIMゲートウェイは<競合/>スタンザエラーを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-To-CPIMゲートウェイは、サブスクリプションが期限切れにならないように、XMPPエンティティに代わってそのようなリフレッシュを非XMPPエンティティに送信する必要がある場合があります。そのようなリフレッシュが必要かどうかは、ゲートウェイが翻訳しているCPIMが認識していない非XMPPサービスによって実装されるネイティブプロトコルによって異なります。
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: 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.
XMPP以外の提示がXMPP-CPIMゲートウェイを介してXMPPエンティティの存在情報を購読したい場合、サブスクリプションをリクエストするために使用するプロトコルを使用するプロトコルを使用する必要があります。ローカルアクセスルールの対象となると、ゲートウェイは、XMPP Watcher以外のXMPPエンティティに「サブスクライブ」の存在スタンザを送信する必要があります。構文マッピングは次のとおりです。OCPP「ウォッチャーパラメーター」フィールド（pres：user@host）は、 '属性（user@host）からxmpp'にマッピングする必要があります。XMPP-CPIMゲートウェイは、アドレスの前面から「pres：fresence 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：fresence URIスキームを削除する必要があります。
o There is no XMPP mapping for the CPP "duration parameter", since XMPP subscriptions are active until they have been explicitly "unsubscribed".
o XMPPサブスクリプションは明示的に「登録解除」されるまでアクティブになるため、CPP「持続時間パラメーター」のXMPPマッピングはありません。
o The CPP "TransID" field SHOULD be mapped to the XMPP 'id' attribute.
o CPP「TransID」フィールドは、XMPP 'ID'属性にマッピングする必要があります。
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エンティティがサブスクリプションリクエストを承認する場合、Watcherのプレゼンテーションに「サブスクライブ」タイプの存在スタンザを送信する必要があります。XMPP-CPIMゲートウェイは、ターゲットXMPPエンティティの現在の利用可能な存在のウォッチャーの提示を通知する必要があります。その後、サブスクリプションがキャンセルされるまで、ゲートウェイはターゲットの存在情報が変更されるたびにウォッチャーのプレゼンテーションに通知する必要があります。
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エンティティがサブスクリプションリクエストを拒否した場合、Watcherのプレゼンテーションに「登録されていない」タイプのスタンザを送信する必要があります。XMPP-CPIMゲートウェイは、Notify操作を呼び出さないでください。
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 "〜"アドレス）は、有効なXMPPエンティティを参照しません
o Access control rules do not permit the watcher presentity to subscribe to the target XMPP entity
o アクセス制御ルールは、ウォッチャーのプレゼンティがターゲットXMPPエンティティを購読することを許可しません
o There exists a pre-existing subscription or in-progress subscribe operation between the watcher presentity and the target XMPP entity
o ウォッチャーのプレゼンティとターゲットXMPPエンティティの間に、既存のサブスクリプションまたは進行中のサブスクライブ操作が存在します
If any of these exceptions occurs, the XMPP-CPIM gateway MUST inform the watcher presentity of failure.
これらの例外のいずれかが発生した場合、XMPP-CPIMゲートウェイは、ウォッチャーの障害の提示を通知する必要があります。
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サービスのエンティティから受信した場合、持続時間パラメーターを追跡し、その期間パラメーターが期限切れになった後にサブスクリプションを削除する場合があります。
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のプレゼンティの変更に関連する存在情報がいつでも、CPPの「通知操作」を呼び出し、ゲートウェイの反対側にその情報の加入者がいます。通知操作に関連する存在情報の構文マッピングは、存在マッピングの下で定義されています（セクション5）。
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には複数の存在「タプル」の概念が含まれています。通常、PIDFドキュメントには少なくとも1つのタプルが含まれますが、複数のタプル（またはゼロタプル、次のセクションを参照）が含まれる場合があります。XMPPの用語では、各タプルは別のリソースの存在情報にマッピングされます。ただし、XMPPには、存在情報を生成するリソースが存在スタンザの「From」アドレスに含まれているため、一度に複数のリソースに関する存在情報を送信する機能は含まれていません。したがって、プレゼンスサービスとして機能するXMPP-CPIMゲートウェイは、複数のタプルを複数のXMPPプレゼンススタンザに含むPIDFドキュメントを分割する必要があり、XMPPユーザーが現在複数の接続されたリソースを持っている場合、1つのPIDFドキュメント（複数のタプルを使用）のみを生成する必要があります。
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スタンザを必要に応じて増殖させないために、XMPP-CPIMゲートウェイは、PIDFタプルに含まれる存在情報がそのタプルIDに関連するデバイスまたはアプリケーションの可用性ステータスの変更を伝える場合にのみ、XMPP-CPIMゲートウェイを生成する必要があります。
In the interest of complying with the PIDF recommendation to provide information about multiple "resources" in multiple tuples rather than in multiple PIDF documents, an XMPP-CPIM gateway SHOULD include information about all of an XMPP user's resources in one PIDF document (with one tuple for each resource), even if the availability status of only one resource has changed.
複数のPIDFドキュメントではなく、複数のタプルで複数の「リソース」に関する情報を提供するためにPIDF推奨事項を遵守するために、XMPP-CPIMゲートウェイには、1つのPIDFドキュメントのすべてのXMPPユーザーのリソースに関する情報を含める必要があります（1つのタプル付きリソースごとに）は、1つのリソースのみの可用性ステータスが変更されていても。
A PIDF document may contain zero tuples. For example:
PIDFドキュメントには、ゼロタプルが含まれている場合があります。例えば：
PIDF Document with Zero Tuples
タプルがゼロのPIDFドキュメント
<presence entity='pres:juliet@example.com'
xmlns='urn:ietf:params:xml:ns:pidf'/>
Because (1) the 'entity' attribute of a PIDF <presence/> element maps to the <user@host> portion of an XMPP address and (2) the 'id' attribute of a PIDF <tuple/> element maps to the resource identifier portion of an XMPP address, a PIDF document that contains zero tuples would provide presence information about a <user@host> rather than a <user@host/resource> when mapped to XMPP. Although the notion of presence notifications about a mere user rather than one of the user's resources is nearly meaningless in the XMPP context, an XMPP-CPIM gateway SHOULD map a PIDF document with zero tuples to an XMPP presence stanza whose 'from' address is the user@host of the non-XMPP entity. However, an XMPP-CPIM gateway MUST NOT generate a PIDF document with zero <tuple/> children when receiving a presence stanza from an XMPP entity (i.e., all PIDF documents communicated by the gateway to a non-XMPP service MUST contain at least one <tuple/> element).
（1）XMPPアドレスの<user@host>部分へのpidf <infaction/>要素の「エンティティ」属性、および（2）pidf <tuple/>要素の「id」属性がXMPPアドレスのリソース識別子部分、ゼロタプルを含むPIDFドキュメントは、XMPPにマッピングしたときに<user@host/resource>ではなく、<user@host>に関する存在情報を提供します。ユーザーのリソースのいずれかではなく、単なるユーザーに関する存在通知の概念はXMPPコンテキストではほとんど意味がありませんが、XMPP-CPIMゲートウェイは、XMPP-CPIMゲートウェイをゼロタプルのPIDFドキュメントにXMPPのプレゼンススタンザにマッピングする必要があります。非XMPPエンティティのユーザー@ホスト。ただし、XMPP-CPIMゲートウェイは、XMPPエンティティから存在スタンザを受け取ったときにゼロ<Tuple/>子供を持つPIDFドキュメントを生成してはなりません（つまり、XMPP以外のサービスへのゲートウェイによって伝達されるすべてのPIDFドキュメントは、少なくとも1つを含める必要があります。<tuple/>要素）。
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-CPIMゲートウェイを介して非XMPPのプレゼンテーションの存在から登録解除したい場合、ターゲットプレゼンテーションに「登録解除」タイプのスタンザを送信する必要があります。構文マッピングは次のとおりです。
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 XMPP 'from'属性（user@host）は、cpp "watcherパラメーター"フィールド（pres：user@host）にマッピングする必要があります。XMPP-CPIMゲートウェイは、「Pres： "Presence 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 XMPP 'to'属性（user@host）は、CPP "ターゲットパラメーター"フィールド（pres：user@host）にマッピングする必要があります。XMPP-CPIMゲートウェイは、「Pres： "Presence URIスキームをアドレスの前面に追加する必要があります。
o The CPP "duration parameter" MUST be set to zero.
o CPP「持続時間パラメーター」はゼロに設定する必要があります。
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" field.
o XMPP 'ID'属性は、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 "" address）が有効なプレゼンテーションを参照していない場合、xmpp-cpimゲートウェイはxmppエンティティに<item-not-found/> stanzaエラーを返す必要があります。
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エンティティにさらなる存在通知を送信してはなりません。
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プレゼンティのサブスクリプションをキャンセルしたい場合、ターゲットプレゼンティに「登録されていない」タイプのスタンザを送信する必要があります。構文マッピングは次のとおりです。
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 XMPP 'from'属性（user@host）は、cpp "watcherパラメーター"フィールド（pres：user@host）にマッピングする必要があります。XMPP-CPIMゲートウェイは、アドレスの前面に「Pres： "Presence 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 XMPP 'to'属性（user@host）は、CPP "ターゲットパラメーター"フィールド（pres：user@host）にマッピングする必要があります。XMPP-CPIMゲートウェイは、アドレスの前面に「Pres： "Presence URIスキームを追加する必要があります。o CPP「持続時間パラメーター」をゼロに設定する必要があります。
o The XMPP 'id' attribute SHOULD be mapped to the CPP "TransID" field.
o XMPP 'ID'属性は、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ゲートウェイは、ウォッチャーのプレゼンティにさらなる存在通知を送信してはなりません。
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 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].
このドキュメントは、[CPIM]と[CPP]を実装するゲートウェイを介して、インスタントメッセージと存在情報を交換するための方法を指定します。このようなゲートウェイは、インスタントメッセージングおよび存在プロトコルの最小セキュリティ要件に準拠している必要があります。RFC 2779でのインスタントメッセージングと存在のセキュリティモデルへのゲートウェイの導入も、いくつかの新しいリスクをもたらします。特に、XMPP-CPIMゲートウェイを介してインターフェイスするインスタントメッセージングと存在ユーザーエージェントの間のエンドツーエンドのセキュリティプロパティ（特に機密性と整合性）は、一般的な形式がサポートされている場合にのみ提供できます。これらの形式は、[xmpp-e2e]で完全に指定されています。
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPIM]ピーターソン、J。、「インスタントメッセージングの共通プロファイル（CPIM）」、RFC 3860、2004年8月。
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[CPP]ピーターソン、J。、「存在の共通プロファイル（CPP）」、RFC 3859、2004年8月。
[IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[Imp-Model] Day、M.、Rosenberg、J。、およびH. Sugano、「存在感とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[Imp-reqs] Day、M.、Aggarwal、S.、Mohr、G。、およびJ. Vincent、「インスタントメッセージング /存在プロトコル要件」、RFC 2779、2000年2月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[MSGFMT] Klyne、G。およびD. Atkins、「Common Expention and Instantメッセージング（CPIM）：メッセージ形式」、RFC 3862、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] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「Presence Information Data Format（PIDF）」、RFC 3863、2004年8月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings (stringprep)", RFC 3454, December 2002.
[StringPrep] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（StringPrep）」、RFC 3454、2002年12月。
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[用語] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[URL-GUIDE] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.
[URL-Guide] Masinter、L.、Alvestrand、H.、Zigmond、D。、およびR. Petke、「新しいURLスキームのガイドライン」、RFC 2718、1999年11月。
[US-ASCII] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[US-ASCII] Cerf、V。、「ネットワークインターチェンジ用ASCII形式」、RFC 20、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、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[XMPP-CORE] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-Core] Saint-Andre、P.、ed。、「Extensibleメッセージングとプレゼンスプロトコル（XMPP）：Core」、RFC 3920、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.
[XMPP-E2E] Saint-Andre、P.、ed。、「拡張可能なメッセージと存在プロトコル（XMPP）におけるエンドツーエンドの署名とオブジェクト暗号化」、RFC 3923、2004年10月。
[XMPP-IM] Saint-Andre (ed.), P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[XMPP-IM] Saint-Andre（ed。）、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：インスタントメッセージングと存在」、RFC 3921、2004年10月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P.、ed。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[MIMETYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MimeTypes] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、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] Saint-Andre、P。、「拡張可能なメッセージ/フォーマット（PIDF）の拡張可能なメッセージと存在プロトコル（XMPP）を介して輸送」、2004年2月の作業。
Author's Address
著者の連絡先
Peter Saint-Andre Jabber Software Foundation
Peter Saint-Andre Jabber Software Foundation
EMail: stpeter@jabber.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。