Network Working Group P. Saint-Andre
Request for Comments: 3922 Jabber Software Foundation
Category: Standards Track October 2004
Mapping the Extensible Messaging and Presence Protocol (XMPP) to
Common Presence and Instant Messaging (CPIM)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（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.
このメモは、拡張メッセージングおよびプレゼンスプロトコル（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ファミリは、Instant Messaging [CPIM]（とも呼ばれるCPIM）のための共通プロファイル、プレゼンス[CPP]のための共通プロファイル、CPIMメッセージフォーマット[MSGFMT]、およびCommonプレゼンス情報データフォーマット[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-CORE]、[XMPP-IM]）は、主にXMPPサービスと非XMPPサービス間のゲートウェイを確立する目的のために、CPIM仕様に含まれる抽象モデルにマップする方法を説明します[IMP-REQS]に準拠しています。そのようなゲートウェイは、「XMPP - CPIMゲートウェイ」と呼ぶ、一つのサービスのプロトコルを解釈し、他のサービスのプロトコルに翻訳するために確立されてもよいです。次のように私たちは、この関係を可視化することができます。
+-------------+ +-------------+ +------------+
| | | | | |
| 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プロトコル間の変換をゲートウェイで使用するためのマッピングを定義します。そのようなゲートウェイは、（ネイティブフォーマットまたはCPIM仕様によって定義されていてもいなくてもよい）、非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]で定義された語彙を継承します。その中で定義されているようなCLOSED、INSTANT INBOX、インスタントメッセージ、OPEN、PRESENCEサービス、PRESENTITY、購読、および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、ノード識別子、ドメイン識別子、リソース識別子、MESSAGE STANZA、およびPRESENCE STANZAなどの用語は同じ意味で使用されています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "オプション" [用語]で説明されるように解釈されるべきです。
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つであると（XMLの固有の拡張は、アプリケーションが他の目的のために、これらのスタンザタイプの一般的なセマンティクスを使用することを可能にするが）しばしばIMユーザ間のインスタントメッセージおよびプレゼンス情報を交換するために使用されています。 XMPPは、[MIME]に基づくものではありません。代わりに、[XMPP-COREは、（例えば、メッセージスタンザの<BODY />子供は通常、人間のユーザによって読み取られることが意図されているXML文字データを含む）の両方のメッセージ及びプレゼンススタンザのための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仕様は、二つの[MIME]コンテンツタイプを介してインスタントメッセージングおよびプレゼンスのための一般的な形式を提供する：プレゼンス用のメッセージ（[MSGFMT]）は、「/ CPIMメッセージ」と「アプリケーション/ PIDF + XML」（[PIDF]）。 「メッセージ/ CPIM」オブジェクトの構文は、に似ているが[RFC2822]で定義されたものよりも厳しくなり、任意のMIMEメディアタイプ[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.
本明細書に取られたアプローチは、XMPP素子からのマッピングを指定することであり、[CPIM]と[CPP]によって定義された意味論に準拠するために、[MSGFMT]及び[PIDF]によって定義されたヘッダと、MIMEフォーマットに属性。当然のことながら、反対方向へのマッピングも同様に提供されます。
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-CORE]で指定された）瞬時受信トレイを識別するために使用されるものとは異なるXMPPエンティティを識別するために使用されるアドレスフォーマットので、必要とされ得る（IMを：[CPIM]で指定されたURIスキーム）とプレゼン（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.
以下の[US-ASCII]文字oをIMで許可されている：/ PRES：XMPPアドレスでのURIではなく、＃26; （＆）、＃27。 （ '）、および＃2F。 （/）。 O多くの非US-ASCII（具体的には、UTF-8）文字は、XMPPアドレスで許可されたがイムには使用できません：/ PRES：URIを、XMPPは国際ローカル部分のアドレスを可能にするので。
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:
またはPRES：以下は、ハイレベルのIMにXMPPアドレスをマッピングするためのアルゴリズムである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.（オプション）正規化するための（[XMPP-CORE]で指定されるように）STRINGPREP]のNodeprepプロファイルを適用
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ではない場合！$ *。？_〜+ = [URL-GUIDE]のセクション2.2.5で説明したように、その後％のhexhexに変更
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)
スキーム（XMPPのための<メッセージ/>スタンザ）または 'PRES：' スキーム（のためのXMPP <存在/>スタンザ）： 'IM' 6.プリペンド
The following is a high-level algorithm for mapping an im: or pres: URI to an XMPP address:
XMPPアドレスにURI：またはPRES：以下は、IMをマッピングするための高レベルのアルゴリズムです。
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]
[URL-GUIDE]のセクション2.2.5に記載したように3等価オクテット％のhexhex翻訳
6. Apply Nodeprep profile of [STRINGPREP] (as specified in [XMPP-CORE]) for canonicalization (OPTIONAL)
6.（オプション）正規化するための（[XMPP-CORE]で指定されるように）STRINGPREP]の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].
このセクションでは、ゲートウェイはXMPPサービスと[CPIM]によって定義されたインスタントメッセージのセマンティクスに準拠するためにカプセル化されたテキストコンテンツのベアラとして「メッセージ/ CPIM」オブジェクトを使用して、非XMPPサービスとの間でインスタントメッセージをマッピングする方法を記載しています。
This section defines the mapping of syntax primitives from XMPP message stanzas to "Message/CPIM" objects with encapsulated text content.
このセクションでは、カプセル化されたテキストの内容に「メッセージ/ CPIM」オブジェクトにスタンザXMPPメッセージから構文プリミティブのマッピングを定義します。
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 = 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".
「コンテンツ・タイプは、」「テキスト/平野」に設定しなければならなくて、文字セットは「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メッセージスタンザマップの属性「から」に「メッセージ/ CPIM」オブジェクトのヘッダ「」から。 XMPPには、送信者のサーバースタンプや「から」のアドレスと完全な<ユーザー@ホスト/リソース> [XMPP-CORE]で定義されている結合の認証とリソースの間に、クライアントとサーバとの間で交渉にその値を設定を検証します。したがってXMPP - CPIMゲートウェイは、送信者のXMPPサーバからフォーム<ユーザ@ホスト/リソース>のアドレス「から」を含むメッセージスタンザを受信します。の前部にインスタントメッセージURIスキーム：「メッセージ/ CPIM」オブジェクトのヘッダ「から」、ゲートウェイは「IM」を追加する必要があり、リソース識別子を削除する必要がありするXMPPメッセージスタンザの属性「から」マッピングします（既知の場合）のアドレスは、送信者のためのCPIM「正式名」を含むかもしれません。
Example: From Address Mapping
例：アドレスマッピングから、
XMPP 'from' attribute <message from='juliet@example.com/balcony'> ... </message>
属性<メッセージfrom='juliet@example.com/balcony '> ... </メッセージ> '' からXMPP
CPIM 'From' header From: Juliet Capulet <im:juliet@example.com>
ジュリエットキャピュレット<イム：juliet@example.com>からヘッダ「から」CPIM
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).
「メッセージ/ CPIM」オブジェクトの「に」ヘッダにXMPPメッセージスタンザマップの属性「」へ。 XMPPでは、送信者はメッセージスタンザの「と」属性を含むべきである、とのメッセージが別のユーザに配信するために意図されている場合、それを含まなければなりません。したがってXMPP - CPIMゲートウェイは、送信者のXMPPサーバからフォーム<ユーザ@ホスト>または<ユーザ@ホスト/リソース>の「に」アドレスを含むメッセージスタンザを受信します。インスタントメッセージURIスキーム：（含まれる場合）「メッセージ/ CPIM」の「に」ヘッダにXMPPメッセージスタンザの「に」属性をマップするオブジェクト、ゲートウェイは「IM」を追加する必要があり、リソース識別子を削除する必要がありますアドレスの前に、及び（既知の場合）受信者のCPIM「正式名」を含むかもしれません。
Example: To Address Mapping
例：マッピングに対処するために
XMPP 'to' attribute <message to='romeo@example.net/orchard'> ... </message>
属性<メッセージto='romeo@example.net/orchard '> ... </メッセージ> 'から' XMPP
CPIM 'To' header To: Romeo Montague <im:romeo@example.net>
CPIM「から」ヘッダーへ：ロミオモンタギュー<イム：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メッセージスタンザは、トラッキングスタンザのために送信するアプリケーションによって使用され、MIMEコンテンツ-IDヘッダで定義されるようなグローバルに一意な識別子ではない「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メッセージスタンザは、メッセージの会話コンテキストをキャプチャするために送信するアプリケーションによって使用される「タイプ」属性を有することができます。 「メッセージ/ 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メッセージスタンザは、メッセージが置かれている会話スレッドを指定するには、<スレッド/>子要素を含むかもしれません。 「メッセージ/ CPIM」ヘッダー、共通MIME機能、またはカプセル化されたテキストコンテンツにXMPP <スレッド/>要素のないマッピングは存在しません。スタンザXMPP - CPIMゲートウェイによって受信されたXMPPメッセージは<スレッド/>子要素が含まれている場合したがって、ゲートウェイが提供された値を無視すべきです。
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」オブジェクトの「件名」ヘッダのXMPP <被験者/>要素をマッピングするために、ゲートウェイは、単にの値に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.
「件名」ヘッダ。対象が書かれている言語を指定する属性：<件名/>要素は、「LANGのxml」を含むかもしれません。 「XML：langの」場合属性が提供され、それが含むことによってマッピングされなければならない「; LANG =タグ」「タグ」「は、XML：langの」の値であり、ヘッダ名とコロンの後、属性。
Example: Subject Mapping
例：件名のマッピング
XMPP <subject/> element <subject>Hi!</subject> <subject xml:lang='cz'>Ahoj!</subject>
XMPP <件名/>要素<対象>こんにちは</サブジェクト> <サブジェクトのxml：LANG = 'CZ'>！！Ahoj </対象>
CPIM 'Subject' header Subject: Hi! Subject:;lang=cz Ahoj!
CPIM "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のXML文字データ<ボディ/>要素には、カプセル化されたテキストメッセージの内容にマッピングされます。
Example: Message Body
例：メッセージ本文
XMPP message <body/> <message> <body>Wherefore art thou, Romeo?</body> </message>
XMPPメッセージ<ボディ/> <メッセージ> <身体>芸術それゆえ汝、ロミオ？</ BODY> </メッセージ>
Encapsulated MIME text content Content-type: text/plain; charset=utf-8 Content-ID: <123456789@example.net>
カプセル化されたMIMEテキストコンテンツのコンテンツタイプ：テキスト/平野。文字セット= UTF-8のContent-ID：<123456789@example.net>
Wherefore art thou, Romeo?
芸術のthou、ロミオ何のために？
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メッセージスタンザは、補足またはコアメッセージスタンザのセマンティクスを拡張するために、任意の名前空間内の「拡張」コンテンツを含むことができます。 [XMPP-E2E]で定義されるように、XMPP - CPIMゲートウェイはゲートウェイを介して渡し、そのような情報を無視してはならない名前空間「XMPP-E2E：IETF：paramsは：XML：NS URN」によって修飾拡張情報を除いて目的の受信者へ。そのような情報のマッピングが定義されていません。
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をメッセージの「礼儀コピー」（すなわち、非プライマリ宛先）を受信するエンティティのアドレスを指定 - メッセージがNS oを送信された日時を指定 - 指定します機能拡張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.
このセクションでは、XMPPメッセージスタンザにencapsualtedテキストコンテンツと「メッセージ/ 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メッセージスタンザの属性「から」に「メッセージ/ CPIM」オブジェクトマップのヘッダ「」から。アドレスの前方からインスタントメッセージURIスキーム及び（提供される場合）CPIM「正式名」を削除する必要があります属性「から」XMPPにヘッダ「」からCPIMをマッピングするために、ゲートウェイは「IM」を削除する必要があります。
Example: From Address Mapping
例：アドレスマッピングから、
CPIM 'From' header From: Romeo Montague <im:romeo@example.net>
ロミオモンタギュー<イム：romeo@example.net>からヘッダ「から」CPIM
XMPP 'from' attribute <message from='romeo@example.net'> ... </message>
属性<メッセージfrom='romeo@example.net '> ... </メッセージ> '' からXMPP
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メッセージスタンザの属性「」への「メッセージ/ CPIM」オブジェクトマップのヘッダ「と」。アドレスの前方からインスタントメッセージURIスキームとCPIMを削除する必要があります：属性「」のXMPPにヘッダ「と」CPIMをマッピングするために、ゲートウェイは「IM」を削除しなければなりません
"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エンティティによって使用中のリソース識別子の知識を有している場合、ゲートウェイアドレスにリソース識別子を追加してもよい（MAY）。
Example: To Address Mapping
例：マッピングに対処するために
CPIM 'To' header To: Juliet Capulet <im:juliet@example.com>
CPIM「から」ヘッダーへ：ジュリエットキャピュレット<イム：juliet@example.com>
XMPP 'to' attribute <message to='juliet@example.com/balcony'> ... </message>
属性<メッセージto='juliet@example.com/balcony '> ... </メッセージ> 'から' XMPP
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.
コアXMPP仕様はメッセージスタンザが送信された日時を指定するための構文が含まれていません。 XMPP - CPIMゲートウェイは「日時」ヘッダを含む「メッセージ/ 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.
「メッセージ/ CPIM」の「件名」ヘッダXMPPメッセージスタンザの<主題/>子要素にマップオブジェクト。 XMPP <被験者/>要素にCPIM「件名」ヘッダをマッピングするために、ゲートウェイは単にXMPP <被験者/>要素のXML文字データに「件名」ヘッダの値をマップする必要があります。 「件名」ヘッダは、被験体が書き込まれた「langの」を指定するかもしれません。 <主題/>要素の属性、「XML：langの」の値属性が「文字列で供給される「タグ」の値である：「langの」情報が提供されている場合、それはLANG XML 'にマッピングされなければなりません; langは=タグ件名 『ヘッダ名とコロン」CPIM後含ま』。
Example: Subject Mapping
例：件名のマッピング
CPIM 'Subject' header Subject: Hi! Subject:;lang=cz Ahoj!
CPIM "Subjectのヘッダー件名：こんにちは！件名：; LANG = CZ Ahoj！
XMPP <subject/> element <subject>Hi!</subject> <subject xml:lang='cz'>Ahoj!</subject>
XMPP <件名/>要素<対象>こんにちは</サブジェクト> <サブジェクトのxml：LANG = 'CZ'>！！Ahoj </対象>
"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.
「メッセージ/ CPIM」オブジェクトは、必須の対を認識する機能を指定するオプションの「要求」ヘッダを含むかもしれません。 （1）受信側アプリケーションは、特定のヘッダ又は（2）で指定された機能を理解する必要があることを主張し、一般に、そのようなヘッダが非XMPP送信アプリケーションに含まれるであろういくつかの非ヘッダセマンティクスによって実装される必要があることを示しメッセージ（例えば、「Locale.MustRenderKanji」）の内容を理解するために、受信側アプリケーション。必須ツー認識機能はXMPP受信アプリケーションではなく、XMPP - CPIMゲートウェイ自体に要求されるため、ゲートウェイが正しくXMPP受信アプリケーションの機能に関する詳細な知識なしにヘッダを「要求」を扱うことができません。従って、「メッセージ/ CPIM」オブジェクト内のヘッダを「必要」、それは、1つまたは複数を含む場合XMPP - CPIMゲートウェイが非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]で指定されるようにContent-ID MIMEヘッダの定義されたとおりでグローバルに一意なIDを捕捉要素または属性が含まれていません。 XMPP - CPIMゲートウェイがContent-IDを含んでいるMIMEオブジェクトを受信した場合、それはメッセージスタンザの「ID」属性の値としてContent-IDを提供することができるが、これは任意です。
Example: Content-ID for Encapsulated Object
例：カプセル化されたオブジェクトのためのContent-ID
MIME header Content-ID: <123456789@example.net>
MIMEヘッダのContent-ID：<123456789@example.net>
XMPP 'id' attribute (OPTIONAL) <message id='123456789@example.net'> ... </message>
XMPP 'ID' 属性（オプション）<メッセージid='123456789@example.net '> ... </メッセージ>
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テキストコンテンツのコンテンツタイプ：テキスト/平野。文字セット= UTF-8のContent-ID：<123456789@example.net>
Wherefore art thou?
それゆえアートなた？
XMPP message <body/> <message id='123456789@example.net'> <body>Wherefore art thou?</body> </message>
アート何のためにXMPPメッセージ<ボディ/> <メッセージid='123456789@example.net '> <身体>汝？</ BODY> </メッセージ>
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.
コンテンツタイプが「text / plainの」でない場合は、XMPP - CPIMゲートウェイは、XMPPの拡張にコンテンツをマッピングすることができるが、それをマッピングしてはならないの<body /> XMLを含有させることXMPPメッセージスタンザの子文字データのみ。このルールの唯一の例外は、そのメモに記載されるようにマッピングされる[XMPP-E2E]で指定された種類のマルチパートMIMEオブジェクトです。
If the charset is "US-ASCII" or "UTF-8", the gateway MUST map the "Message/CPIM" object; otherwise it SHOULD NOT.
文字セットは「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].
このセクションでは、ゲートウェイは、[CPPによって定義されたプレゼンスセマンティクスに準拠するためにカプセル化された[PIDF】オブジェクトのベアラとして「メッセージ/ 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.
このセクションでは、カプセル化された「アプリケーション/ PIDF + XML」オブジェクトとの「メッセージ/ CPIM」オブジェクトをスタンザXMPP存在から構文プリミティブのマッピングを定義します。
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オブジェクトの既定のコンテンツタイプは、 "コンテンツタイプ：テキスト/平野;のcharset = US-ASCII"。 XMPPは、専ら[UTF-8]文字エンコーディングを使用し、PIDFは、「アプリケーション/ PIDF + XML」MIMEタイプを指定するため、プレゼンス情報をXMPP - CPIMゲートウェイによって生成されたカプセル化されたMIMEオブジェクトは、「コンテンツタイプ」ヘッダを設定しなければならないためそのオブジェクトの。 「コンテンツ・タイプは、」「アプリケーション/ PIDF + XML」に設定しなければならなくて、文字セットは「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).
「メッセージ/ CPIM」オブジェクトのヘッダ「から」へのXMPP存在スタンザマップの属性「から」。 XMPPには、送信者のサーバースタンプや「から」のアドレスと[XMPP-CORE]で定義されている結合の認証とリソースの間に、クライアントとサーバー間でネゴシエート<ユーザー@ホスト/リソース>にその値を設定を検証します。したがって、XMPP - CPIMゲートウェイは、送信者のXMPPサーバーからフォーム<ユーザー@ホスト/リソース>のアドレス「から」を含むプレゼンススタンザを受け取ることになります。の前部にインスタントメッセージURIスキーム：「メッセージ/ CPIM」のヘッダ「から」オブジェクトにXMPP存在スタンザの属性「から」マッピングするために、ゲートウェイは、リソース識別子を削除する必要があり、「IM」を追加する必要があります（既知の場合）のアドレスは、送信者のためのCPIM「正式名」を含むかもしれません。
Example: From Address Mapping
例：アドレスマッピングから、
XMPP 'from' attribute <presence from='juliet@example.com/balcony'> ... </presence>
属性<存在from='juliet@example.com/balcony '> ... </プレゼンス> '' からXMPP
CPIM 'From' header From: Juliet Capulet <im:juliet@example.com>
ジュリエットキャピュレット<イム：juliet@example.com>からヘッダ「から」CPIM
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存在スタンザマップの属性「から」PIDFの「エンティティの属性に<存在/>ルート要素。 PIDF「エンティティの属性に属性「から」XMPPをマップするには、ゲートウェイは、リソース識別子を削除する必要がありますし、「PRES：」を追加しなければならないアドレスの前にインスタントメッセージングURIスキームを。
Example: From Address Mapping (PIDF)
例：アドレスマッピングから（PIDF）
XMPP 'from' attribute <presence from='juliet@example.com/balcony'> ... </presence>
属性<存在from='juliet@example.com/balcony '> ... </プレゼンス> '' からXMPP
PIDF 'entity' attribute <presence entity='pres:juliet@example.com'> ... </presence>
PIDF '実体' 属性<プレゼンスエンティティ= 'PRES：juliet@example.com'> ... </プレゼンス>
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ゲートウェイはPIDF <タプル/>子要素の「ID」属性に属性「から」XMPPに含まれるXMPPアドレスのリソース識別子をマップする必要があります。
Example: Resource Identifier Mapping
例：リソース識別子のマッピング
XMPP 'from' attribute <presence from='juliet@example.com/balcony'> ... </presence>
属性<存在from='juliet@example.com/balcony '> ... </プレゼンス> '' からXMPP
PIDF 'id' for <tuple/> <presence entity='pres:juliet@example.com'> <tuple id='balcony'> ... </tuple> </presence>
<タプル/>のためのPIDF 'ID' <プレゼンスエンティティ= 'PRES：juliet@example.com'> <タプルID = 'バルコニー'> ... </タプル> </プレゼンス>
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).
「メッセージ/ CPIM」オブジェクトの「から」ヘッダにXMPP存在スタンザマップの属性「から」。 XMPPでは、送信者が存在スタンザの「から」属性を含むことができ、プレゼンススタンザは（放送のために意図プレゼンススタンザは、送信者によって「から」のアドレスがスタンプされている別のユーザーへの直接送達するために意図されている場合、それを含まなければなりませんサーバ）。したがってXMPP - CPIMゲートウェイは、送信者のXMPPサーバからフォーム<ユーザ@ホスト>または<ユーザ@ホスト/リソース>の「に」アドレスを含むプレゼンススタンザを受け取ります。インスタントメッセージURIスキーム：（含まれる場合）「メッセージ/ CPIM」の「に」ヘッダにXMPP存在スタンザの「に」属性をマップすることは、オブジェクト、ゲートウェイは「IM」を追加する必要があり、リソース識別子を削除する必要がありますアドレスの前に、及び（既知の場合）受信者のCPIM「正式名」を含むかもしれません。
Example: To Address Mapping
例：マッピングに対処するために
XMPP 'to' attribute <presence to='romeo@example.net/orchard'> ... </presence>
属性<存在to='romeo@example.net/orchard '> ... </プレゼンス> 'から' XMPP
CPIM 'To' header To: Romeo Montague <im:romeo@example.net>
CPIM「から」ヘッダーへ：ロミオモンタギュー<イム：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存在スタンザトラッキングスタンザのために送信するアプリケーションによって使用され、MIMEコンテンツ-IDヘッダで定義されるようなグローバルに一意な識別子ではない「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存在スタンザは、「タイプ」属性を有することができます。ノー「タイプ」属性が含まれている場合は、プレゼンススタンザは、送信者が利用可能であることを示します。この状態は、OPENのPIDF基本的なプレゼンスタイプにマップされます。 「タイプ」属性が「利用不可」の値を持っている場合は、プレゼンススタンザは、送信者が使用できなくなったことを示していません。この状態はCLOSEDのPIDF基本的なプレゼンスタイプにマップされます。したがって、「利用不可」の値に設定「タイプ」属性と「タイプ」属性が存在しないことの両方が[CPP]「操作を通知する」に相当します。他のすべての存在のタイプは、現在のプレゼンスのプレゼンスサブスクリプションまたはプローブを管理するために使用されています。これらの他のプレゼンス・タイプのマッピングは、プレゼンスサービスとしてXMPP - CPIMゲートウェイ（セクション6）の下に定義されています。
Example: Available Presence
例：使用可能なプレゼンス
XMPP available presence <presence from='juliet@example.com/balcony'/>
XMPP可能なプレゼンス<プレゼンス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基本的なプレゼンス（OPEN）<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？> <プレゼンスのxmlns = '壷：IETF：のparams：XML：NS：PIDF' 実体= 'PRES：juliet@example.com 「>
<tuple id='balcony'> <status> <basic>open</basic> </status> </tuple> </presence>
<タプルID = 'バルコニー'> <状態> <基本>開く</塩基性> </状態> </タプル> </プレゼンス>
Example: Unavailable Presence
例：使用不可のプレゼンス
XMPP unavailable presence <presence from='juliet@example.com/balcony' type='unavailable'/>
XMPP使用できない存在<プレゼンスfrom='juliet@example.com/balcony」タイプ= '使用できません' />
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基本的なプレゼンス（CLOSED）<？XMLバージョン= '1.0' エンコード= 'UTF-8'？> <プレゼンスのxmlns = 'URN：IETF：paramsは：XML：NS：PIDF' エンティティ= 'PRES：romeo@example.net '> <タプルID =' バルコニー '> <状態> <基本> </塩基性> </状態> </タプル> </存在閉じ>
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存在スタンザの<ショー/>子要素は、送信者の利用可能性に関する追加情報を提供します。 PIDFで拡張<状態/>コンテンツへのXMPP <ショー/>要素マップのXML文字データ。 <ショー/>要素の定義された値は、「XAを」、「チャット」「DND」、および「離れ」であり、すぐに値が拡張された状態での状態のために指定されているとして「URN：IETF：のparams：XML：NS：PIDF：イム」名前空間、XMPP値はPIDF値にマッピングされます。
Example: Show Element
例：表示要素
XMPP <show/> element <presence from='juliet@example.com/balcony'> <show>away</show> </presence>
XMPP <ショー/>要素<プレゼンスfrom='juliet@example.com/balcony '> <ショー>離れて</ショー> </プレゼンス>
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>
<？XMLバージョン= '1.0' エンコード= 'UTF-8'？> PIDF拡張プレゼンス情報<プレゼンスのxmlns = 'URN：IETF：paramsは：XML：NS：PIDF' のxmlns：IM = 'URN：IETF：paramsは：XML ：NS：PIDF：IM」エンティティ= 'PRES：juliet@example.com'> <タプルID = 'バルコニー'> <状態> <基本>開く</基本>
<im:im>away</im:im> </status> </tuple> </presence>
<IM：IM>離れて</ IM：IM> </状態> </タプル> </プレゼンス>
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存在スタンザの<状態/>子要素は、送信者の詳細な可用性状態のユーザ定義、自然言語記述を提供します。 XMPP <状態/>要素は、PIDF <タプル/>要素のPIDF <ノート/>子にマップされます。
Example: Status Element
例：Status要素
XMPP <status/> element <presence from='juliet@example.com/balcony'> <show>away</show> <status>retired to the chamber</status> </presence>
XMPP <状態/>要素<プレゼンスfrom='juliet@example.com/balcony '> <ショー>離れて</ショー> <状態>室</状態> </プレゼンス>に引退
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 <ノート/>要素<プレゼンスのxmlns = '壷：IETF：のparams：XML：NS：PIDF' <XMLバージョン= '1.0' エンコーディング= 'UTF-8'？>のxmlns：イム= 'URN：IETF：のparams ：XML：NS：PIDF：IM」エンティティ= 'PRES：juliet@example.com'> <タプルID = 'バルコニー'> <状態> <基本>開く</塩基性> <IM：IM>離れて</ IM： IM> </状態> <注意> </注意> </タプル> </プレゼンス室に引退>
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 <タプル/>要素の<接触/>子供の「優先順位」属性にマッピングされてもよいです。 XMPPの値が<優先/>要素が負の場合、XMPP - CPIMゲートウェイは、値をマップしてはいけません。 PIDF「優先順位」属性の許容値の範囲は、小数点以下3桁の最大で、ゼロからの包括的な1に任意の10進数です。 XMPP - CPIMゲートウェイがこれらの値をマッピングする場合PIDF優先= '1' は、中間値をマッピングするように、PIDF優先= '0' とXMPP <優先度> 127 </優先>としてXMPP <優先度> 0 </優先度を>扱うべきですそれらはPIDF優先0.015 PIDF優先度0.007、XMPP優先度2にXMPP優先順位1、例えば（ユニークであるので、最大マッピングXMPP優先度126を介してPIDF優先度0.992に適切になるように、これは一例であり、そのことに注意してください正確なマッピング）がXMPP - CPIMゲートウェイによって決定されなければなりません。
Example: Presence Priority
例：プレゼンスの優先順位
XMPP <status/> element <presence from='juliet@example.com/balcony'> <priority>13</priority> </presence>
XMPP <状態/>要素<プレゼンスfrom='juliet@example.com/balcony '> <優先度> 13 </優先> </プレゼンス>
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 <ノート/>要素<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？> <プレゼンスのxmlns = '壷：IETF：のparams：XML：NS：PIDF' 実体= 'PRES：juliet@example.com '> <タプルID =' バルコニー '> ... <接触優先=' 0.102' > IM：juliet@example.com </接触> </タプル> </プレゼンス>
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存在スタンザは、補足またはコア存在スタンザのセマンティクスを拡張するために、任意の名前空間内の「拡張」コンテンツを含むことができます。 [XMPP-E2E]で定義されるように、XMPP - CPIMゲートウェイはゲートウェイを介して渡し、そのような情報を無視してはならない名前空間「XMPP-E2E：IETF：paramsは：XML：NS URN」によって修飾拡張情報を除いて目的の受信者へ。そのような情報のマッピングが定義されていません。
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 presence information (i.e., a non-primary addressee)
O CCは - プレゼンス情報の「好意コピー」（すなわち、非プライマリ宛先）を受信するエンティティのアドレスを指定します
o DateTime -- specifies the datetime at which the presence information was sent
O日時は - プレゼンス情報が送信された日時を指定します
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要素の存在を指定するが、コア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 <接触が/> - アドレスを指定する（例えば、IM :, TEL :,またはのmailto：URI）をプレゼンティティと通信することができる一方において、インスタントメッセージングURIスキーム：XMPP-CPIMゲートウェイは、それが「イム」で先頭に追加XMPP送信者の<ユーザー@ホスト>にその値を設定する必要があり、その場合には、この要素を含んでいてもよいです。
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 <タイムスタンプ/> - プレゼンス情報が送信された日時を指定します。 XMPP - CPIMゲートウェイは、独立して、自身の情報（例えば、それがXMPPエンティティからプレゼンススタンザを受信した日時）に基づいて、または非コアXMPP拡張でエンコードされたデータに基づいて、この要素を生成することができ、しかし、そうするためのルールでありますこのメモの範囲外。
This section defines the mapping of syntax primitives from "Message/CPIM" objects with encapsulated "application/pidf+xml" objects to XMPP presence stanzas.
このセクションでは、XMPP存在スタンザにカプセル化された「アプリケーション/ PIDF + XML」オブジェクトと「メッセージ/ CPIM」オブジェクトから構文プリミティブのマッピングを定義します。
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オブジェクトは、マルチパートMIMEオブジェクトを除いて（「アプリケーション/ PIDF + XML」以外のコンテンツ・タイプを有する「メッセージ/ CPIM」オブジェクトスタンザXMPP存在にマップしてはいけませんで指定されるように[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.
XMPP存在スタンザの属性、およびPIDF <タプル/>子要素マップの「ID」属性「から」の<ユーザ@ホスト>部分に「メッセージ/ CPIM」オブジェクトマップのヘッダ「」から属性「から」資源識別子部分XMPPへ。アドレスの前方からインスタントメッセージURIスキーム及び（提供される場合）CPIM「正式名」を削除する必要があります。そのため、属性「から」XMPPにCPIM PIDFと情報をマッピングするために、ゲートウェイは「IM」を削除しなければなりません属性「から」XMPPの<user @ host>の部分を生成するために、その後、PIDF <タプル/>要素の「ID」属性の値が続く「/」文字を追加します。
Example: From Address Mapping
例：アドレスマッピングから、
CPIM 'From' header From: Romeo Montague <im:romeo@example.net>
ロミオモンタギュー<イム：romeo@example.net>からヘッダ「から」CPIM
XMPP 'from' attribute <presence from='romeo@example.net'> ... </presence>
属性<存在from='romeo@example.net '> ... </プレゼンス> '' からXMPP
Example: Resource Identifier Mapping
例：リソース識別子のマッピング
XMPP 'from' attribute <presence from='juliet@example.com/balcony'> ... </presence>
属性<存在from='juliet@example.com/balcony '> ... </プレゼンス> '' からXMPP
PIDF 'id' for <tuple/> <presence entity='pres:juliet@example.com'> <tuple id='balcony'> ... </tuple> </presence>
<タプル/>のためのPIDF 'ID' <プレゼンスエンティティ= 'PRES：juliet@example.com'> <タプルID = 'バルコニー'> ... </タプル> </プレゼンス>
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.
XMPP存在スタンザの属性「から」への「メッセージ/ CPIM」オブジェクトマップのヘッダ「から」。アドレスの前方からインスタントメッセージURIスキーム及び（提供される場合）CPIM「正式名」を削除する必要があります属性「」のXMPPにヘッダ「と」CPIMをマッピングするために、ゲートウェイは「IM」を削除する必要があります。ゲートウェイはXMPPエンティティによって使用中のリソース識別子の知識を有している場合、ゲートウェイアドレスにリソース識別子を追加してもよい（MAY）。
Example: To Address Mapping
例：マッピングに対処するために
CPIM 'To' header To: Juliet Capulet <im:juliet@example.com>
CPIM「から」ヘッダーへ：ジュリエットキャピュレット<イム：juliet@example.com>
XMPP 'to' attribute <presence to='juliet@example.com/balcony'> ... </presence>
属性<存在to='juliet@example.com/balcony '> ... </プレゼンス> 'から' XMPP
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.
コアXMPP仕様は存在スタンザのために、「礼儀コピー」（非プライマリ宛先）を指定するための構文が含まれていません。 XMPP - CPIMゲートウェイが「メッセージ/ CPIM」「CC」ヘッダが含まれているカプセル化PIDFオブジェクトとオブジェクトを受信した場合、したがって、それは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ゲートウェイは「日時」ヘッダが含まれているカプセル化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ゲートウェイが「メッセージ/ CPIM」「件名」ヘッダが含まれているカプセル化PIDFオブジェクトとオブジェクトを受信した場合、したがって、それは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.
「メッセージ/ 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]で指定されるようにContent-ID MIMEヘッダの定義されたとおりでグローバルに一意なIDを捕捉要素または属性が含まれていません。 XMPP - CPIMゲートウェイは、Content-IDを含んでいるMIMEオブジェクトを受信した場合、それが存在スタンザの「ID」属性の値としてContent-IDを提供することができるが、これはオプションです。
Example: Content-ID for Encapsulated Object
例：カプセル化されたオブジェクトのためのContent-ID
MIME header Content-ID: <123456789@example.net>
MIMEヘッダのContent-ID：<123456789@example.net>
XMPP 'id' attribute (OPTIONAL) <presence id='123456789@example.net'> ... </presence>
XMPP 'ID' 属性（オプション）<存在id='123456789@example.net '> ... </プレゼンス>
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で定義された基本的なプレゼンスステータスの種類には、OPENおよびCLOSEDです。 （デフォルトの利用可能性を示す）は、「タイプ」属性を持っていないXMPP存在スタンザにOPENマップのPIDF基本的なプレゼンスステータス。 「利用不可」の値を「タイプ」属性を所有XMPP存在スタンザにCLOSEDマップのPIDF基本的なプレゼンスステータス。
Example: OPEN Presence
例：OPENプレゼンス
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基本的なプレゼンス（OPEN）<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？> <プレゼンスのxmlns = '壷：IETF：のparams：XML：NS：PIDF' 実体= 'PRES：romeo@example.net '> <タプルID =' 果樹園 '> <状態> <基本> </塩基性> </状態> </タプル> </プレゼンスオープン>
XMPP available presence <presence from='romeo@example.net/orchard'/>
XMPP可能なプレゼンス<プレゼンスfrom='romeo@example.net/orchard '/>
Example: CLOSED Presence
例：CLOSEDプレゼンス
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基本的なプレゼンス（CLOSED）<？XMLバージョン= '1.0' エンコード= 'UTF-8'？> <プレゼンスのxmlns = 'URN：IETF：paramsは：XML：NS：PIDF' エンティティ= 'PRES：romeo@example.net '> <タプルID =' 果樹園 '> <状態> <基本> </塩基性> </状態> </タプル> </存在閉じ>
XMPP unavailable presence <presence from='romeo@example.net/orchard' type='unavailable'/>
XMPP使用できない存在<プレゼンスfrom='romeo@example.net/orchard」タイプ= '使用できません' />
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 <ショー/>要素の定義された値にマッピングすることができない事前定義された拡張ステータス状態が存在しない（「離れて」は、「チャット」、「サイレント」、および「XA」）。そのような拡張ステータス状態のPIDF拡張がインターネットStandardsプロセス内で定義されると、ゲートウェイは、これらの拡張子をマップする必要があります。関連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>
<？XMLバージョン= '1.0' エンコード= 'UTF-8'？> PIDF拡張プレゼンス情報<プレゼンスのxmlns = 'URN：IETF：paramsは：XML：NS：PIDF' のxmlns：IM = 'URN：IETF：paramsは：XML ：NS：PIDF：イム」実体= 'PRES：romeo@example.net'> <タプルID = '果樹園'> <状態> <基本>開く</基本> <IM：IM>忙しい</ IM：IM> </ステータス> </タプル> </プレゼンス>
XMPP <show/> element <presence from='romeo@example.net/orchard'> <show>dnd</show> </presence>
XMPP <ショー/>要素<プレゼンスfrom='romeo@example.net/orchard '> <ショー> DND </示して> </プレゼンス>
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 <タプル/>要素には、送信者の詳細な可用性状態のユーザ定義、自然言語記述を提供<ノート/>子供が含まれていてもよいです。 PIDF <ノート/>要素は、XMPP <状態/>要素にマップされます。
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 <ノート/>要素<プレゼンスのxmlns = '壷：IETF：のparams：XML：NS：PIDF' <XMLバージョン= '1.0' エンコーディング= 'UTF-8'？>のxmlns：イム= 'URN：IETF：のparams ：XML：NS：PIDF：イム」実体= 'PRES：romeo@example.net'> <タプルID = '果樹園'> <状態> <基本>開く</基本> <IM：IM>忙しい</ IM：イム> </状態> <ノート>ジュリエット</ノート> </タプル> </プレゼンスを求愛>
XMPP <status/> element <presence from='romeo@example.net/orchard'> <show>dnd</show> <status>Wooing Juliet</status> </presence>
XMPP <状態/>要素<存在from='romeo@example.net/orchard '> <ショー> DND </表示し> <状態>求愛ジュリエット</ステータス> </プレゼンス>
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 <存在/>要素の直接の子として1つ以上の<ノート/>要素を含んでいてもよいです。 XMPP存在スタンザに、このようなPIDF文書の一切のマッピングはありません。 （ゼロ参考文献を参照可能であればXMPP - CPIMゲートウェイの非XMPP側エンティティは、XMPPの受信者にそのようなPIDF文書を送ってはならず、XMPP - CPIMゲートウェイは、XMPP存在スタンザに、このようなPIDF文書をマップしてはいけません（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例えば、IM :, TEL :,またはmailtoの）接触させることが可能なアドレスのURIを指定する<接触/>要素を含んでいてもよいです。連絡先アドレスは、XMPP存在スタンザの属性「から」中に暗黙的であるため、コアXMPP仕様は、連絡先のURIを指定するための構文が含まれていません。 XMPP - CPIMゲートウェイは<接触/>要素が含まれている「メッセージ/ CPIM」カプセル化PIDFオブジェクトとオブジェクトを受信した場合、したがって、それは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>
PIDF <接触/>要素<？XMLバージョン= '1.0' エンコード= 'UTF-8'？> <プレゼンスのxmlns = 'URN：IETF：paramsは：XML：NS：PIDF' エンティティ= 'PRES：romeo@example.net '> <タプルID =' 果樹園 '> ... <接点> IM：romeo@example.net </接触> </タプル> </プレゼンス>
XMPP presence stanza <presence from='romeo@example.net/orchard'/>
XMPP存在スタンザ<プレゼンス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の<接触/>子<タプル/>要素は、その値が0と1（小数点以下3桁の最大値を有する）との間の十進数で「優先度」属性を有し得ます。この属性の値は、XMPP存在スタンザの<優先/>子要素にマッピングされてもよいです。 XMPP - CPIMゲートウェイはXMPP <優先/>要素の負の値にPIDF優先順位値をマッピングしてはいけません。 XMPP - CPIMゲートウェイは、これらの値をマッピングしている場合、それはPIDF優先順位を=扱うべきである「0」XMPP <優先度> 0 </優先>とPIDF優先度=として「1」<優先順位> 127 </優先>のように、適切に中間値をマッピング彼らはそう最大0.992と0.999との間のマッピングPIDF優先順位を介してXMPP優先度126にXMPP優先順位1、XMPP優先度2から0.008と0.015との間のPIDF優先度、および0.001と0.007との間のユニークな（例えば、PIDFの優先順位になるように、このことに注意してください正確なマッピングが）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.
コアXMPP仕様は存在スタンザが送信された日時またはタイムスタンプを指定するための構文が含まれていません。 XMPP - CPIMゲートウェイは<タイムスタンプ/>要素が含まれている「メッセージ/ CPIM」カプセル化PIDFオブジェクトとオブジェクトを受信した場合、したがって、それは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存在スタンザの構文にマップされない（例えば、<接触/>要素の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ゲートウェイMAY機能は、およびXMPPエンティティはゲートウェイのプレゼンスサービスと対話するために定義されたXMPPの構文を使用することができそうだとすれば。 【PIDF】このようなサブスクライブなどの意味論的操作のための構文を指定していないため、このセクションでは、XMPP - CPIMゲートウェイないPIDFにそのようなXMPP構文の翻訳によって提供されるプレゼンスサービスにのみ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はCPP「ウォッチャーパラメータ」フィールド（：ユーザー@ホストPRES）にマップする必要があります。アドレスの前に存在URIスキーム：XMPP - CPIMゲートウェイは「PRES」を追加する必要があります。
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.
属性（ユーザ@ホスト）「から」XMPP OがCPP「ターゲットパラメータ」フィールド（：ユーザー@ホストPRES）にマップする必要があります。アドレスの前に存在URIスキーム：XMPP - CPIMゲートウェイは「PRES」を追加する必要があります。
o There is no XMPP mapping for the CPP "duration parameter", since XMPP subscriptions are active until they have been explicitly "unsubscribed".
彼らは明示的に「解除」されるまでXMPPのサブスクリプションがアクティブになっているので、O 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エンティティに「解除」型の存在スタンザを返さなければならないと通知する操作を起動してはいけません。
In addition to the approval and denial cases, one of the following exceptions may occur:
承認と拒否の場合に加えて、以下のいずれかの例外が発生する可能性があります。
o The target parameter (XMPP "to" address) does not refer to a valid presentity; if this exception occurs, the XMPP-CPIM gateway MUST return an <item-not-found/> stanza error to the XMPP entity.
Oターゲットパラメータ（アドレス「を」XMPP）は、有効なプレゼンを指すものではありません。この例外が発生した場合、XMPP - CPIMゲートウェイはXMPPエンティティへの<item-見つかりません/>スタンザエラーを返さなければなりません。
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実体と対象プレゼン間の動作をサブスクライブが存在します。この例外が発生した場合、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ツー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ウォッチャーからXMPPエンティティに「購読」タイプの存在スタンザを送らなければなりません。次のような構文のマッピングは次のとおりです。CPP「ウォッチャーパラメータ」フィールド（PRES：ユーザー@ホスト）O属性（ユーザー@ホスト）「から」XMPPにマップする必要があります。アドレスの前から存在URIスキーム：XMPP - CPIMゲートウェイは「PRES」を削除しなければなりません。
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：ユーザー@ホスト）は、属性「から」XMPP（ユーザー@ホスト）にマップする必要があります。アドレスの前から存在URIスキーム：XMPP - CPIMゲートウェイは「PRES」を削除しなければなりません。
o There is no XMPP mapping for the CPP "duration parameter", since XMPP subscriptions are active until they have been explicitly "unsubscribed".
彼らは明示的に「解除」されるまでXMPPのサブスクリプションがアクティブになっているので、O 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実体がサブスクリプション要求を承認した場合、それはウォッチャープレゼンにタイプ「サブスクライブ」の存在スタンザを送らなければなりません。 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実体がサブスクリプション要求を拒否した場合、それはウォッチャープレゼンを「解除」タイプの存在スタンザを送らなければなりません。 XMPP - CPIMゲートウェイが通知する操作を起動してはいけません。
In addition to the approval and denial cases, one of the following exceptions MAY occur:
承認と拒否の場合に加えて、以下のいずれかの例外が発生する可能性があります。
o The target parameter (XMPP "to" address) does not refer to a valid XMPP entity
Oターゲットパラメータ（アドレス「を」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ゲートウェイはCPP「通知する操作を」呼び出すたびXMPP実体または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文書は、少なくとも一つのタプルを含むことになるが、複数のタプル（または次のセクションを参照しているゼロタプルを、）を含んでいてもよいです。 XMPPの用語では、各タプルは、別個のリソースのプレゼンス情報にマッピングすることになります。しかし、XMPPは、プレゼンス情報は、プレゼンススタンザのアドレス「から」中に含まれる生成リソースいるので、一度に複数のリソースについてのプレゼンス情報を送信する機能が含まれていません。したがって、プレゼンスサービスとして作用するXMPP - CPIMゲートウェイは複数XMPP存在スタンザに複数のタプルを含んPIDF文書を分割する必要があり、XMPPユーザーは、現在、複数の接続されたリソースを持っている場合（複数のタプルを有する）のみ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を乗算しないの関心に必要以上スタンザ、PIDFタプルに含まれるプレゼンス情報がそのタプルIDに関連付けられたデバイスまたはアプリケーションの可用性ステータスの変更を通信する場合にのみ、XMPP存在スタンザを生成する必要が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組と唯一つのリソースの可用性状況が変化した場合でも、）各リソースのため。
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'/>
<プレゼンスエンティティ= '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）<存在/> <ユーザ@ホスト>に要素マップPIDF <タプル/>要素マップのXMPPアドレスと、（2）「ID」属性の部分にPIDFの「エンティティ」属性XMPPアドレスのリソース識別子部分XMPPにマッピングされた場合、ゼロタプルを含んPIDF文書は、<ユーザ@ホスト>はなく、<ユーザ@ホスト/リソース>についてのプレゼンス情報を提供するであろう。単なるユーザーに関するプレゼンス通知の概念ではなく、ユーザーの資源の一つは、XMPPの文脈ではほぼ無意味である、XMPP - CPIMゲートウェイは、アドレス「から」であるXMPP存在スタンザにゼロタプルでPIDFドキュメントをマッピングする必要がありますが非XMPP実体のユーザ@ホスト。しかし、XMPP - CPIMゲートウェイはゼロでPIDFドキュメントを生成してはならない<タプル/>子供XMPPエンティティからプレゼンススタンザを受信したとき（すなわち、非XMPPサービスへのゲートウェイによって通信されるすべてのPIDFドキュメントは、少なくとも一つを含まなければなりません<タプル/>要素）。
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はCPP「ウォッチャーパラメータ」フィールド（：ユーザー@ホストPRES）にマップする必要があります。アドレスの前に存在URIスキーム：XMPP - CPIMゲートウェイは「PRES」を追加する必要があります。
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.
属性（ユーザ@ホスト）「から」XMPP OがCPP「ターゲットパラメータ」フィールド（：ユーザー@ホストPRES）にマップする必要があります。アドレスの前に存在URIスキーム：XMPP - CPIMゲートウェイは「PRES」を追加する必要があります。
o The CPP "duration parameter" MUST be set to zero.
CPP「durationパラメータ」Oをゼロに設定しなければなりません。
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）は、有効なプレゼンティティを参照しない場合は、XMPP - CPIMゲートウェイはXMPPエンティティへの<item-見つかりません/>スタンザエラーを返さなければなりません。
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はCPP「ウォッチャーパラメータ」フィールド（：ユーザー@ホストPRES）にマップする必要があります。アドレスの前に存在URIスキーム：XMPP-CPIMゲートウェイは「PRES」を追加しなければなりません。
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.
属性（ユーザ@ホスト）「から」XMPP OがCPP「ターゲットパラメータ」フィールド（：ユーザー@ホストPRES）にマップする必要があります。アドレスの前に存在URIスキーム：XMPP-CPIMゲートウェイは「PRES」を追加しなければなりません。 CPP「durationパラメータ」Oをゼロに設定しなければなりません。
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.
インスタントメッセージングおよびプレゼンスプロトコルの詳細なセキュリティ問題は、具体的には、セクション5.4を介して5.1に、[IMP-REQS]に記載されています。
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]実装ゲートウェイを介してインスタントメッセージおよびプレゼンス情報を交換するための方法を指定します。そのようなゲートウェイは、それがインタフェースれるインスタントメッセージングおよびプレゼンスプロトコルの最低限のセキュリティ要件に準拠しなければなりません。 RFC 2779でインスタントメッセージングとプレゼンスのセキュリティモデルへのゲートウェイの導入も紹介します
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ゲートウェイを介してインターフェースは、共通のフォーマットがサポートされている場合にのみ提供することができる、インスタントメッセージングとプレゼンスユーザエージェントとの間、特に、エンド・ツー・エンドのセキュリティ特性（特に機密性と完全性）。これらのフォーマットは、[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]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、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日目、M.、アガルワル、S.、モール、G.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、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.アトキンス、 "一般的なプレゼンスとインスタントメッセージング（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]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（PIDF）"、RFC 3863、2004年8月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings (stringprep)", RFC 3454, December 2002.
【STRINGPREP]ホフマン、P.及びM.ブランシェ、RFC 3454、2002年12月 "国際化された文字列（文字列準備）の調製"。
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[用語]ブラドナーの、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]サーフ、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]サンアンドレ、P.、エド、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"。、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]サンアンドレ、P.、エド。、 "エンドツーエンドの署名とオブジェクトの暗号化拡張メッセージングおよびプレゼンスプロトコル（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]サン・アンドレ（編）、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：インスタントメッセージングとプレゼンス"、RFC 3921、2004年10月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[MIMETYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIMEタイプ]解放され、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）を輸送" [XMPP-PIDF]サンアンドレ、P.、進歩、2004年2月に作業。
Author's Address
著者のアドレス
Peter Saint-Andre Jabber Software Foundation
ピーターサンアンドレのJabberソフトウェア財団
EMail: stpeter@jabber.org
メールアドレス：stpeter@jabber.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。