[要約] RFC 3863は、Presence Information Data Format (PIDF)に関する標準化されたデータフォーマットです。PIDFは、ユーザーの存在情報を表現するために使用され、インスタントメッセージングやプレゼンスサービスなどのアプリケーションで利用されます。このRFCの目的は、PIDFの仕様を提供し、相互運用性とセキュリティを確保することです。
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)
存在情報データ形式（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）The Internet Society（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エンティティを表す新しいメディアタイプ「Application/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準拠の存在プロトコルの共通の存在データ形式として存在情報データ形式（PIDF）をさらに定義し、セキュリティとパフォーマンスに付随する利点を持つ、変更なしでCPP準拠のプロトコル境界を越えて存在情報を転送できるようにします。
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.
このメモで指定された形式は、RFC 2779で必要なベース存在形式と拡張性を定義します。IMPPモデルドキュメント[RFC2778]によって定義された最小限の存在ステータス値を定義します。ただし、存在アプリケーションは、このメモで提供される拡張性フレームワークを使用して、独自のステータス値を定義することができます。このような拡張ステータス値を定義することは、このメモの範囲を超えています。
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]で定義されている語彙を使用しています。メモの閉じた、インスタントメッセージ、オープン、プレゼンスサービス、プレゼンテーション、ウォッチャー、およびウォッチャーユーザーエージェントなどの用語は、そこに定義されているのと同じ意味で使用されます。
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].
「必須」、「必要はない」、「必須」、「は」、「「必要」はない」、「推奨」、「5月」、および「オプション」は、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) 存在情報は、1つ以上の存在タプルで構成されており、存在タプルはステータス、オプションの通信アドレス、およびオプションのその他の存在マークアップで構成されています。このドキュメントでは、通信アドレスの連絡先アドレスがURI（RFC2778：SEC.3）のみを参照するように理解されていることに注意してください。
(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) ステータスには、少なくとも相互に極限の値が開いて閉じているため、インスタントメッセージを受け入れるための意味があり、他のコミュニケーション手段に意味がある場合があります。インスタントメッセージの受け入れについて何も意味しない他のステータスの値があるかもしれません。これらの他のステータスの値は、オープンとクローズと組み合わせることができます。または、それらの値と相互に閉鎖される場合があります（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) 共通形式に含まれていない追加情報を表すために、共通の存在形式を拡張する手段が必要です。拡張および登録メカニズムは、新しいステータス条件や他の存在マークアップの新しいフォームなど、存在情報スキーマに対して定義する必要があります（RFC2779：SEC.3.1.4-3.1.5）。
(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) 共通の存在形式には、存在情報が報告されているプレゼン性を一意に識別する手段を含める必要があります（RFC2779：Sec.3.1.2）。
(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) 連絡先アドレスの相対的な優先順位は、存在情報のソースが複数の連絡先の手段よりも優先権を受信者（Watcherユーザーエージェント）に伝えることを許可するために指定されています。
(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) プレゼンス形式には、存在情報の作成のタイムスタンプを含めることができます。存在するドキュメント内のタイムスタンプにより、レシーバーは、それを含むメッセージが遅延している場合でも、データの作成時を知らせることができます。また、基礎となる署名メカニズムとは無関係に、リプレイ攻撃の検出にも使用できます。このメカニズムは、ウォッチャーやプレゼンテーションのグローバルタイム同期システムを想定していないことに注意してください（RFC2779、8.1.4 A7の付録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」を定義します。この仕様は、[RFC3023]で説明されている推奨事項と規則に従って、タイプの命名規則（「XML」接尾辞）や「charset」パラメーターの使用法を含む。
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].
オプションとして定義されていますが、「charset」パラメーターの使用が推奨されます。「charset」パラメーターが指定されていない場合、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 プレゼンティURL：プレゼンテーションの「pres」URLを指定します。o存在タプルのリスト - 識別子：トークン存在情報内でこのタプルを識別します。 - ステータス：オープン/クローズドおよび/または拡張ステータス値。 - 通信アドレス：このタプルの通信手段と連絡先住所。（オプション） - 相対的な優先度：この通信アドレスの優先度を指定する数値値。（オプション） - タイムスタンプ：このタプルの変更のタイムスタンプ（オプション） - 人間の読み取り可能なコメント：このタプルに関する無料のテキストメモ（オプション）
o PRESENTITY human readable comment: free text memo about the PRESENTITY (optional).
o プレゼンティヒューマンリードコメント：プレゼンテーションに関する無料のテキストメモ（オプション）。
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）を定義します。この形式でのプレゼンスペイロードは、プレゼンテーション（プレゼンス情報のソース）によって生成され、解釈や変更なしでプレゼンスサーバーまたはゲートウェイによってウォッチャーに輸送されると予想されます。
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宣言にエンコード宣言を含める必要があります。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ネームスペース名「urn：ietf：params：xml：ns：pidf」に関連付けられています。名前空間は、デフォルトの名前空間である場合があるか、いくつかの名前空間プレフィックスに関連付けられている場合があります（例についてはセクション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を含む）の<tuple>要素が含まれ、その後、<mote>要素の任意の数（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.
<pesconis>要素には、「エンティティ」属性が必要です。「エンティティ」属性の値は、このプレゼンスドキュメントを公開するプレゼントの「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:'.
<pesconding>要素には、存在ドキュメントの基礎となる名前空間を示すために、名前空間宣言（ 'xmlns'）を含める必要があります。この仕様に準拠した存在ドキュメントには、名前空間 'urn：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.
<tuple>要素は、必須の<status>要素で構成される存在タプルを持ち、その後に任意の数のオプションの拡張要素（おそらく他の名前空間から）が続き、その後にオプションの<contact>要素が続き、その後に任意の数のオプション<が続きます。注>要素、その後にオプションの<タイムスタンプ>要素が続きます。
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.
<tuple>要素には、このタプルを同じプレゼンテーションで他のタプルと区別するために使用される「ID」属性を含める必要があります。「ID」属性の値は、同じ提示に対して他のタプルの「ID」属性値内で一意でなければなりません。「ID」値は、同じプレゼンテーションの以前に取得した存在情報で対応するタプルを識別するために、プレゼンスドキュメントを処理するアプリケーションで使用されます。「ID」属性の値は任意の文字列であり、上記のように<Tuple>値を区別する手段を提供する以外に重要ではありません。
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.
<contact>要素はオプションです。これは、通信アドレスを非表示にする必要がある場合や、通信手段に関連しないタプルがある可能性があるためです。<basic>ステータス要素を含むタプルは、<contact>アドレスを含める必要があります。タプルには矛盾する存在状態が含まれる場合があります-1つの<tuple>は<basic> <status> op openを提供する場合があり、同じPIDFに別の<Tuple>が閉じた<basic> <status>を含めることができます。同じ<連絡先>アドレス。
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ユーザーエージェントによってセグメント化された存在情報が理解される方法は、Watcherユーザーエージェントの機能と問題の存在アプリケーションに大きく依存しています。タプルの意味に関するアプリケーション固有またはプロトコル固有の理解がない場合、Watcherユーザーエージェントは次のガイドラインに従うことがあります。Watcherユーザーエージェントは、各<Tuple>の「ID」と以前の通知で受信したものと、Tuppleの両方の<stature>要素を比較するものと相関することにより、最後の通知以来の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.
<status>要素には、1つのオプションの<basic>要素が含まれ、その後、少なくとも1つの子要素が<status>要素に表示されるという制限の下で、任意の数のオプションの拡張要素（おそらく他の名前空間から）が含まれます。これらの子供の要素は、このタプルのステータス値を含んでいます。単一の<tuple>要素で複数のステータス値を許可することにより、さまざまなタイプのステータス値、たとえば到達可能性と場所を<tuple>で表現できます。複数のステータス値の例については、セクション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).
このメモは、<basic>ステータス値要素のみを定義します。その他のステータス値は、標準の拡張性フレームワークを使用して含めることができます（セクション4.2.4を参照）。<status>内で認識されていない要素に遭遇するアプリケーションは、それらが必須の= "true"またはnust understand = "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.
<status>要素には少なくとも1つのステータス値要素が必要ですが、このステータス値は<basic>要素ではない場合があります。
The <basic> element contains one of the following strings: "open" or "closed".
<basic>要素には、次の文字列のいずれかが含まれています：「開く」または「閉じ」。
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.
<tuple>がインスタントメッセージングアドレス用である場合、「開いている」および「閉じた」値は、インスタントメッセージを受信する可用性を示します。また、他の通信手段の一般的な可用性も示していますが、このメモはこれらを詳細に指定していません。
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.
オープン：インスタントメッセージのコンテキストでは、この値は、関連する<contact>要素がある場合、インスタントメッセージを受け入れる準備ができているインスタント受信トレイに対応することを意味します。
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.
閉じている：インスタントメッセージのコンテキストでは、この値は、関連する<contact>要素がある場合、インスタントメッセージを受け入れることができないインスタント受信トレイに対応することを意味します。
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.
<contact>要素には、連絡先アドレスの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.
<note>要素には文字列値が含まれています。これは通常、人間の読み取り可能なコメントに使用されます。<ノート>要素は、<pesconis>の子要素として、または<tuple>要素の子要素として表示される場合があります。前者の場合、コメントは現在のものに関するものであり、後者の場合、コメントは特定のタプルに関するものです。
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.
<note>要素には、[XML]のセクション2.12で定義されているように、この要素の内容で使用される言語を指定するための特別な属性「XML：LANG」が必要です。この属性の値は、[RFC3066]で定義されている言語識別子です。使用される言語が、XML：XML要素を囲む上のlang属性、または囲まれたmimeラッパーのコンテンツ言語ヘッダー[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.
<TimestAmp>要素には、このタプルのステータス変更の日付と時刻を示す文字列が含まれています。この要素の値は、IMPP DateTime形式[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には<satution>値を<basic>を超えて拡張する手段が必要です。これらの拡張機能は、<basic>がどのように理解されるかを変更したり、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に関連付けられた2つの異なるプレフィックスは、同じ名前空間を参照しています。
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参照を使用してはいけません。）
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は、[urn-ns-itf]で定義され、[xml-registry]によって拡張された名前空間識別子「ietf」を使用して、urn [urn]です。
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>
, 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>
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の場合には、名前空間を備えた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への拡張は、本質的に情報に基づいています - <basic>ステータスを超えて追加情報を提供します。ただし、複雑な拡張機能を理解するには、拡張要素内のネストされた要素に必須とマークする必要がある場合があります。そのような場合、要素名は必須の= 'true'または必須= '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.
注：a nustunderstand = 'true'またはnust understand = '1'属性は無視されている要素自体は無視されます。ネストされた必須の理解と理解の情報の筆者は、必要に応じて、囲まれた要素が必須= 'true'または必須= '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.
この仕様では、「urn：ietf：params：xml：ns：pidf」という名前の「urn：ietf：params：pidf」の要素を定義します。必須の属性を搭載していなくても、プロセッサは説明されているようにこれらを処理する必要があります。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.
エージェントが、必需品= 'true'（または '1'）属性を持つ認識されていない要素を含む<station>ブロックで存在情報を受信した場合、その要素全体とコンテンツ全体を認識されずに処理しようとしないように扱う必要があります。
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情報を正しく処理できるようにするために、必須の属性は、<station>要素にネストされたオプション要素内でのみ使用する必要があります。これにより、拡張機能の処理がその拡張機能に制限され、この仕様で定義されている基本的な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.
このメモは、「open」と「closing」の値を持つ<basic>ステータス値のみを定義します。その他のステータス値は、上記で定義された標準の名前空間ベースの拡張性ルールを使用して可能です。
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>
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.
一部の新しいステータス値は、<basic>要素の値を「拡張」します。たとえば、インスタントメッセージングで使用するために定義されるステータス値には、「アウェイ」、「ビジー」、「オフライン」などの値が含まれます。新しい拡張機能を認識しないユーザーエージェントである程度の相互運用性を維持するためには、<basic>ステータス値も含める必要があります。これは、拡張機能が、各値からのマッピングを開いて閉じるために定義する義務がないことを意味します。
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定義により、任意の要素が<status>要素に表示されることができますが、拡張ステータス要素とそのセマンティクス（特定のステータスの意味、解釈方法）を標準化することが望ましい場合があります。urn 'urn：ietf：params：xml：ns：pidf：status'は、<status> pidf要素への拡張を指定する傘の名前空間として指定されています（例：urn：ietf：xml：ns：ns：PIDF：ステータス：My-Extension）。この名前空間の下の新しい値は、標準トラック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スキーマは、「Home」、「Office」、または「Car」の値を持つことができる<location>存在情報の拡張機能を定義しています。<location>要素が標準化されている場合、このドキュメントは、拡張機能の使用に関する情報とともにRFCで利用可能になります。これらの拡張機能は、namespace 'urn：ietf：params：xml：ns：pidf：status'を使用し、拡張機能を定義する各RFCは、その名前空間内のianaとともに拡張名を登録する必要があります。
<?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">
<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:schema>
In addition to the XML Schema to validate the extension, registration of the extension name with IANA, RFCs defining extensions MUST discuss:
拡張機能を検証するためのXMLスキーマに加えて、拡張名のIANAとの登録は、拡張機能を定義する必要があります。
- 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クライアント、電話、ジオロケーターなどにとってのみ価値がありますか？どのような存在アプリケーションがこの拡張機能を使用し、どのような状況で使用しますか？
- 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...."
- <basic>に関連する拡張機能で定義されている存在状態、または以前にRFCで公開された関連する拡張機能にどのように存在状態。たとえば、「状態Zはオープンを意味するため、閉じた基本的な状態が表現されている場合は使用しないでください」、または「RFC QQQQの拡張機能ではなく、このドキュメントで拡張機能を使用する必要があります。...」
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用に開発される可能性のあるステータス拡張の例として、仮説的な「PIDF：IM 'XMLネームスペース」を使用しています。
<?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" 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" 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>
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.
このセクションでは、「アプリケーション/PIDF XML」形式のXMLスキーマ定義[XMLSCHEMA1]を示します。これは、「アプリケーション/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">
<!-- 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"/>
<xs:element name="presence" type="tns:presence"/>
<xs:complexType name="presence">
<xs:sequence>
<xs:element name="tuple" type="tns:tuple" minOccurs="0"
maxOccurs="unbounded"/>
<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: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 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 name="contact">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="priority" type="tns:qvalue"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="note">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</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>
<!-- 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>
This memo calls for IANA to:
このメモは、IANAに次のように求めています。
- register a new MIME content-type application/pidf+xml, per [MIME],
- 新しいMIMEコンテンツタイプアプリケーション/PIDF XML、[MIME]ごとに登録してください。
- register a new XML namespace URN per [XML-Registry].
- [XML-Registry]ごとに新しいXMLネームスペースurnを登録します。
- register a new XML namespace URN for status extensions per [XML-Registry].
- [XML-Registry]ごとにステータス拡張機能のために、新しい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
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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):
追加情報：マジック番号：ファイル拡張機能：Macintoshファイルタイプコード：
Person & email address to contact for further information: Hiroyasu Sugano EMail: sugano.h@jp.fujitsu.com
詳細については、人と電子メールアドレスをお問い合わせ：Hiroyasu Suganoメールメール：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>.
著者/変更コントローラー：この仕様は、IETF IMPPワーキンググループの作業項目であり、メーリングリストアドレス<impp@iastate.edu>があります。
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
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>
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
5.3. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:status'
URI
urn:ietf:params:xml:ns:pidf:status
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>
XML BEGIN <?xml version="1.0"?>
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>
<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
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ドキュメントで定義されているため、MIMEレベル（S/MIME [RFC3851]）でのPIDFのセキュリティのステージングが適切と思われます。したがって、PIDFは、CORE 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時間以上前のように見える場合、それは時代遅れと見なされる可能性があります（この存在のために生成された通知はウォッチャーに到達するのにそれほど長い時間はかかりません。最後の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].
この仕様に準拠したすべてのプロセッサは、UTF-8エンコーディングを生成および受け入れることができなければなりません。これは、XML適合プロセッサの必須文字エンコーディングの1つであり、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、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] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C。、およびE. Maler、「拡張可能なマークアップ言語（XML）1.0（第2版）」、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] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
ムーア、K。、「MIME（多目的インターネットメール拡張）パート3：ASSASCII以外のテキストのメッセージヘッダー拡張機能」、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.
Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、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.
Freed、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. Newman、「インターネット上の日時：タイムスタンプ」、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] Bray、T.、Hollander、D。、およびA. layman "xml in xmlの名前空間"、w3c推奨：xml-names、1999年1月14日、<http://www.w3.org/tr/rec-xml-names>
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[urn] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[URN-NS-IETF] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[urn-ns-itf] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[XML-Registry] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[XML-Registry] 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] Thompson、H.、Beech、D.、Maloney、M.、およびN. Mendelsohn、「XML Schema Part 1：Structures」、W3C Rec-Xmlschema-1、2001年5月、<http：//www.w33.org/tr/xmlschema-1/>。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[RFC2779] Day、M.、Aggarwal、S.、Mohr、G。、およびJ. Vincent、「インスタントメッセージング /存在プロトコル要件」、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] Dawson、F。and T. Howes、「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.、ed。、「Secure/Multipurpose Internet Mail Extensions（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月。
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">
<!ELEMENT presence ((tuple*),note?)>
<!ATTLIST presence
xmlns %URI; #REQUIRED
entity %URL; #REQUIRED
>
<!ELEMENT tuple (status,contact?,note?,timestamp?)>
<!ATTLIST tuple
id %TUPLEID; #REQUIRED
>
<!ELEMENT status (basic?)>
<!ELEMENT basic CDATA>
<!ELEMENT contact %URL;>
<!ATTLIST contact
priority %PRIORITY; #IMPLIED
>
<!ELEMENT note %NOTE;>
<!ELEMENT timestamp %DATETIME;>
Authors' Addresses
著者のアドレス
Hiroyasu Sugano Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan
Hiroyasu Sugano Fujitsu Laboratories Ltd. 64、Nishiwaki Ohkubo-Cho紅674-8555日本
EMail: sugano.h@jp.fujitsu.com
Shingo Fujimoto Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan
Shingo Fujimoto Fujitsu Laboratories Ltd. 64、Nishiwaki Ohkubo-Cho紅674-8555日本
EMail: shingo_fujimoto@jp.fujitsu.com
Graham Klyne Nine by Nine
Graham Klyne Nine by Nine
EMail: GK@ninebynine.org
Adrian Bateman VisionTech Limited Colton, Staffordshire, WS15 3LD United Kingdom
Adrian Bateman VisionTech Limited Colton、Staffordshire、WS15 3LD United Kingdom
EMail: bateman@acm.org
Wayne Carr Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 USA
ウェインカーインテルコーポレーション2111 NE 25th Avenue Hillsboro、または97124 USA
EMail: wayne.carr@intel.com
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。