Network Working Group H. Sugano
Request for Comments: 3863 S. Fujimoto
Category: Standards Track Fujitsu
G. Klyne
Nine by Nine
A. Bateman
VisionTech
W. Carr
Intel
J. Peterson
NeuStar
August 2004
Presence Information Data Format (PIDF)
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 specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type "application/pidf+xml" to represent the XML MIME entity for PIDF.
このメモは、CPP準拠のプレゼンス・プロトコルのための共通のプレゼンスデータ形式としてのプレゼンスのための共通プロファイル（CPP）、プレゼンス情報データフォーマット（PIDF）を指定し、またXMLのMIMEを表現するために、新たなメディアタイプ「アプリケーション/ PIDF + XML」を定義しますPIDFのためのエンティティ。
Table of Content
コンテンツの表
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Conventions. . . . . . . . . . . . . . . 3
2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Minimal Model. . . . . . . . . . . . . . . . . . . . . . 3
2.2. Added Features . . . . . . . . . . . . . . . . . . . . . 4
2.3. XML Encoding Decision. . . . . . . . . . . . . . . . . . 5
3. Overview of Presence Information Data Format . . . . . . . . . 5
3.1. The 'application/pidf+xml' Content Type. . . . . . . . . 5
3.2. Presence Information Contents. . . . . . . . . . . . . . 5
4. XML-encoded Presence Data Format . . . . . . . . . . . . . . . 6
4.1. XML Format Definitions . . . . . . . . . . . . . . . . . 6
4.1.1. The <presence> element. . . . . . . . . . . . . . 6
4.1.2. The <tuple> element . . . . . . . . . . . . . . . 7
4.1.3. The <status> element. . . . . . . . . . . . . . . 8
4.1.4. The <basic> element . . . . . . . . . . . . . . . 8
4.1.5. The <contact> element . . . . . . . . . . . . . . 8
4.1.6. The <note> element. . . . . . . . . . . . . . . . 9
4.1.7. The <timestamp> element . . . . . . . . . . . . . 9
4.2. Presence Information Extensibility . . . . . . . . . . . 10
4.2.1. XML Namespaces Background . . . . . . . . . . . . 10
4.2.2. XML Namespaces In Presence Information. . . . . . 11
4.2.3. Handling Of Unrecognized Element Names. . . . . . 12
4.2.4. Status Value Extensibility. . . . . . . . . . . . 12
4.2.5. Standardizing Status Extensions . . . . . . . . . 13
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Default Namespace with Status Extensions. . . . . 14
4.3.2. Presence with Other Extension Elements. . . . . . 15
4.3.3. Example Mandatory To Understand Elements. . . . . 16
4.4. XML Schema Definitions . . . . . . . . . . . . . . . . . 16
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
5.1. Content-type registration for 'application/pidf+xml' . . 18
5.2. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf'. . . . . . . . . . . . . . 19
5.3. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:status' . . . . . . . . . . 20
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
7. Internationalization Considerations. . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Document Type Definitions. . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 28
The Common Profiles for Instant Messaging (CPIM) [CPIM] and Presence (CPP) [CPP] specifications define a set of operations and parameters to achieve interoperability between different Instant Messaging and Presence protocols which meet RFC 2779 [RFC2779].
インスタントメッセージング（CPIM）[CPIM]とプレゼンス（CPP）CPP】仕様のための一般的なプロファイルは、RFC 2779 [RFC2779]に合致する異なるインスタントメッセージングおよびプレゼンスプロトコル間の相互運用性を達成するために、操作とパラメータのセットを定義します。
This memo further defines the Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant presence protocols, allowing presence information to be transferred across CPP-compliant protocol boundaries without modification, with attendant benefits for security and performance.
このメモはさらにプレゼンス情報がセキュリティとパフォーマンスのための付随する利点と、変更なしでCPP準拠プロトコルの境界を越えて転送されることを可能にする、CPP準拠のプレゼンスプロトコルのための共通のプレゼンスデータ形式としてプレゼンス情報データフォーマット（PIDF）を定義します。
The format specified in this memo defines the base presence format and extensibility required by RFC 2779. It defines a minimal set of presence status values defined by the IMPP Model document [RFC2778]. However, a presence application is able to define its own status values using the extensibility framework provided by this memo. Defining such extended status values is beyond the scope of this memo.
このメモで指定されたフォーマットは、IMPPモデルドキュメント[RFC2778]で定義されたプレゼンス状態値の最小セットを定義するRFC 2779.によって必要とされる塩基の存在形式と拡張を定義します。しかしながら、プレゼンスアプリケーションは、このメモが提供する拡張フレームワークを使用して、自身のステータスの値を定義することができます。そのような拡張されたステータス値を定義すると、このメモの範囲を超えています。
Note also that this memo defines only the format for a presence data payload and the extensibility framework for it. How the presence data is transferred within a specific protocol frame would be defined separately in a protocol specification.
このメモは、プレゼンスデータペイロード及びそのための拡張フレームワークのための唯一の形式を定義することにも留意されたいです。プレゼンスデータは、特定のプロトコル・フレーム内で転送される方法、プロトコル仕様で別々に定義されます。
This memo makes use of the vocabulary defined in the IMPP Model document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are used in the same meaning as defined therein.
このメモはIMPPモデルドキュメント[RFC2778]で定義された語彙を使用しています。その中で定義されているようなCLOSED、インスタントメッセージ、OPEN、PRESENCEサービス、PRESENTITY、WATCHER、およびメモでWATCHERユーザエージェントなどの用語は同じ意味で使用されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、この文書では、 "SHOULD"、 "推奨" "NOTべきで"、 "MAY"、および "任意の" BCP 14で説明したように解釈されるべきです、 RFC 2119 [RFC2119]。
We have adopted the IMPP Model and Requirements documents [RFC2778, RFC2779] as the starting point of our discussion. The two RFCs contain a number of statements about presence information, which can be regarded as a basic set of constraints for the format design. Also, we took the minimalist approach to the design based on them. Starting from the minimal model, only the features that are necessary to solve particular problems have been included.
我々は、我々の議論の出発点としてIMPPモデルと要件文書[RFC2778、RFC2779]を採用しています。 2つのRFCは、フォーマットデザインの制約の基本セットとみなすことができるプレゼンス情報に関する文の数が含まれています。また、我々は彼らに基づく設計へのミニマリスト的なアプローチを取りました。最小限のモデルから開始し、特定の問題を解決するために必要なだけの機能が含まれています。
This specification is based on the minimal model extracted from the IMPP Model and Requirements documents. The model consists of the following items. Each of them is accompanied with the corresponding RFCs and their section numbers as its grounds, e.g., (RFC2778:Sec.2.4) refers to Section 2.4 of RFC 2778.
この仕様は、IMPPモデルと要件文書から抽出された最小限のモデルに基づいています。モデルは、以下の項目から構成されています。それらの各々は、その根拠として、対応するRFCおよびそれらのセクション番号を伴う、例えば、（RFC2778：Sec.2.4）は、RFC 2778のセクション2.4を指します。
(a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES, where a PRESENCE TUPLE consists of a STATUS, an optional COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. Note that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is understood in this document to refer only to a URI (RFC2778:Sec.3).
（a）は、プレゼンス情報は、プレゼンス・タプルは、STATUS、オプションの通信アドレス、および任意の他のプレゼンスマークアップで構成されて一つ以上のプレゼンスタプルからなります。通信アドレスで連絡先アドレスのみURI（：Sec.3 RFC2778）を参照するために、このドキュメントでは理解されていることに注意してください。
(b) STATUS has at least the mutually-exclusive values OPEN and CLOSED, which have meaning for the acceptance of INSTANT MESSAGES, and may have meaning for other COMMUNICATION MEANS. There may be other values of STATUS that do not imply anything about INSTANT MESSAGE acceptance. These other values of STATUS may be combined with OPEN and CLOSED or they may be mutually-exclusive with those values (RFC2778:Sec.3, RFC2779:Sec.4.4.1- 4.4.3).
（b）は、STATUSは、インスタントメッセージの受け入れのために意味を持ち、他の通信手段を意味している可能性があり、少なくとも相互に排他的な値開閉を有しています。インスタントメッセージの受け入れについては何を意味するものではありませんSTATUSの他の値があるかもしれません。 STATUSのこれらの他の値は、開閉と組み合わせることができる、またはそれらは、それらの値（RFC2778：Sec.3、RFC2779：Sec.4.4.1- 4.4.3）と相互に排他的であってもよいです。
(c) STATUS may consist of single or multiple values.(RFC2778:Sec.2.4)
（C）状態は、単一または複数の値から成ることができる（RFC2778：Sec.2.4）。
(d) There must be a means of extending the common presence format to represent additional information not included in the common format. The extension and registration mechanisms must be defined for presence information schema, including new STATUS conditions and new forms for OTHER PRESENCE MARKUP (RFC2779:Sec.3.1.4-3.1.5).
（d）は共通のフォーマットに含まれていない追加情報を表すために、共通のプレゼンス形式を拡張する手段がなければなりません。拡張および登録メカニズムは新しいステータス条件および他のプレゼンスマークアップ（：Sec.3.1.4-3.1.5 RFC2779）のための新たな形態を含む、プレゼンス情報のスキーマを定義する必要があります。
(e) The common presence format must include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported (RFC2779:Sec.3.1.2).
（e）は、共通のプレゼンス形式は一意にプレゼンス情報（：Sec.3.1.2 RFC2779）が報告されているPRESENTITYを識別するための手段を含まなければなりません。
(f) The common presence format must allow the PRESENTITY to secure presence information sent to a WATCHER. The format must allow integrity, confidentiality and authentication properties to be applied to presence information (RFC2779:Sec5.2.1, 5.2.4, 5.3.1, 5.3.3).
（f）は、共通のプレゼンス形式は、プレゼンティティがウォッチャに送信されたプレゼンス情報を保護することができなければなりません。フォーマットは、完全性、機密性と認証のプロパティは、プレゼンス情報に適用できるようにする必要があります（RFC2779：Sec5.2.1、5.2.4、5.3.1、5.3.3）。
In addition to the minimal model described above, the format specified in this specification has the following features.
上記最小モデルに加えて、本明細書で指定された形式は、以下の特徴を有しています。
(a) Relative priorities of contact addresses are specifiable in order to allow the source of PRESENCE INFORMATION to tell the receiver (WATCHER USER AGENTS) its preference over multiple contact means.
（a）は、コンタクトアドレスの相対的な優先順位は、プレゼンス情報のソースは、レシーバ（ウォッチャユーザエージェント）は、複数の接触手段上の好みを伝えることを可能にするために指定可能です。
(b) The presence format is able to contain the timestamp of the creation of the PRESENCE INFORMATION. The timestamp in the presence document lets the receiver know the time of the creation of the data even if the message containing it is delayed. It can also be used to detect a replay attack, independent of the underlying signature mechanism. Note that this mechanism does not assume any global time synchronization system for watchers and presentities (see Appendix A of RFC2779, 8.1.4 A7), but rather assumes that the minimum length of time that might pass before presence information is considered stale is long enough that minor variations among system clocks will not lead to misjudgments of the freshness of presence information.
（b）は、プレゼンス・フォーマットは、プレゼンス情報の作成のタイムスタンプを含むことができます。プレゼンス文書のタイムスタンプは、受信機がそれを含むメッセージが遅延した場合でも、データの作成時刻を知ることができます。また、基礎となる署名メカニズムの独立リプレイ攻撃を検出するために使用することができます。このメカニズムは（8.1.4 A7をRFC2779の付録Aを参照）ウォッチャーとプレゼンのための任意のグローバル時刻同期システムを想定していないことに注意してくださいではなく、プレゼンス情報が古くなったと見なされる前に渡すかもしれない時間の長さの最小値が十分な長さであることを前提としていそのシステムクロックのうち小さな変化は、プレゼンス情報の鮮度の誤判定につながることはありません。
The Presence Information Data Format encodes presence information in XML (eXtensible Markup Language [XML]). Regarding the features of PRESENCE INFORMATION discussed above, such that it has a hierarchical structure and it should be fully extensible, XML is considered as the most desirable framework over other candidates such as vCard [vCard].
プレゼンス情報データフォーマットがXMLでプレゼンス情報を符号化する（拡張マークアップ言語[XML]）。それは階層構造を有しており、それは完全に拡張可能であるべきであるように、上述のプレゼンス情報の特徴について、XMLは、vCardの[vCardの】として他の候補で最も望ましい枠組みとして考えられています。
This section describes an overview of the presence data format defined in this memo.
このセクションでは、このメモで定義されたプレゼンス・データ・フォーマットの概要を説明しています。
This memo defines a new content type "application/pidf+xml" for an XML MIME entity that contains presence information. This specification follows the recommendations and conventions described in [RFC3023], including the naming convention of the type ('+xml' suffix) and the usage of the 'charset' parameter.
このメモは、プレゼンス情報を含むXML MIMEエンティティの新しいコンテンツタイプ「アプリケーション/ PIDF + XML」を定義します。この仕様は、タイプの命名規則（「+ XML」サフィックス）と「文字セット」パラメータの使用を含む、[RFC3023]に記載お薦めや規則に従います。
Although it is defined as optional, use of the 'charset' parameter is RECOMMENDED. If the 'charset' parameter is not specified, conforming XML processors MUST follow the requirements in section 4.3.3 of [XML].
それがオプションとして定義されているが、「文字セット」パラメータの使用が推奨されます。 「文字セット」パラメータが指定されていない場合、準拠XMLプロセッサは、[XML]のセクション4.3.3の要求事項に従わなければなりません。
This subsection outlines the information in an "application/pidf+xml" document. A full definition of the PIDF content is in Section 4.
ここでは、「アプリケーション/ PIDF + xml」で文書に記載されている情報の概要を説明します。 PIDFのコンテンツの完全な定義はセクション4です。
o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY. o List of PRESENCE TUPLES - Identifier: token to identify this tuple within the presence information. - STATUS: OPEN/CLOSED and/or extension status values. - COMMUNICATION ADDRESS: COMMUNICATION MEANS and CONTACT ADDRESS of this tuple. (optional) - Relative priority: numerical value specifying the priority of this COMMUNICATION ADDRESS. (optional) - Timestamp: timestamp of the change of this tuple.(optional) - Human readable comment: free text memo about this tuple (optional)
O PRESENTITYのURLは：PRESENTITYの "PRES" URLを指定します。 O PRESENCEタプルのリスト - 識別子：トークンは、プレゼンス情報内のこのタプルを識別することができます。 - STATUS：CLOSED / OPENおよび/または拡張ステータス値。 - 通信アドレス：通信手段と、このタプルの連絡先。 （オプション） - 相対的な優先度：この通信アドレスの優先順位を指定する数値。 （オプション） - タイムスタンプ：このタプルの変更のタイムスタンプ（オプション） - 人間の読めるコメント：このタプルについて自由テキストメモ（オプション）
o PRESENTITY human readable comment: free text memo about the PRESENTITY (optional).
O PRESENTITY人間が読めるコメント：（オプション）PRESENTITYに関するフリーテキストメモ。
This section defines an XML-encoded presence information data format (PIDF) for use with CPP compliant systems. A presence payload in this format is expected to be produced by the PRESENTITY (the source of the PRESENCE INFORMATION) and transported to the WATCHERS by the presence servers or gateways without any interpretation or modification.
このセクションでは、CPP準拠のシステムで使用するためのXMLでエンコードされたプレゼンス情報データフォーマット（PIDF）を定義します。この形式で存在ペイロードはPRESENTITY（プレゼンス情報の源）によって生成され、任意の解釈や変更を加えることなく、プレゼンスサーバまたはゲートウェイによってウォッチャに輸送されることが期待されます。
A PIDF object is a well formed XML document.
PIDFオブジェクトは、整形式XML文書です。
It MUST have the XML declaration and it SHOULD contain an encoding declaration in the XML declaration, e.g., "<?xml version='1.0' encoding='UTF-8'?>". If the charset parameter of the MIME content type declaration is present and it is different from the encoding declaration, the charset parameter takes precedence.
これは、XML宣言を持たなければならないし、それは、例えば、 "<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？>" XML宣言のencoding宣言を、含むべきです。 MIMEコンテンツタイプ宣言のcharsetパラメータが存在し、それがエンコーディング宣言と異なる場合、charsetパラメータが優先されます。
Every application conformant to this specification MUST accept the UTF-8 character encoding to ensure the minimal interoperability.
この仕様への準拠すべてのアプリケーションは、最小限の相互運用性を確保するために、UTF-8文字エンコーディングを受け入れなければなりません。
PIDF elements are associated with the XML namespace name 'urn:ietf:params:xml:ns:pidf', declared using an xmlns attribute, per [XML-NS]. The namespace may be a default namespace, or may be associated with some namespace prefix (see section 4.2.2 for examples).
PIDF要素がXML名前空間名 '：IETF：のparams：XML：NS：骨壷PIDF' に関連付けられている、[XML-NS]ごとに、のxmlns属性を使用して宣言しました。名前空間は、デフォルトの名前空間であってもよく、またはいくつかの名前空間接頭辞（例についてはセクション4.2.2を参照）に関連付けられてもよいです。
The root of an "application/pidf+xml" object is a <presence> element associated with the presence information namespace. This contains any number (including 0) of <tuple> elements, followed by any number (including 0) of <note> elements, followed by any number of OPTIONAL extension elements from other namespaces.
ルート「アプリケーション/ PIDF + XML」の目的は、プレゼンス情報の名前空間に関連付けられた<プレゼンス>要素です。これは、（0を含む）任意の数続く<タプル>要素の任意の数（0を含む）を含む他の名前空間からオプションの拡張要素の任意の数字が続く<注意>要素の。
The <presence> element MUST have an 'entity' attribute. The value of the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing this presence document.
<存在>要素は、「エンティティの属性を持たなければなりません。 「エンティティの属性の値は、このプレゼンス文書を公開PRESENTITYの「PRES」URLです。
The <presence> element MUST contain a namespace declaration ('xmlns') to indicate the namespace on which the presence document is based. The presence document compliant to this specification MUST have the namespace 'urn:ietf:params:xml:ns:pidf:'.
<プレゼンス>要素は、プレゼンス文書が基づいている名前空間を示すために、名前空間宣言（「のxmlns」）を含まなければなりません。この仕様に準拠したプレゼンス文書は、名前空間「：IETF：のparams：XML：NS：PIDF：壷」を持たなければなりません。
It MAY contain other namespace declarations for the extensions used in the presence XML document.
これは、プレゼンス、XML文書で使用される拡張のための他の名前空間宣言を含むかもしれません。
The <tuple> element carries a PRESENCE TUPLE, consisting of a mandatory <status> element, followed by any number of OPTIONAL extension elements (possibly from other namespaces), followed by an OPTIONAL <contact> element, followed by any number of OPTIONAL <note> elements, followed by an OPTIONAL <timestamp> element.
<タプル>要素はオプションの任意の数続くオプションの<接点>要素、続いて、（他の名前空間から、おそらく）は、オプションの拡張要素のいずれかの数字が続く必須<状態>要素から成る、プレゼンスタプルを運びます< >オプション<タイムスタンプ>要素に続く要素を、注意してください。
Tuples provide a way of segmenting presence information. Protocols or applications may choose to segment the presence information associated with a presentity for any number of reasons - for example, because components of the full presence information for a presentity have come from distinct devices or different applications on the same device, or have been generated at different times. Tuples should be preferred over other manners of segmenting presence information such as creating multiple PIDF instances.
タプルはプレゼンス情報をセグメント化する方法を提供します。プレゼンティティの完全なプレゼンス情報の構成要素は、同じデバイス上の別個のデバイスまたは異なるアプリケーションから来た、または生成されているので、例えば - プロトコルまたはアプリケーションは、セグメントに理由の任意の数のプレゼンティティに関連するプレゼンス情報を選択することができます異なる時間に。タプルは、複数PIDFインスタンスを作成するようにプレゼンス情報を分割する他の方法よりも優先されるべきです。
The <tuple> element MUST contain an 'id' attribute which is used to distinguish this tuple from other tuples in the same PRESENTITY. The value of an 'id' attribute MUST be unique within 'id' attribute values of other tuples for the same PRESENTITY. An 'id' value is used by applications processing the presence document to identify the corresponding tuple in the previously acquired PRESENCE INFORMATION of the same PRESENTITY. The value of the 'id' attribute is an arbitrary string, and has no significance beyond providing a means to distinguish <tuple> values, as noted above.
<タプル>要素は同じPRESENTITYに他のタプルから、このタプルを区別するために使用される「ID」属性を含まなければなりません。 「ID」属性の値は、同じPRESENTITYのために他のタプルの「ID」属性値内で一意でなければなりません。 「ID」の値は同じPRESENTITYの以前に取得したプレゼンス情報に対応するタプルを識別するために、プレゼンス文書を処理するアプリケーションで使用されます。 「ID」属性の値は、任意の文字列であり、上述したように、<タプル>値を区別するための手段を提供することを超えては意味を持ちません。
The <contact> element is OPTIONAL because a PRESENTITY might need to hide its COMMUNICATION ADDRESS or there might be tuples not related to any COMMUNICATION MEANS. Tuples that contain a <basic> status element SHOULD contain a <contact> address. Tuples MAY contain conflicting presence status - one <tuple> might provide a <basic> <status> of OPEN, and another <tuple> in the same PIDF could contain a <basic> <status> of CLOSED, even if they both contain the same <contact> address.
プレゼンティティがその通信アドレスを非表示にする必要があるかもしれませんまたは任意の通信手段に関連していないタプルがあるかもしれませんので、<連絡先>要素はオプションです。 <基本>ステータス要素が含まれているタプルは<連絡先>アドレスを含むべきです。タプルは競合プレゼンスステータスを含むかもしれ - 1 <タプル>両者が含まれている場合でも、同じPIDFでOPENの<基本> <状態>、および他の<タプル>は、CLOSEDの<基本> <状態>を含めることができます提供することがあります同じ<連絡先>アドレス。
The manner in which segmented presence information is understood by the WATCHER USER AGENT is highly dependent on the capabilities of the WATCHER USER AGENT and the presence application in question. In the absence of any application-specific or protocol-specific understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey the following guidelines. WATCHER USER AGENTS should note which tuples in the PIDF have changed their state since the last notification by correlating the 'id' of each <tuple> with those received in previous notifications and comparing both <status> values and <timestamp> elements in the tuples, if any are present.
セグメント化されたプレゼンス情報をウォッチャーユーザーエージェントによって理解される方法は、ウォッチャーユーザーエージェントと当該プレゼンスアプリケーションの機能に大きく依存します。タプルの意味のいずれかの特定のアプリケーションやプロトコル固有の理解がない場合には、WATCHERのユーザエージェントは、次のガイドラインに従うかもしれません。ウォッチャーユーザーエージェントは、以前の通知で受信したものとそれぞれの「ID」<タプル>相関し、<状態>の値とタプル内の<タイムスタンプ>要素の両方を比較することにより、最後の通知以降、その状態を変更したPIDFにタプルに注意してください、いずれかが存在する場合。
The <status> element contains one OPTIONAL <basic> element, followed by any number of OPTIONAL extension elements (possibly from other namespaces), under the restriction that at least one child element appears in the <status> element. These children elements of <status> contain status values of this tuple. By allowing multiple status values in a single <tuple> element, different types of status values, e.g., reachability and location, can be represented by a <tuple>. See Section 4.3 for an example with multiple status values.
<状態>要素は少なくとも1つのつの子要素が<ステータス>要素に表示された制限下で、（場合によっては他の名前空間からの）オプションの拡張要素の任意の数の続く一つの任意の<基本>要素が含まれています。 <状態>のこれらの子要素は、このタプルのステータス値が含まれています。単一の<タプル>要素内の複数の状態値を可能にすることによって、状態値の異なるタイプ、例えば、到達可能性および位置は、<タプル>によって表すことができます。複数のステータス値を持つ例えば、セクション4.3を参照してください。
This memo only defines the <basic> status value element. Other status values may be included using the standard extensibility framework (see Section 4.2.4). Applications encountering unrecognized elements within <status> may ignore them, unless they carry a mustUnderstand="true" or mustUnderstand="1" attribute (see section 4.2.3).
このメモは、<基本>ステータス値の要素を定義します。その他のステータス値（セクション4.2.4を参照）は、標準拡張フレームワークを使用して含まれてもよいです。彼らはのmustUnderstand =「true」またはでmustUnderstand =「1」属性（セクション4.2.3を参照）を実行しない限り、<状態>の中に認識されていない要素に遭遇するアプリケーションは、それらを無視することができます。
Note that, while the <status> element MUST have at least one status value element, this status value might not be the <basic> element.
<ステータス>要素は、少なくとも一つのステータス値の要素を持っていなければならないが、このステータス値は、<基本>要素ではないかもしれない、ということに注意してください。
The <basic> element contains one of the following strings: "open" or "closed".
<基本>要素は、以下のいずれかの文字列が含まれています。「オープン」または「クローズド」。
The values "open" and "closed" indicate availability to receive INSTANT MESSAGES if the <tuple> is for an instant messaging address. They also indicate general availability for other communication means, but this memo does not specify these in detail.
「オープン」と「閉」の値が<タプル>は、インスタントメッセージングアドレスのためであれば、インスタントメッセージを受信するための利用可能性を示しています。彼らはまた、他の通信手段のための一般的な利用可能性を示しますが、このメモは詳細にこれらを指定していません。
open: In the context of INSTANT MESSAGES, this value means that the associated <contact> element, if any, corresponds to an INSTANT INBOX that is ready to accept an INSTANT MESSAGE.
開き：インスタントメッセージの文脈では、この値は、もしあれば関連<接点>要素は、インスタントメッセージを受け入れる準備ができているINSTANT INBOXに対応することを意味します。
closed: In the context of INSTANT MESSAGES, this value means that the associated <contact> element, if any, corresponds to an INSTANT INBOX that is unable to accept an INSTANT MESSAGE.
閉じた：インスタントメッセージの文脈では、この値は、もしあれば関連<接点>要素は、インスタントメッセージを受け入れることができないINSTANT INBOXに対応することを意味します。
The <contact> element contains a URL of the contact address. It optionally has a 'priority' attribute, whose value means a relative priority of this contact address over the others. The value of the attribute MUST be a decimal number between 0 and 1 inclusive with at most 3 digits after the decimal point. Higher values indicate higher priority. Examples of priority values are 0, 0.021, 0.5, 1.00. If the 'priority' attribute is omitted, applications MUST assign the contact address the lowest priority. If the 'priority' value is out of the range, applications just SHOULD ignore the value and process it as if the attribute was not present.
<連絡先>要素には、連絡先のURLが含まれています。それは、必要に応じてその値が他のものよりも、この連絡先の相対的優先順位を意味する「優先度」属性を有しています。属性の値は、小数点以下は最大で3桁で0から1までの間の十進数でなければなりません。より高い値は高い優先度を示しています。優先値の例は、0、0.021、0.5、1.00です。 「優先権」属性が省略された場合、アプリケーションは、連絡先に最も低い優先度を割り当てる必要があります。 「優先順位」の値が範囲外の場合、アプリケーションは、単に値を無視すべきであり、属性が存在しなかったかのようにそれを処理します。
Applications SHOULD handle contacts with a higher priority as they have precedence over those with lower priorities. How they are actually treated is beyond this specification. Also, how to handle contacts with the same priority is up to implementations.
彼らは優先度の低いものよりも優先されてアプリケーションは、優先順位の高いコンタクトを処理する必要があります。どのように彼らは実際に扱われ、この仕様を超えています。また、同じ優先度で連絡先をどのように扱うかの実装次第です。
The <note> element contains a string value, which is usually used for a human readable comment. A <note> element MAY appear as a child element of <presence> or as a child element of the <tuple> element. In the former case the comment is about the PRESENTITY and in the latter case the comment is regarding the particular tuple.
<ノート>要素は、通常、人間が読めるコメントに使用される文字列の値を、含まれています。 <ノート>要素は、<存在>または<タプル>要素の子要素としての子要素として表示されることがあります。前者の場合にコメントがPRESENTITYについてであり、後者の場合、コメントは、特定のタプルについてれます。
Note that, wherever it appears, a <note> element SHOULD NOT be used, and interpreted, as a non-interoperable substitute for status of its parent element.
それはどこに現れても、その親要素の状態のための非相互運用可能代替として、<ノート>要素を使用し、解釈してはならない、ことに注意してください。
The <note> element SHOULD have a special attribute 'xml:lang' to specify the language used in the contents of this element as defined in Section 2.12 of [XML]. The value of this attribute is the language identifier as defined by [RFC3066]. It MAY be omitted when the language used is implied by the larger context such as the encoding information of the contents, such as an xml:lang attribute on an enclosing XML element, or a Content-language header [RFC3282] on an enclosing MIME wrapper.
[XML]のセクション2.12で定義された、この要素の内容で使用される言語を指定するには：<ノート>要素には、特別な属性「LANGのxml」を持つべきである（SHOULD）。 [RFC3066]で定義されるように、この属性の値は言語識別子です。使用される言語は、そのようなコンテンツの符号化情報として、より大きな文脈によって暗示されている場合には、XMLなどの、省略され得る。包囲MIMEラッパーで囲むXML要素にlang属性、またはContent-Languageヘッダ[RFC3282] 。
The <timestamp> element contains a string indicating the date and time of the status change of this tuple. The value of this element MUST follow the IMPP datetime format [RFC3339]. Timestamps that contain 'T' or 'Z' MUST use the capitalized forms.
<タイムスタンプ>要素は、このタプルのステータス変更の日付と時刻を示す文字列が含まれています。この要素の値は、IMPP日時フォーマット[RFC3339]を従わなければなりません。 「T」または「Z」が含まれているタイムスタンプは、大文字のフォームを使用しなければなりません。
As a security measure, the <timestamp> element SHOULD be included in all tuples unless the exact time of the status change cannot be determined. For security guidelines for watchers receiving presence information with timestamps, see the Security Considerations.
ステータス変更の正確な時間を決定することができない場合を除き、セキュリティ対策として、<タイムスタンプ>要素は、すべてのタプルに含まれるべきです。タイムスタンプ付きのプレゼンス情報を受信ウォッチャーのためのセキュリティガイドラインについては、セキュリティ上の考慮事項を参照してください。
A PRESENTITY MUST NOT generate successive <presence> elements containing the same timestamp.
プレゼンティティが同じタイムスタンプを含む連続した<プレゼンス>要素を生成してはいけません。
The presence information extensibility framework is based on XML namespaces [XML-NS].
プレゼンス情報の拡張フレームワークは、XML名前空間[XML-NS]に基づいています。
RFC 2779 requires that PIDF have a means of extending <status> values beyond <basic>. These extensions MUST NOT modify how <basic> is to be understood, nor change the structure or semantics of PIDF bodies themselves. These extensions merely allow protocols and applications to define richer presence data.
RFC 2779は、PIDFは、<基本>を超えて<状態>の値を拡張する手段を持っていることが必要です。これらの拡張機能は、理解されるべきであるか、<基本>変更、またPIDF本体そのものの構造や意味論を変更してはなりません。これらの拡張機能は、単にプロトコルおよびアプリケーションは、より豊かなプレゼンスデータを定義することができます。
All elements and some attributes are associated with a "namespace", which is in turn associated with a globally unique URI. Any developer can introduce their own element names, avoiding conflict by choosing an appropriate namespace URI.
すべての要素といくつかの属性を順番にグローバルに一意なURIに関連付けられている「名前空間」、と関連しています。すべての開発者は、適切な名前空間URIを選択することで、競合を避け、自分の要素名を導入することができます。
Within the presence data, element or attribute names are associated with a particular namespace by a namespace prefix, which is a leading part of the name, followed by a colon (":"); e.g.,
プレゼンス内のデータ要素または属性名は、（「：」）コロン、名前の先頭部分である名前空間接頭辞で特定の名前空間に関連付けられています。例えば。、
<prefix:element-name ...> ... </prefix:element-name>
<接頭辞：要素名...> ... </プレフィックス：要素名>
Where, 'prefix' is the header name prefix, 'element-name' is a name which is scoped by the namespace associated with 'prefix'. Note that the choice of 'prefix' is quite arbitrary; it is the corresponding URI that defines the naming scope. Two different prefixes associated with the same namespace URI refer to the same namespace.
ここで、「プレフィックス」は、ヘッダ名の接頭辞で、「要素名」は「プレフィックス」に関連付けられた名前空間によってスコープされる名前です。 「プレフィックス」の選択は非常に任意であることに注意してください。それは命名範囲を定義する対応するURIです。同じ名前空間URIに関連付けられている二つの異なる接頭辞が同じ名前空間を参照してください。
A default namespace can be declared for XML elements without a namespace prefix. The default namespace does NOT apply to attribute names, but interpretation of an unprefixed attribute can be determined by the containing element.
デフォルトの名前空間は、名前空間接頭辞なしでXML要素に対して宣言することができます。デフォルトの名前空間は属性名には適用されませんが、接頭辞属性の解釈が含まれている要素によって決定することができます。
A namespace is identified by a URI. In this usage, the URI is used simply as a globally unique identifier, and there is no requirement that it can be used to retrieve a web resource, or for any other purpose. Any legal globally unique URI MAY be used to identify a namespace. (By "globally unique", we mean constructed according to some set of rules so that it is reasonable to expect that nobody else will use the same URI for a different purpose.)
名前空間は、URIで識別されます。この使用法では、URIは、グローバル一意識別子として単純に使用され、Webリソースを取得するために使用、またはその他の目的のためにすることができます必要はありません。法的グローバルにユニークなURIは、名前空間を識別するために使用されるかもしれません。 （「グローバルに一意」によって、我々は、誰もが異なる目的のために同じURIを使用しないことを期待するのは合理的であるように、いくつかのルールのセットに基づいて構成を意味します。）
For further details, see the XML namespace specification [XML-NS].
詳細については、XML名前空間仕様[XML-NS]を参照してください。
A URI used as a namespace identifier in PRESENCE INFORMATION data MUST be a full absolute-URI, per RFC 2396 [URI]. (Relative URIs and URI-references containing fragment identifiers MUST NOT be used for this purpose.)
URIは、RFC 2396 [URI]あたり、完全絶対URIでなければなりませんプレゼンス情報データにおける名前空間識別子として使用されます。 （断片識別子を含む相対URIとURI参照は、この目的のために使用してはいけません。）
The namespace URI for elements defined by this specification is a URN [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] and extended by [XML-Registry]:
この仕様によって定義された要素の名前空間URIは、名前空間識別子「IETF」[URN-NS-IETF]によって定義され、[XML-レジストリ]によって拡張を使用してURN [URN]、です。
urn:ietf:params:xml:ns:pidf
URN：IETF：のparams：XML：NS：PIDF
Thus, simple presence data might be thus:
このように、シンプルなプレゼンスデータは、このように次のようになります。
<?xml version="1.0" encoding="UTF-8"?> <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf" entity="pres:someone@example.com"> <impp:tuple id="sg89ae"> <impp:status> <impp:basic>open</impp:basic> </impp:status> <impp:contact priority="0.8">tel:+09012345678</impp:contact> </impp:tuple> </impp:presence>
<？xml version = "1.0" エンコード= "UTF-8"？> <IMPP：プレゼンスのxmlns：IMPP = "URN：IETF：paramsは：XML：NS：PIDF" エンティティ= "PRES：someone@example.com"> <IMPP：タプルID = "sg89ae"> <IMPP：状態> <IMPP：基本>開く</ IMPP：基本> </ IMPP：状態> <IMPP：コンタクト優先= "0.8">電話：09012345678 </ IMPP連絡先> </ IMPP：タプル> </ IMPP：存在>
, using a default XML namespace:
、デフォルトのXML名前空間を使用しました：
<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="pres:someone@example.com"> <tuple id="sg89ae"> <status> <basic>open</basic> </status> <contact priority="0.8">tel:+09012345678</contact> </tuple> </presence>
<？xml version = "1.0" エンコード= "UTF-8"？> <プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" エンティティ= "PRES：someone@example.com"> <タプルID = "sg89ae"> <状態> <基本>開く</塩基性> </状態> <コンタクト優先度= "0.8"> TEL：09012345678 </接触> </タプル> </プレゼンス>
As is generally the case in XML with namespaces, the xmlns attribute can be used on any element in the presence information to define either the default namespace or a namespace associated with a namespace prefix.
一般名前空間とXMLの場合のように、のxmlns属性は、デフォルトの名前空間または名前空間接頭辞に関連付けられた名前空間のいずれかを定義するプレゼンス情報の任意の要素で使用することができます。
Except as noted below, a processor of PRESENCE INFORMATION MUST ignore any XML element with an unrecognized name (i.e., having an unrecognized namespace URI, or an unrecognized local name within that namespace). This includes all of the element content, even if it appears to contain elements with recognized names.
以下に記載されている場合を除き、プレゼンス情報のプロセッサが認識されていない名前のXML要素（すなわち、認識されていない名前空間URI、又はその名前空間内の認識されていないローカル名を有する）を無視しなければなりません。これは、認識される名前を持つ要素を含むように見える場合でも、要素の内容がすべて含まれています。
Extensions to PIDF are informational in nature - they provide additional information beyond <basic> status. However, in order to understand a complex extension, nested elements within an extension element might need to be marked as mandatory. In such cases, the element name is qualified with a mustUnderstand='true' or mustUnderstand='1' attribute. See section 4.3.3 for an example.
PIDFの拡張は、自然の中で情報提供している - 彼らは、<基本>状態以外の追加情報を提供します。しかし、複雑な拡張を理解するために、拡張要素内のネストされた要素は必須としてマークする必要がある場合があります。このような場合には、要素名はでmustUnderstand =「true」またはでmustUnderstand =「1」属性で修飾されています。例えばセクション4.3.3を参照してください。
NOTE: a mustUnderstand='true' or mustUnderstand='1' attribute within an element that is being ignored is itself ignored. The writer of nested mandatory-to-understand information is responsible for ensuring that any enclosing element is also labelled with a mustUnderstand='true' or mustUnderstand='1' attribute, if necessary.
注：無視されている要素内にmustUnderstand =「true」またはでmustUnderstand =「1」の属性は、それ自体が無視されます。ネストされた義務的に理解情報の作家は、必要に応じて任意の囲み要素はまた、のmustUnderstand =「true」またはでmustUnderstand =「1」属性で標識されていることを確実にする責任があります。
This specification defines (section 4.1) elements within the 'urn:ietf:params:xml:ns:pidf' namespace that MUST be recognized in CPP presence data. Processors MUST handle these as described, even if they do not carry a mustUnderstand attribute. The XML Schema Definition (section 4.4) indicates those elements that MUST be present in a valid presence information document.
本明細書の定義（セクション4.1） 'URN：IETF：paramsは：XML：NS：PIDF' 内の要素CPPプレゼンスデータで認識されなければならない名前空間。プロセッサは、彼らがmustUnderstand属性を運ばない場合でも、説明したように、これらを処理しなければなりません。 XMLスキーマ定義（セクション4.4）は、有効なプレゼンス情報文書中に存在していなければなりませんこれらの要素を示しています。
If an agent receives PRESENCE INFORMATION with a <status> block containing an unrecognized element with a mustUnderstand='true' (or '1') attribute, it should treat that entire element and any content as unrecognized and not attempt to process it.
エージェントはでmustUnderstand =「真」（または「1」）属性と認識されていない要素を含む<状態>ブロックでプレゼンス情報を受信した場合、その要素全体ととして認識されていない任意のコンテンツを処理し、それを処理することを試みるべきではありません。
In order to ensure that minimal implementations can correctly process basic PIDF information the mustUnderstand attribute MUST be used only within optional elements nested in a <status> element. This will ensure that problems processing an extension are restricted to that extension and do not affect the processing of the basic PIDF information defined in this specification.
最小限の実装が正しく基本PIDF情報にmustUnderstand属性を処理できることを確実にするためにのみ、<状態>要素にネストオプション要素内で使用されなければなりません。これは、拡張機能の処理の問題は、その拡張子に制限されており、この仕様で定義された基本的なPIDF情報の処理に影響を与えないことを保証します。
This memo defines only the <basic> status value with values of "open" and "closed". Other status values are possible using the standard namespace-based extensibility rules defined above.
このメモは、「オープン」と「閉」の値でのみ、<基本>ステータス値を定義します。その他のステータス値は、上記で定義された標準的な名前空間ベースの拡張ルールを使用して可能です。
For example, a location status value might be included thus:
例えば、位置状態値は、このように含まれている場合があります。
<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:local="urn:example-com:pidf-status-type" entity="pres:someone@example.com"> <tuple id="ub93s3"> <status> <basic>open</basic> <local:location>home</local:location> </status> <contact>im:someone@example.com</contact> </tuple> </presence>
<？xml version = "1.0" エンコード= "UTF-8"？> <プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：ローカル= "URN：例-COM：PIDF-ステータス型"実体=" PRES：someone@example.com "> <タプルID =" ub93s3" > <状態> <基本>開く</基本> <ローカル：場所>ホーム</ローカル：場所> </状態> <連絡先>イム：someone@example.com </連絡先> </タプル> </プレゼンス>
Some new status values will 'extend' the value of the <basic> element. For example, a status value defined for use with instant messaging may include values such as 'away', 'busy' and 'offline'. In order that some level of interoperability be maintained with user agents that don't recognize the new extension, the <basic> status value must also be included. This means that extensions are not obligated to define a mapping from each of their values to OPEN or CLOSED.
いくつかの新しいステータス値は、<基本>要素の値を「拡張」します。たとえば、インスタントメッセージングを使用するために定義されたステータス値は、「離れて」、「忙しい」と「オフライン」として値を含んでいてもよいです。相互運用性のいくつかのレベルが新しい拡張子を認識しないユーザエージェントで維持されるようにするために、<基本>ステータス値も含まれている必要があります。これは、拡張が開いているか閉じためにそれらの値のそれぞれからマッピングを定義する義務はないことを意味します。
Although the existing PIDF definition allows arbitrary elements to appear in the <status> element, it may be sometimes desirable to standardize extension status elements and their semantics (the meanings of particular statuses, how they should be interpreted). The URN 'urn:ietf:params:xml:ns:pidf:status' has been specified as an umbrella namespace under which extensions to the <status> PIDF element should be specified (e.g., urn:ietf:params:xml:ns:pidf:status:my-extension). New values under this namespace MUST be defined by a standards-track RFC.
既存のPIDF定義は、任意の要素は、<状態>要素内に現れることを可能にするが、拡張状態要素とその意味論（それらは解釈されるべき方法を特定の状態、の意味）を標準化することが望ましい場合があってもよいです。 URN 'URN：IETF：のparams：XML：NS：PIDF：状態' <状態>への拡張その下で傘名前空間として指定されているが、PIDF要素が指定されなければならない（例えば、URN：IETF：のparams：XML：NS： PIDF：状態：私の拡張）。この名前空間の下に新しい値が標準トラックRFCで定義されなければなりません。
The following example XML Schema defines an extension for <location> presence information, which can have the values of 'home', 'office', or 'car'. If the <location> element were standardized, this document would be made available in an RFC along with information about the use of the extension. These extensions should use the namespace 'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an extension should register an extension name within that namespace with IANA.
次の例XMLスキーマは、「ホーム」、「オフィス」または「車」の値を持つことができます。<場所>プレゼンス情報、の拡張子を定義します。 <場所>要素は標準化された場合、この文書は、拡張の使用に関する情報と共にRFCに利用可能であろう。 、そしてIANAと、その名前空間内の拡張名を登録する必要があります拡張子を定義する各RFCこれらの拡張機能は、名前空間「：IETF：のparams：XML：NS：PIDF状態壷」を使用する必要があります。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:status" xmlns:tns="urn:ietf:params:xml:ns:pidf:status" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：PIDF：状態" のxmlns：TNS = "壷：IETF：のparams：XML ：NS：PIDF：状態」のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>
<xs:simpleType name="location"> <xs:restriction base="xs:string"> <xs:enumeration value="home"/> <xs:enumeration value="office"/> <xs:enumeration value="car"/> </xs:restriction> </xs:simpleType>
<XS：単純型名= "場所"> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "ホーム" /> <XS：列挙値= "オフィス" /> <XS：列挙値= "車" /> </ XS：制限> </ XS：単純>
</xs:schema>
</ XS：スキーマ>
In addition to the XML Schema to validate the extension, registration of the extension name with IANA, RFCs defining extensions MUST discuss:
拡張子を検証するXMLスキーマ、IANAと拡張子名の登録に加えて、拡張を定義するRFCは議論しなければなりません：
- The domain of applicability of the extension. Is this extension exclusively valuable to IM clients, telephones, geolocators, etc? What sorts of presence applications would use this extension and under what circumstances?
- 延長の適用のドメイン。この拡張機能は、IMクライアント、電話、geolocatorsに独占的に価値がある、など？プレゼンスアプリケーションのどのような種類がこの拡張機能を使用し、どのような状況下でのでしょうか？
- Semantics for the presence states defined in the extension. What disposition provokes an automated presentity to declare that it is in state X, or does a human select X from a drag-down menu? Is there any general guidance for watchers of presence information with state Y (for example, how they should best attempt to communicate with the presentity, if at all, when the principal is in state Y).
- 拡張で定義されたプレゼンス状態のためのセマンティクス。どのような処分は、それが、状態Xであることを宣言するために自動化されたプレゼンを誘発する、またはヒトは、ドラッグダウンメニューから[X]を選択しますか？ （すべてであれば元本が状態Yにあるとき、例えば、それらがどのようにプレゼンと通信するための最良の試みをすべきである）状態Yとのプレゼンス情報のウォッチャーのための任意の一般的なガイダンスがあります。
Extensions SHOULD also discuss:
拡張も議論する必要があります：
- How, if at all, any presence states defined in the extension related to <basic>, or to any relevant extension previously published in an RFC. For example, "state Z implies OPEN, so it MUST NOT be used if a basic state of CLOSED is expressed", or "you should use the extension in this document, not the extension in RFC QQQQ, if your circumstances are as follows...."
- どのように、すべての場合は、<基本>に関連した拡張で定義された任意のプレゼンス状態、または以前にRFCに掲載されたすべての関連の拡張子に。次のように自分の状況がある場合は、この文書の拡張子ではなく、RFC QQQQに拡張子を使用する必要があります」、または例えば、「CLOSEDの基本的な状態が表現されている場合、それは使用してはいけませんので、状態Zは、OPENを意味します」。 ...」
The following instance document uses a hypothetical 'pidf:im' XML namespace as an example of the sort of status extension that might be developed for PIDF.
PIDFのために開発されるかもしれない状況の拡張子の種類の例として、XML名前空間：以下のインスタンス文書は、仮想的な「イムPIDF」を使用しています。
<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:im="urn:ietf:params:xml:ns:pidf:im" xmlns:myex="http://id.example.com/presence/" entity="pres:someone@example.com"> <tuple id="bs35r9"> <status> <basic>open</basic> <im:im>busy</im:im> <myex:location>home</myex:location> </status> <contact priority="0.8">im:someone@mobilecarrier.net</contact> <note xml:lang="en">Don't Disturb Please!</note> <note xml:lang="fr">Ne derangez pas, s'il vous plait</note> <timestamp>2001-10-27T16:49:29Z</timestamp> </tuple> <tuple id="eg92n8"> <status> <basic>open</basic> </status> <contact priority="1.0">mailto:someone@example.com</contact> </tuple> <note>I'll be in Tokyo next week</note> </presence>
<？xml version = "1.0" エンコード= "UTF-8"？> <プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：IM = "URN：IETF：paramsは：XML：NS：PIDF ：IM」のxmlns：myex = "http://id.example.com/presence/" エンティティ= "PRES：someone@example.com"> <タプルID = "bs35r9"> <状態> <基本>開きます</基本的な> <IM：IM>忙しい</ IM：IM> <myex：場所>ホーム</ myex：場所> </状態> <連絡先の優先順位= "0.8"> IM：someone@mobilecarrier.net </連絡先> <ノートのxml：langは= "EN"> </注意してください> <ノートXMLを邪魔しないでください！LANG = "FR">ネオンderangezのPAS、s'il vousのひだ</注意> <タイムスタンプ> 2001-10-27T16 ：49：29Z </タイムスタンプ> </タプル> <タプルID = "eg92n8"> <状態> <基本>開く</基本> </状態> <連絡先の優先= "1.0">のmailto：someone@example.com </連絡先> </タプル> <注意>私は</注意> </プレゼンス>東京で来週になるだろう
<?xml version="1.0" encoding="UTF-8"?> <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf" xmlns:myex="http://id.example.com/presence/" entity="pres:someone@example.com"> <impp:tuple id="ck38g9"> <impp:status> <impp:basic>open</impp:basic> </impp:status> <myex:mytupletag>Extended value in tuple</myex:mytupletag> <impp:contact priority="0.65">tel:+09012345678</impp:contact> </impp:tuple> <impp:tuple id="md66je"> <impp:status> <impp:basic>open</impp:basic> </impp:status> <impp:contact priority="1.0"> im:someone@mobilecarrier.net</impp:contact> </impp:tuple> <myex:mytag>My extended presentity information</myex:mytag> </impp:presence>
<？xml version = "1.0" エンコードは= "UTF-8"？> <IMPP：プレゼンスのxmlns：IMPP = "壷：IETF：のparams：XML：NS：PIDF" のxmlns：myex =「のhttp：//id.example .COM /プレゼンス/ "エンティティ=" PRESは：someone@example.com "> <IMPP：タプルID =" ck38g9「> <IMPP：状態> <IMPP：基本>開く</ IMPP：基本> </ IMPP：状態> <myex：mytupletag>タプルの拡張値</ myex：mytupletag> <IMPP：コンタクト優先= "0.65">電話：09012345678 </ IMPP：接触> </ IMPP：タプル> <IMPP：タプルID =「md66je "> <IMPP：状態> <IMPP：基本>開く</ IMPP：基本> </ IMPP：状態> <IMPP：連絡先の優先=" 1.0「> INV someone@mobilecarrier.net </ IMPP：接触> </ IMPP：タプル> <myex：mytagという>マイ拡張プレゼン情報</ myex：mytagという> </ IMPP：存在>
<?xml version="1.0" encoding="UTF-8"?> <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf" xmlns:myex="http://id.mycompany.com/presence/" entity="pres:someone@example.com"> <impp:tuple id="tj25ds"> <impp:status> <impp:basic>open</impp:basic> </impp:status> <myex:complexExtension> <myex:ex1 impp:mustUnderstand="1">val1</myex:ex1> <myex:ex2>val2</myex:ex2> </myex:complexExtension> <impp:contact priority="0.725">tel:+09012345678</impp:contact> </impp:tuple> <myex:mytag>My extended presentity information</myex:mytag> </impp:presence>
<？xml version = "1.0" エンコード= "UTF-8"？> <IMPP：プレゼンスのxmlns：IMPPは= "壷：IETF：のparams：XML：NS：PIDF" のxmlns：myex =「のhttp：//id.mycompany .COM /プレゼンス/ "エンティティ=" PRES：someone@example.com "> <IMPP：タプルID =" tj25ds「> <IMPP：状態> <IMPP：基本>開く</ IMPP：基本> </ IMPP：状態> <myex：complexExtension> <myex、EX- 1 IMPP：でmustUnderstand = "1"> VAL1 </ myex、EX- 1> <myex、EX2> VAL2 </ myex、EX2> </ myex：complexExtension> <IMPP：コンタクト優先度= " 0.725「>電話番号：09012345678 </ IMPP：接触> </ IMPP：タプル> <myex：mytagという>マイ拡張プレゼン情報</ myex：mytagという> </ IMPP：存在>
Here, <myex:ex1> must be understood and, if it is not recognized, <myex:complexExtension> MUST be ignored. <myex:mytag> and <myex:ex2> MAY be ignored if they are not recognized.
ここで、<myex：EX1>を理解しなければならないと、それが認識されない場合は、<myex：complexExtension>無視しなければなりません。 <myex：mytagという>と<myex：EX2>彼らは認識されない場合は無視してもよいです。
This section gives the XML Schema Definition [XMLSchema1] of the "application/pidf+xml" format. This is presented as a formal definition of the "application/pidf+xml" format. Note that the XML Schema definition is not intended to be used with on-the-fly validation of the presence XML document.
このセクションでは、[XMLSchema1は]「アプリケーション/ PIDF + XML」形式のXMLスキーマ定義を与えます。これは、「アプリケーション/ PIDF + XML」形式の正式な定義として提示されます。 XMLスキーマ定義が存在するXML文書のオンザフライ検証で使用されるものではないことに注意してください。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf" xmlns:tns="urn:ietf:params:xml:ns:pidf" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
xmlns "PIDF壷：IETF：のparams：XML：：NS"：の<？xml version = "1.0" エンコード= "UTF-8"？> <XSスキーマのtargetNamespace = TNS = "壷：IETF：のparams：XML：NS ：PIDF」のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>
<!-- This import brings in the XML language attribute xml:lang--> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<！ - このインポートは、XML言語の属性xmlにもたらします：LANG - > <XS：インポートの名前空間= "http://www.w3.org/XML/1998/namespace" のschemaLocation = "のhttp：// WWW。 w3.org/2001/xml.xsd "/>
<xs:element name="presence" type="tns:presence"/>
<XS：要素名= "存在" タイプ= "TNS：プレゼンス" />
<xs:complexType name="presence"> <xs:sequence> <xs:element name="tuple" type="tns:tuple" minOccurs="0" maxOccurs="unbounded"/>
<XS：complexTypeの名前= "存在"> <XS：配列> <XS：要素名= "タプル" タイプ= "TNS：タプル" のminOccurs = "0" のmaxOccurs = "無制限" />
<xs:element name="note" type="tns:note" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="entity" type="xs:anyURI" use="required"/> </xs:complexType>
<XS：要素名=タイプ= "注" "TNSを：NOTE" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS： "##その他" のいずれかの名前空間=のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "実体" タイプ= "XS：anyURIの" 使用は= "必要" /> </ XS：complexTypeの>
<xs:complexType name="tuple"> <xs:sequence> <xs:element name="status" type="tns:status"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="contact" type="tns:contact" minOccurs="0"/> <xs:element name="note" type="tns:note" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/> </xs:sequence> <xs:attribute name="id" type="xs:ID" use="required"/> </xs:complexType>
<XS：complexTypeの名前= "タプル"> <XS：シーケンス> <XS：要素名= "ステータス" タイプ= "TNS：状態" /> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：要素名= "接触" タイプ= "TNS：接触" のminOccurs = "0" /> <XS：要素名= "メモ" タイプ= "TNS注：" minOccurs = "0" のmaxOccurs = "無制限" /> <XS：要素名= "タイムスタンプ" タイプ= "XS：dateTimeの" minOccurs属性= "0" /> </ XS：配列> <XS：属性名= "ID"タイプ= "XS：ID" 使用= "必須" /> </ XS：complexTypeの>
<xs:complexType name="status"> <xs:sequence> <xs:element name="basic" type="tns:basic" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:simpleType name="basic"> <xs:restriction base="xs:string"> <xs:enumeration value="open"/> <xs:enumeration value="closed"/> </xs:restriction> </xs:simpleType>
<XS：complexTypeの名= "ステータス"> <XS：シーケンス> <XS：要素名= "基本" タイプ= "TNS：基本" のminOccurs = "0" /> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> </ XS：complexTypeの> <XS：単純名は= "基本"> <XS：制限ベース= "XS：文字列"> <XS：列挙値= "オープン" /> <XS：列挙値= "閉" /> </ XS：制限> </ XS：simpleTypeの>
<xs:complexType name="contact"> <xs:simpleContent> <xs:extension base="xs:anyURI"> <xs:attribute name="priority" type="tns:qvalue"/> </xs:extension> </xs:simpleContent> </xs:complexType>
<XS：complexTypeの名前= "接触"> <XSD：simpleContentを> <XSD：増設ベース= "XS：anyURIの"> <XS：属性名= "優先度" タイプ= "TNS：のqvalue" /> </ XS：拡張> </ XS：simpleContentを> </のxsd：complexTypeの>
<xs:complexType name="note"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute ref="xml:lang"/> </xs:extension>
<XS：complexTypeの名前= "ノート"> <XS：simpleContentを> <XS：増設ベース= "XS：文字列"> <XS：属性REF = "XML：LANG" /> </ XS：拡張>
</xs:simpleContent> </xs:complexType>
</ XS：simpleContentを> </ XS：complexTypeの>
<xs:simpleType name="qvalue"> <xs:restriction base="xs:decimal"> <xs:pattern value="0(.[0-9]{0,3})?"/> <xs:pattern value="1(.0{0,3})?"/> </xs:restriction> </xs:simpleType>
<XS：単純型名= "のqvalue"> <XS：制限ベース= "XS：小数"> <XS：パターン値= "0（[0-9] {0,3}）。？" /> <XS：パターン値= "1（0.0 {0,3}）？" /> </ XS：制限> </ XS：simpleTypeの>
<!-- Global Attributes --> <xs:attribute name="mustUnderstand" type="xs:boolean" default="0"> <xs:annotation> <xs:documentation> This attribute may be used on any element within an optional PIDF extension to indicate that the corresponding element must be understood by the PIDF processor if the enclosing optional element is to be handled. </xs:documentation> </xs:annotation> </xs:attribute> </xs:schema>
<！ - グローバル属性 - > <XS：属性名= "のmustUnderstand" タイプ= "XS：ブール" デフォルト= "0"> <XS：注釈> <XS：ドキュメント>この属性は、内の任意の要素で使用することができます封入任意の要素が処理される場合、対応する要素は、PIDFプロセッサにより理解されなければならないことを示すために、オプションのPIDF拡張。 </ XS：ドキュメンテーション> </ XS：注釈> </ XS：属性> </ XS：スキーマ>
This memo calls for IANA to:
このメモはIANAへのために呼び出します。
- register a new MIME content-type application/pidf+xml, per [MIME],
- [MIME]あたりの新しいMIMEコンテンツタイプアプリケーション/ PIDF + XMLを、レジスタ
- register a new XML namespace URN per [XML-Registry].
- [XML-レジストリ]あたりの新しいXML名前空間のURNを登録します。
- register a new XML namespace URN for status extensions per [XML-Registry].
- [XML-レジストリ]あたりの状態の拡張のための新しいXML名前空間のURNを登録します。
The registration templates for these are below. For more information on status extensions, see section 4.2.5.
これらの登録テンプレートは以下の通りです。ステータスの拡張機能の詳細については、セクション4.2.5を参照してください。
To: ietf-types@iana.org Subject: Registration of MIME media type application/pidf+xml
To：ietf-types@iana.org件名：MIMEメディアタイプapplication / PIDF + XMLの登録
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: pidf+xml
MIMEサブタイプ名：PIDF + xmlの
Required parameters: (none)
必須パラメータ：（なし）
Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8.
オプションのパラメータ：charsetが囲まれたXMLの文字エンコーディングを示します。デフォルトはUTF-8です。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC 3023], section 3.2.
エンコードの考慮事項：使用される文字エンコーディングに応じて、8ビット文字を採用することができるXMLを使用しています。 RFC 3023 [RFC 3023]、セクション3.2を参照してください。
Security considerations: This content type is designed to carry presence data, which may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information.
セキュリティの考慮事項：このコンテンツの種類は、個人情報と見なすことができるプレゼンスデータを運ぶために設計されています。適切な予防措置は、この情報の開示を制限するために採用されるべきです。
Interoperability considerations: This content type provides a common format for exchange of presence information across different CPP compliant protocols.
相互運用性に関する注意事項：このコンテンツタイプは異なるCPP準拠したプロトコルにわたってプレゼンス情報を交換するための共通フォーマットを提供します。
Published specification: RFC 3863
公開された仕様：RFC 3863
Applications which use this media type: Presence and instant messaging systems.
プレゼンスとインスタントメッセージングシステム：このメディアタイプを使用するアプリケーション。
Additional information: Magic number(s): File extension(s): Macintosh File Type Code(s):
追加情報：マジックナンバー（S）：ファイルの拡張子（S）：Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information: Hiroyasu Sugano EMail: sugano.h@jp.fujitsu.com
人とEメールアドレスは、詳細のために連絡する：博康菅野Eメール：sugano.h@jp.fujitsu.com
Intended usage: LIMITED USE
意図している用法：限定使用
Author/Change controller: This specification is a work item of the IETF IMPP working group, with mailing list address <impp@iastate.edu>.
著者/変更コントローラは、この仕様では、メーリングリストのアドレス<impp@iastate.edu>で、IETF IMPPワーキンググループの作業項目です。
Other information: This media type is a specialization of application/xml [RFC 3023], and many of the considerations described there also apply to application/pidf+xml.
その他の情報：このメディアタイプは、アプリケーション/ XML [RFC 3023]の特殊化であり、そこに記載考察の多くは、アプリケーション/ PIDF + XMLに適用します。
URI urn:ietf:params:xml:ns:pidf
URI骨壷：IETF：のparams：XML：NS：PIDF
Description: This is the XML namespace URI for XML elements defined by RFC 3863 to describe CPP presence information in application/pidf+xml content type.
説明：これは、アプリケーション/ PIDF + XMLコンテンツタイプCPPプレゼンス情報を記述するためにRFC 3863によって定義されたXML要素のXML名前空間URIです。
Registrant Contact IETF, IMPP working group, <impp@iastate.edu> Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
登録者連絡先IETF、IMPPワーキンググループ、<impp@iastate.edu>博康菅野、<sugano.h@jp.fujitsu.com>
XML BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <title>Namespace for CPP presence information</title> </head> <body> <h1>Namespace for CPP presence information</h1> <h2>urn:ietf:params:xml:ns:pidf</h2> <p>See <a href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]"> RFC3863</a>.</p> </body> </html> END
！XML BEGIN <？xmlのバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C // DTD XHTML Basicの1.0 // EN"「http://www.w3.org/TR/xhtml-basic/xhtml -basic10.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml "> <HEAD> <メタHTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset = UTF CPPプレゼンス情報について-8" /> <タイトル>名前空間CPPの存在のための情報</ TITLE> </ HEAD> <BODY> <H1>名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：PIDF </ H2> <P> <a href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]"> RFC3863 </a>を参照してください。</ P> </ body> </ html>このEND
5.3. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:status'
5.3. 以下のためのURNサブ名前空間の登録 '：IETF：のparams：XML：NS：URN PIDF：状態'
URI urn:ietf:params:xml:ns:pidf:status
URI骨壷：IETF：のparams：XML：NS：PIDF：ステータス
Description: This is the XML namespace URI for XML elements defined by RFC 3863 to describe extensions to the status of CPP presence information in application/pidf+xml content type.
説明：これは、アプリケーション/ PIDF + XMLコンテンツタイプCPPプレゼンス情報のステータスへの拡張を記述するためにRFC 3863によって定義されたXML要素のXML名前空間URIです。
Registrant Contact IETF, IMPP working group, <impp@iastate.edu> Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
登録者連絡先IETF、IMPPワーキンググループ、<impp@iastate.edu>博康菅野、<sugano.h@jp.fujitsu.com>
XML BEGIN <?xml version="1.0"?>
XML BEGINの<？xml version = "1.0"？>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <title>Namespace for CPP status extensions</title> </head> <body> <h1>Namespace for CPP presence information extensions</h1> <h2>urn:ietf:params:xml:ns:pidf:status</h2> <p>See <a href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]"> RFC3863</a>.</p> </body> </html> END
<！DOCTYPE htmlののPUBLIC " - // W3C // DTD XHTML Basicの1.0 // EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <HTMLのxmlns = "HTTP ：//www.w3.org/1999/xhtml "> <HEAD> <META HTTP-当量=" コンテンツタイプ」コンテンツ= "text / htmlの;のcharset = UTF-8" /> <タイトル> CPPステータスの名前空間拡張子</ TITLE> </ HEAD> <BODY> <H1> CPPプレゼンス情報の拡張</ H1> <H2> URNのための名前空間：IETF：のparams：XML：NS：PIDF：状況</ H2> <P>を参照してください< HREF = "[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]"> RFC3863 </a>でます。</ p> </ body> </ HTML> END
Because presence is very privacy-sensitive information, the protocol for the presence information MUST have capabilities to protect PIDF from possible threats, such as eavesdropping, corruption, tamper and replay attacks. These security mechanisms must be able to be used end-to-end between presentities and watchers, even if the watcher and the presentity employ different presence protocols and communicate through a CPP gateway. Since the 'application/pidf+xml' MIME type is defined for this PIDF document, staging security for PIDF at the MIME level (with S/MIME [RFC3851]) seems appropriate. Therefore, PIDF should follow the normative recommendations for the use of S/MIME (including minimum ciphersuites) given in the core CPP specification.
存在が非常にプライバシーの機密情報であるため、プレゼンス情報のためのプロトコルは、盗聴、破損、改ざんやリプレイ攻撃などの脅威の可能性からPIDFを保護する能力を持たなければなりません。これらのセキュリティメカニズムは、ウォッチャとプレゼンティティが異なるプレゼンスプロトコルを使用し、CPPゲートウェイを介して通信を行う場合であっても、プレゼンティティとウォッチャーとの間のエンドツーエンドを使用することができなければなりません。 「アプリケーション/ PIDF + XML」MIMEタイプがこのPIDF文書のために定義されているので、（S / MIME [RFC3851]を用いて）MIMEレベルPIDFのセキュリティをステージングすると、適切と思われます。したがって、PIDFは、コアCPP仕様で指定された（最小暗号スイートを含む）は、S / MIMEを使用するための規範的な勧告に従うべきです。
Note that the use of timestamps in PIDF (see section 4.1.7) can provide some rudimentary protection against replay attacks. If a watcher receives presence information that is outdated, it SHOULD be ignored. A watcher can determine that presence information is outdated in a number of fashions. Most significantly, if the newest timestamp in presence information is older than the newest timestamp in the last received presence information, it should be considered outdated. Applications and protocols also are advised to adopt their own rules for determining how frequently presence information should be refreshed. For example, if presence information appears to be more than one hour old, it could be considered outdated (a notification generated for this presence information will not take such a long time to reach a watcher, and if a presentity has not refreshed its presence state in the last hour, it is probably offline).
PIDFのタイムスタンプの使用は（セクション4.1.7を参照）、リプレイ攻撃に対するいくつかの初歩的な保護を提供できることに注意してください。ウォッチャーが古いプレゼンス情報を受信した場合、それは無視されるべきです。ウォッチャーは、プレゼンス情報をファッションの数に古いされていることを判断することができます。プレゼンス情報の最新タイムスタンプが最後に受信したプレゼンス情報の最新タイムスタンプより古い場合に最も重要なこと、それは時代遅れと見なされるべきです。アプリケーションおよびプロトコルはまた、プレゼンス情報をリフレッシュする頻度を決定するための独自のルールを採用することをお勧めします。プレゼンス情報が一時間以上古いように見える場合、このプレゼンス情報のために生成される通知がウォッチャーに到達するために、このような長い時間がかかることはありません（時代遅れと考えることができ、そしてプレゼンは、その存在の状態に更新していない場合過去1時間に、それは）おそらくオフラインです。
All the processors conformant to this specification MUST be able to generate and accept UTF-8 encoding, this being one of the mandatory character encodings for XML conforming processors, and also required by the policies set out in RFC 2277 [RFC2277].
この仕様に準拠すべてのプロセッサが、これはプロセッサを適合するXMLに必須の文字エンコーディングの一つである、UTF-8エンコーディングを生成し、受け入れることができなければならない、ともRFC 2277で定められたポリシーで必要とされる[RFC2277]。
Other character encodings MAY be accepted (but CPP compliant processors are strongly discouraged from emitting anything other than UTF-8).
その他の文字エンコーディングが受け入れられる（しかし、CPP準拠したプロセッサは強くUTF-8以外のものを放出するからがっかりしています）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、BCP 14、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>
[XML]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第二版）"、W3C勧告、2000年10月、<HTTP：// www.w3.org/TR/2000/REC-xml-20001006>
[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月。
Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996.
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
ムーア、K.、「MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張」、RFC 2047、1996年11月。
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
解放された、N.、Klensin、J.、およびJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、BCP 13、RFC 2048、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
解放された、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, March 1995.
[RFC3066] Alvestrand、H.、 "言語識別のためのタグ"、BCP 47、RFC 3066、1995年3月。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339] Klyne、G.とC.ニューマン、 "インターネット上の日付と時刻：タイムスタンプ"、RFC 3339、2002年7月。
[XML-NS] Bray, T., Hollander, D., and A. Layman "Namespaces in XML", W3C recommendation: xml-names, 14 January 1999, <http://www.w3.org/TR/REC-xml-names>
[XML-NS]ブレイ、T.、オランダ、D.、およびA.素人 "XMLにおける名前空間"、W3C勧告：XML名前、1999年1月14日、<http://www.w3.org/TR/REC -xml-名>
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[URN]堀、R.、 "URN構文"、RFC 2141、1997年5月。
[URN-NS-IETF] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[URN-NS-IETF]堀、R.、 "URN名前空間IETFドキュメントについて"、RFC 2648、1999年8月。
[XML-Registry] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[XML-レジストリ] Mealling、M.、 "IETF XMLレジストリ"、RFC 3688、2004年1月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[XMLSchema1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[XMLSchema1は]トンプソン、H.、ブナ、D.、マロニー、M.、およびN.メンデルゾーン、 "XMLスキーマパート1：構造"、W3C REC-XMLSCHEMA-1、2001年5月、<のhttp：//www.w3 .ORG / TR / XMLSCHEMA-1 />。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[RFC2779]の日、M.、アガルワル、S.、モール、G.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、RFC 2779、2000年2月。
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPIM]ピーターソン、J.、 "インスタントメッセージングのための共通プロファイル（CPIM）"、RFC 3860、2004年8月。
[CPP] Peterson, J., "Common Presence for Presence (CPP)", RFC 3859, August 2004.
[CPP]ピーターソン、J.、 "プレゼンスのための一般的なプレゼンス（CPP）"、RFC 3859、2004年8月。
[vCard] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[vCardの]ドーソン、F.とT.ハウズ、 "vCardのMIMEディレクトリプロフィール"、RFC 2426、1998年9月。
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、エド。、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[RFC3282] Alvestrand、H.、 "コンテンツ言語ヘッダ"、RFC 3282、2002年5月。
Appendix A. Document Type Definitions
付録A.の文書型定義
The Document Type Definition for the "application/pidf+xml" format is described. The DTD here is presented only for informational for those who may not familiar with the XML Schema definition.
「アプリケーション/ PIDF + XML」形式の文書型定義が記載されています。 DTDは、ここでの唯一のXMLスキーマ定義に慣れていないかもしれない人のための情報提供のために提示されます。
Note: the DTD does not show where extension elements can be added. See the XML Schema for that information.
注意：拡張要素を追加することができる場所DTDは表示されません。その情報のためのXMLスキーマを参照してください。
<!ENTITY % URL "CDATA"> <!ENTITY % URI "CDATA"> <!ENTITY % TUPLEID "CDATA"> <!ENTITY % DATETIME "CDATA"> <!ENTITY % VALUETYPE "CDATA"> <!ENTITY % PRIORITY "CDATA"> <!ENTITY % NOTE "CDATA">
<！ENTITY％以下のURL "CDATA"> <！ENTITY％のURI "CDATA"> <！ENTITY％以下のTUPLEID "CDATA"> <！ENTITY％でのDATETIME "CDATA"> <！ENTITY％以下のVALUETYPE "CDATA"> <！ENTITY％以下のPRIORITY "CDATA"> <！ENTITY％注意 "CDATA">
<!ELEMENT presence ((tuple*),note?)> <!ATTLIST presence xmlns %URI; #REQUIRED entity %URL; #REQUIRED >
！<！ELEMENTの存在（？（タプル*）、注意してください）> <ATTLISTプレゼンスのxmlns％URI; #REQUIREDエンティティ％のURL。 #REQUIRED>
<!ELEMENT tuple (status,contact?,note?,timestamp?)> <!ATTLIST tuple id %TUPLEID; #REQUIRED >
<！ELEMENTタプル（ステータス、連絡先、メモ、タイムスタンプ？？？）> <ATTLISTタプルのid％のTUPLEID！; #REQUIRED>
<!ELEMENT status (basic?)> <!ELEMENT basic CDATA>
<！ELEMENT状況（基本的な？）> <！ELEMENT基本CDATA>
<!ELEMENT contact %URL;> <!ATTLIST contact priority %PRIORITY; #IMPLIED >
<！ELEMENTコンタクト％のURL;> <！ATTLIST接触優先％のPRIORITY; #IMPLIED>
<!ELEMENT note %NOTE;>
<！ELEMENTノート％注;>
<!ELEMENT timestamp %DATETIME;>
<！ELEMENTのタイムスタンプ％のDATETIME;>
Authors' Addresses
著者のアドレス
Hiroyasu Sugano Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan
ひろやす すがの ふじつ ぁぼらとりえｓ Ｌｔｄ。 ６４、 にしわき おｈくぼーちょ あかし ６７４ー８５５５ じゃぱん
EMail: sugano.h@jp.fujitsu.com
メールアドレス：sugano.h@jp.fujitsu.com
Shingo Fujimoto Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan
しんご ふじもと ふじつ ぁぼらとりえｓ Ｌｔｄ。 ６４、 にしわき おｈくぼーちょ あかし ６７４ー８５５５ じゃぱん
EMail: shingo_fujimoto@jp.fujitsu.com
メールアドレス：shingo_fujimoto@jp.fujitsu.com
Graham Klyne Nine by Nine
ナインにより、グラハムKlyneナイン
EMail: GK@ninebynine.org
メールアドレス：GK@ninebynine.org
Adrian Bateman VisionTech Limited Colton, Staffordshire, WS15 3LD United Kingdom
エイドリアン・ベイトマンVisionTech限定コルトン、スタッフォードシャー、WS15 3LDイギリス
EMail: bateman@acm.org
メールアドレス：bateman@acm.org
Wayne Carr Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 USA
ウェイン・カーインテルコーポレーション2111 NE 25日アベニューヒルズボロ、OR 97124 USA
EMail: wayne.carr@intel.com
メールアドレス：wayne.carr@intel.com
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520 USA
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz
電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz
Full Copyright Statement
完全な著作権声明
Copyright (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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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機能のための基金は現在、インターネット協会によって提供されます。