RFC3863 日本語訳
3863 Presence Information Data Format (PIDF). H. Sugano, S. Fujimoto,G. Klyne, A. Bateman, W. Carr, J. Peterson. August 2004. (Format: TXT=56956 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループH.菅野の要求をネットワークでつないでください: 3863秒間藤本Category: 規格はA.Bateman VisionTech W.カーインテルJ.ピーターソンNeuStar2004年8月に富士通G.Klyne9時9分前を追跡します。
Presence Information Data Format (PIDF)
存在情報データの形式(PIDF)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This memo 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対応することのPresenceプロトコルのために一般的な存在データの形式としてPresence(CPP)存在情報Data Format(PIDF)にCommon Profileを指定して、また、PIDFのためにXML MIME実体を表すためにニューメディアタイプ「アプリケーション/pidf+xml」を定義します。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 用語とコンベンション。 . . . . . . . . . . . . . . 3 2. 決定. . . . . . . . . . . . . . . . . . . . . . . 3 2.1を設計してください。 最小量のモデル。 . . . . . . . . . . . . . . . . . . . . . 3 2.2. 特徴. . . . . . . . . . . . . . . . . . . . . 4 2.3を加えました。 決定をコード化するXML。 . . . . . . . . . . . . . . . . . 5 3. 存在情報データの形式. . . . . . . . . 5 3.1の概要。 'アプリケーション/pidf+xml'content type。 . . . . . . . . 5 3.2. 存在情報量。 . . . . . . . . . . . . . 5 4. XMLによってコード化された存在データの形式. . . . . . . . . . . . . . . 6 4.1。 XML形式定義. . . . . . . . . . . . . . . . . 6
Sugano, et al. Standards Track [Page 1] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[1ページ]。
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
4.1.1. <存在>要素。 . . . . . . . . . . . . . 6 4.1.2. <tuple>要素. . . . . . . . . . . . . . . 7 4.1.3。 <状態>要素。 . . . . . . . . . . . . . . 8 4.1.4. <の基本的な>要素. . . . . . . . . . . . . . . 8 4.1.5。 <連絡>要素. . . . . . . . . . . . . . 8 4.1.6。 <注意>要素。 . . . . . . . . . . . . . . . 9 4.1.7. <タイムスタンプ>要素. . . . . . . . . . . . . 9 4.2。 存在情報伸展性. . . . . . . . . . . 10 4.2.1。 XML名前空間バックグラウンド. . . . . . . . . . . . 10 4.2.2。 存在情報のXML名前空間。 . . . . . 11 4.2.3. 認識されていない要素名の取り扱い。 . . . . . 12 4.2.4. 状態値伸展性。 . . . . . . . . . . . 12 4.2.5. 状態拡大. . . . . . . . . 13 4.3を標準化します。 例. . . . . . . . . . . . . . . . . . . . . . . . 14 4.3の.1。 状態拡大を伴うデフォルト名前空間。 . . . . 14 4.3.2. 他のExtension Elementsがいる存在。 . . . . . 15 4.3.3. Elementsを理解するために義務的な例。 . . . . 16 4.4. XML図式定義. . . . . . . . . . . . . . . . . 16 5。 IANA問題。 . . . . . . . . . . . . . . . . . . . . . 18 5.1. 'アプリケーション/pidf+xml'. . 18 5.2のための文書内容登録。 'つぼ:ietf:params:xml:ナノ秒: pidf'のためのURNサブ名前空間登録。 . . . . . . . . . . . . . 19 5.3. 'つぼ:ietf:params:xml:ナノ秒:pidf:状態'. . . . . . . . . . 20 6のためのURNサブ名前空間登録。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 21 7. 国際化問題。 . . . . . . . . . . . . . 22 8. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1。 引用規格. . . . . . . . . . . . . . . . . . 22 8.2。 有益な参照. . . . . . . . . . . . . . . . . 23付録A.は型定義を記録します。 . . . . . . . . . . . . . . 25人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 26の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 28
1. Introduction
1. 序論
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].
Instant Messaging(CPIM)[CPIM]とPresence(CPP)[CPP]仕様のためのCommon Profilesは、RFC2779[RFC2779]に会う異なったInstant MessagingとPresenceプロトコルの間の相互運用性を達成するために1セットの操作とパラメタを定義します。
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対応することの存在プロトコルのための一般的な存在データの形式とPresence情報Data Format(PIDF)を定義します、存在情報がCPP対応することのプロトコル限界の向こう側に変更なしで移されるのを許容して、セキュリティのための付き添いの利益と性能で。
Sugano, et al. Standards Track [Page 2] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[2ページ]。
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.
このメモで指定された形式はRFC2779によって必要とされたベース存在書式と伸展性を定義します。 それはIMPP Modelドキュメント[RFC2778]によって定義された1人の極小集合の存在状態値を定義します。 しかしながら、存在アプリケーションは、このメモで提供された伸展性フレームワークを使用することでそれ自身の状態値を定義できます。 そのような拡張状態値を定義するのはこのメモの範囲を超えています。
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.
また、このメモが存在データペイロードとそれのための伸展性フレームワークのために書式だけを定義することに注意してください。 特定のプロトコルフレームの中にどう存在データを移すかは別々にプロトコル仕様に基づき定義されるでしょう。
1.1. Terminology and Conventions
1.1. 用語とコンベンション
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 Modelドキュメント[RFC2778]で定義されたボキャブラリーを利用します。 メモによるCLOSEDや、INSTANT MESSAGEや、オープンや、PRESENCE SERVICEや、PRESENTITYや、WATCHERや、WATCHER USER AGENTなどの用語はそこに定義されるのと同じ意味で使用されます。
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"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
2. Design Decisions
2. デザイン決定
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 ModelとRequirementsドキュメント[RFC2778、RFC2779]を採用しました。 2RFCsが存在情報に関する多くの声明を含んでいます。(情報を形式デザインのための基本的な規制と見なすことができます)。 また、私たちはそれらに基づくデザインに最小主義アプローチを取りました。 最小量のモデルから始めて、特定の問題を解決するのに必要な特徴だけが含まれています。
2.1. Minimal Model
2.1. 最小量のモデル
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 ModelとRequirementsドキュメントから抜粋された最小量のモデルに基づいています。 モデルは以下の項目から成ります。それぞれのそれらは根拠として対応するRFCsと彼らのセクション番号で伴われます、例えば、(RFC2778: Sec.2.4)はRFC2778のセクション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) PRESENCE INFORMATIONは1PRESENCE TUPLESから成ります。そこでは、PRESENCE TUPLEがSTATUS、任意のCOMMUNICATION ADDRESS、および任意のOTHER PRESENCE MARKUPから成ります。 COMMUNICATIONS ADDRESSのCONTACT ADDRESSがURI(RFC2778: Sec.3)だけについて言及するのが本書では理解されていることに注意してください。
Sugano, et al. Standards Track [Page 3] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[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) STATUSは少なくとも互いに唯一の値のオープンとCLOSEDを持っていて、他のCOMMUNICATION MEANSのための意味を持っているかもしれません。(CLOSEDはINSTANT MESSAGESの承認のための意味を持っています)。 INSTANT MESSAGE承認に関して何も含意しないSTATUSの他の値があるかもしれません。 STATUSのこれらの他の値がオープンとCLOSEDに結合されるかもしれませんか、または彼らはそれらの値(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) STATUSは単一であるか複数の値から成るかもしれません。(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) 一般的な形式で含まれていなかった追加情報を表す一般的な存在形式を広げる手段があるに違いありません。 存在情報図式のために拡大と登録メカニズムを定義しなければなりません、OTHER PRESENCE MARKUP(RFC2779: Sec.3.1.4-3.1.5)のための新しいSTATUS状態と新しいフォームを含んでいて。
(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) 一般的な存在形式は唯一、PRESENCE INFORMATIONが報告されるPRESENTITY(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) 一般的な存在形式で、PRESENTITYは、存在がWATCHERに送られた情報であると機密保護することができなければなりません。 形式が、保全、秘密性、および認証の特性が存在情報に適用されるのを許容しなければならない、(RFC2779: Sec5.2、.1 5.2 .4 5.3 .1 5.3 .3)。
2.2. Added Features
2.2. 付記された特徴
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) 連絡先の相対的なプライオリティは、PRESENCE INFORMATIONの情報筋が複数の接触にわたる好みが意味する受信機(WATCHER USER AGENTS)を言うのを許容するために明記できます。
(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
(b) 存在形式はPRESENCE INFORMATIONの作成に関するタイムスタンプを含むことができます。 それを含むメッセージが遅らせられても、存在ドキュメントのタイムスタンプはデータの作成の時間を受信機に知らせます。 また、基本的な署名メカニズムの如何にかかわらず反射攻撃を検出するのにそれを使用できます。 このメカニズムがウォッチャーとpresentitiesのどんなグローバルな時間同期化システムも仮定しないことに注意してください、(RFC2779のAppendix Aを見てください、8.1、.4A7)、むしろ、存在情報の前に経過するかもしれない最小の長さの時間が聞き古したである考えられると仮定します。
Sugano, et al. Standards Track [Page 4] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[4ページ]。
is long enough that minor variations among system clocks will
not lead to misjudgments of the freshness of presence
information.
存在情報の新しさの誤判定にはシステムクロックの中の小さい方の変化がそうしないほど長いリードがありますか?
2.3. XML Encoding Decision
2.3. 決定をコード化するXML
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].
Presence情報Data FormatはXML(eXtensible Markup Language[XML])の存在情報をコード化します。 それには階層構造があって、完全に広げることができるべきであるように上で議論したPRESENCE INFORMATIONの特徴を見なして、XMLはvCard[vCard]などの他の候補の上の最も望ましいフレームワークであるとみなされます。
3. Overview of Presence Information Data Format
3. 存在情報データの形式の概要
This section describes an overview of the presence data format defined in this memo.
このセクションはこのメモで定義された存在データの形式の概要について説明します。
3.1. The 'application/pidf+xml' Content Type
3.1. 'アプリケーション/pidf+xml'content type
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実体の新しいcontent type「アプリケーション/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'パラメタの使用はRECOMMENDEDです。 'charset'パラメタが指定されないなら、XMLプロセッサを従わせると、.3セクション4.3[XML]の要件は続かなければなりません。
3.2. Presence Information Contents
3.2. 存在情報量
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を指定する、PRESENCE TUPLESのo List--、識別子: 存在情報の中でこのtupleを特定するトークン。 - 状態: オープン/CLOSED、そして/または、拡大状態値。 - コミュニケーションアドレス: このtupleのCOMMUNICATION MEANSとCONTACT ADDRESS。 (任意)です。 - 相対的な優先権: このCOMMUNICATION ADDRESSの優先権を指定する数値。 (任意)です。 - タイムスタンプ: この変化に関するタイムスタンプ、tuple(任意の)--人間の読み込み可能なコメント: このtupleに関する無料のテキストメモ(任意)です。
Sugano, et al. Standards Track [Page 5] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[5ページ]。
o PRESENTITY human readable comment: free text memo about the
PRESENTITY (optional).
o PRESENTITYの人間の読み込み可能なコメント: PRESENTITY(任意の)に関するテキストメモを解放してください。
4. XML-encoded Presence Data Format
4. XMLによってコード化された存在データの形式
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(PRESENCE INFORMATIONの源)によって生産されて、存在サーバかゲートウェイによって少しも解釈や変更なしでWATCHERSに輸送されると予想されます。
4.1. XML Format Definitions
4.1. XML形式定義
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宣言とそれがなければなりません。SHOULDはXML宣言、例えば、「<--='UTF-8'をコード化するxmlバージョン='1.0'-->」にコード化宣言を含んでいます。 MIME content type宣言のcharsetパラメタが存在していて、それがコード化宣言と異なるなら、charsetパラメタは優先します。
Every application conformant to this specification MUST accept the UTF-8 character encoding to ensure the minimal interoperability.
この仕様へのあらゆるアプリケーションconformantは、最小量の相互運用性を確実にするためにUTF-8文字符号化を受け入れなければなりません。
4.1.1. The <presence> element
4.1.1. <存在>要素
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-NS]単位でxmlns属性を使用することで宣言されたXML名前空間名の'つぼ:ietf:params:xml:ナノ秒: 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」オブジェクトのルートは存在情報名前空間に関連している<存在>要素です。 これはいろいろなOPTIONAL拡大要素に従ってどんな数(0を含んでいる)の<注意>要素も支えた>要素が他の名前空間から続いた<tupleのどんな数(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:ナノ秒:pidfがなければなりません:、'
Sugano, et al. Standards Track [Page 6] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[6ページ]。
It MAY contain other namespace declarations for the extensions used in the presence XML document.
それは存在XMLドキュメントで使用される拡張子のための他の名前空間宣言を含むかもしれません。
4.1.2. The <tuple> element
4.1.2. <tuple>要素
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>要素はPRESENCE TUPLEを運びます、と義務的な<状態>要素のいろいろなOPTIONAL拡大要素(ことによると他の名前空間からの)が支えた成るのがOPTIONAL<タイムスタンプ>要素に従っていろいろなOPTIONAL<注意>要素が支えた>要素が続いたOPTIONAL<接触のそばで続きました。
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.
Tuplesは存在情報を区分する方法を提供します。 presentityに、完全な存在情報の成分が例えば同じデバイスで異なったデバイスか異なったアプリケーションから来たか、またはいろいろな時間に生成されたので、プロトコルかアプリケーションがいろいろな理由によるpresentityに関連している存在情報をセグメントに選ぶかもしれません。 Tuplesは複数の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>要素は同じPRESENTITYで他のtuplesとこのtupleを区別するのに使用される'イド'属性を含まなければなりません。 同じPRESENTITYに、'イド'属性の値は他のtuplesの'イド'属性値の中でユニークであるに違いありません。 'イド'値は同じPRESENTITYの以前後天的なPRESENCE INFORMATIONで対応するtupleを特定するために存在文書を処理するアプリケーションで使用されます。 'イド'属性の値は、任意のストリングであり、<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.
PRESENTITYが、COMMUNICATION ADDRESSを隠す必要があるかもしれないので、<連絡>要素はOPTIONALであるかどんなCOMMUNICATION MEANSにも関連しないtuplesがあるかもしれません。 <の基本的な>状態要素にSHOULDを含むTuplesが<連絡>アドレスを含んでいます。 Tuplesは闘争している存在状態を含むかもしれません--1<tuple>が<の基本的な><状態にオープンの>を供給して、同じPIDFのtuple>が含むことができた別の<に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
区分された存在情報がWATCHER USER AGENTに解釈される方法はWATCHER USER AGENTの能力と問題の存在アプリケーションに非常に依存しています。 tuplesの意味のどんなアプリケーション特有であるのやプロトコル限定された意味解釈がないとき、WATCHER USER AGENTS MAYは以下のガイドラインに従います。 WATCHER USER AGENTSは、最終以来PIDFのどのtuplesが彼らの状態を変えているかに注意するはずです。
Sugano, et al. Standards Track [Page 7] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[7ページ]。
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.
いずれかあるなら、ものが前の通知に受け取られて、tuplesで<状態>値と<タイムスタンプ>要素の両方を比較している現在のそれぞれの<tuple>の'イド'を関連させるのによる通知。
4.1.3. The <status> element
4.1.3. <状態>要素
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つの子供要素が<状態>要素に現れるという制限で1つのOPTIONALの<の基本的な>要素を含んでいます、続いて、いろいろなOPTIONAL拡大要素(ことによると他の名前空間からの)を含みます。 <状態>のこれらの子供要素はこのtupleの状態値を含んでいます。 ただ一つの<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).
このメモは<の基本的な>状態値要素を定義するだけです。 他の状態値は、標準の伸展性フレームワークを使用することで含まれるかもしれません(セクション4.2.4を見てください)。 「本当に= 」mustUnderstandを運ばないなら、<状態>の中で認識されていない要素に遭遇するアプリケーションがそれらを無視するかもしれませんか、または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.
<状態>要素には少なくとも1つの状態値要素がなければならない間この状態値が<の基本的な>要素でないかもしれないことに注意してください。
4.1.4. The <basic> element
4.1.4. <の基本的な>要素
The <basic> element contains one of the following strings: "open" or "closed".
<の基本的な>要素は以下のストリングの1つを含んでいます: 「開く」か「閉じられます」。
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>が瞬間にアドレスを通信させるなら、値「戸外」と「閉鎖」は、INSTANT MESSAGESを受け取るために有用性を示します。 また、彼らは他のコミュニケーション手段のための一般的な入手可能性を示しますが、このメモは詳細にこれらを指定しません。
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 MESSAGESの文脈では、この値は、もしあれば関連<連絡>要素が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 MESSAGESの文脈では、この値は、もしあれば関連<連絡>要素がINSTANT MESSAGEを受け入れることができないINSTANT INBOXに対応することを意味します。
4.1.5. The <contact> element
4.1.5. <連絡>要素
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
<連絡>要素は連絡先の1つのURLを含んでいます。 それには、値が他のものの上でこの連絡先の相対的な優先を意味する'優先権'属性が任意にあります。 価値
Sugano, et al. Standards Track [Page 8] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[8ページ]。
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.
属性は小数点以下高々3ケタについて包括的な0〜1の10進数であるに違いありません。 より高い値は、より高い優先度を示します。 優先順位の値に関する例は0、0.021、0.5、1.00です。 '優先権'属性が省略されるなら、アプリケーションは最も低い優先度を連絡先に割り当てなければなりません。 '優先権'値が範囲から脱しているなら、まるで属性が存在していないかのように、まさしくアプリケーションSHOULDは値を無視して、それを処理します。
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.
それらにそれらの上の先行が下側のプライオリティと共にあるとき、アプリケーションSHOULDは、より高い優先度との接触を扱います。 それらが実際にどう扱われるかはこの仕様を超えています。 また、どう同じ優先権との接触を扱うかは実装まで達しています。
4.1.6. The <note> element
4.1.6. <注意>要素
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.
<注意>要素はストリング値を含んでいます。(通常、それは、人間の読み込み可能なコメントに使用されます)。 <注意>要素は<存在>の子供要素や<tuple>要素の子供要素のように見えるかもしれません。 前の場合では、コメントはPRESENTITYに関するものです、そして、後者の場合には、特定の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.
<が、どこに見えても>要素SHOULD NOTが親元素の状態の非共同利用できる代用品として使用されて、解釈されることに注意することに注意してください。
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.
<注意>要素SHOULDには、[XML]のセクション2.12で定義されるようにこの要素のコンテンツに使用される言語を指定する特別な属性'xml: lang'があります。 [RFC3066]によって定義されるようにこの属性の値は言語識別子です。 使用される言語がコンテンツの符号化情報などの、より大きい文脈によって含意されるとき、それは省略されるかもしれません、xmlのように: 同封のXML要素のlang属性、または同封のMIMEラッパーのContent-言語ヘッダー[RFC3282]。
4.1.7. The <timestamp> element
4.1.7. <タイムスタンプ>要素
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.
<タイムスタンプ>要素はこのtupleの状態変化の日時を示すストリングを含んでいます。 この要素の価値は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として、セキュリティは測定します、<タイムスタンプ>要素SHOULD。状態変化の正確な時間が決定している場合があるなら、すべてのtuplesで含められてください。 タイムスタンプで存在情報を受け取るウォッチャーのための安全ガイドラインに関しては、Security Considerationsを見てください。
A PRESENTITY MUST NOT generate successive <presence> elements containing the same timestamp.
PRESENTITY MUST NOTは、連続した<存在が同じタイムスタンプを含む>要素であると生成します。
Sugano, et al. Standards Track [Page 9] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[9ページ]。
4.2. Presence Information Extensibility
4.2. 存在情報伸展性
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.
RFC2779は、PIDFには<の基本的な>を超えて<状態>値を広げる手段があるのを必要とします。 これらの拡大は、<の基本的な>がどう理解されることになっているかを変更して、PIDFボディー自体の構造か意味論を変えてはいけません。 これらの拡大で、プロトコルとアプリケーションは単により豊かな存在データを定義できます。
4.2.1. XML Namespaces Background
4.2.1. XML名前空間バックグラウンド
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.
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.
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.
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.
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.)
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.)
For further details, see the XML namespace specification [XML-NS].
For further details, see the XML namespace specification [XML-NS].
Sugano, et al. Standards Track [Page 10] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 10] RFC 3863 Presence Information Data Format August 2004
4.2.2. XML Namespaces In Presence Information
4.2.2. XML Namespaces In Presence Information
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.)
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.)
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]:
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]:
urn:ietf:params:xml:ns:pidf
urn:ietf:params:xml:ns:pidf
Thus, simple presence data might be thus:
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" 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:
, using a default XML namespace:
<?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" 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.
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.
Sugano, et al. Standards Track [Page 11] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 11] RFC 3863 Presence Information Data Format August 2004
4.2.3. Handling Of Unrecognized Element Names
4.2.3. Handling Of Unrecognized Element Names
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
4.2.4. Status Value Extensibility
4.2.4. Status Value Extensibility
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.
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.
Sugano, et al. Standards Track [Page 12] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 12] RFC 3863 Presence Information Data Format August 2004
For example, a location status value might be included thus:
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" 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.
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.
4.2.5. Standardizing Status Extensions
4.2.5. Standardizing Status Extensions
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.
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.
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.
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 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"
<?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"
Sugano, et al. Standards Track [Page 13] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 13] RFC 3863 Presence Information Data Format August 2004
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
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: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>
</xs:schema>
In addition to the XML Schema to validate the extension, registration of the extension name with IANA, RFCs defining extensions MUST discuss:
In addition to the XML Schema to validate the extension, registration of the extension name with IANA, RFCs defining extensions MUST discuss:
- 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?
- 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?
- 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).
- 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).
Extensions SHOULD also discuss:
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...."
- 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...."
4.3. Examples
4.3. Examples
4.3.1. Default Namespace with Status Extensions
4.3.1. Default Namespace with Status Extensions
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.
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.
Sugano, et al. Standards Track [Page 14] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 14] RFC 3863 Presence Information Data Format August 2004
<?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"?> <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>
4.3.2. Presence with Other Extension Elements
4.3.2. Presence with Other Extension Elements
<?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.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>
Sugano, et al. Standards Track [Page 15] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 15] RFC 3863 Presence Information Data Format August 2004
4.3.3. Example Mandatory To Understand Elements
4.3.3. Example Mandatory To Understand Elements
<?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" 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.
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.
4.4. XML Schema Definitions
4.4. XML Schema Definitions
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.
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.
<?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">
<?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"/>
<!-- 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:element name="presence" type="tns:presence"/>
<xs:complexType name="presence">
<xs:sequence>
<xs:element name="tuple" type="tns:tuple" minOccurs="0"
maxOccurs="unbounded"/>
<xs:complexType name="presence"> <xs:sequence> <xs:element name="tuple" type="tns:tuple" minOccurs="0" maxOccurs="unbounded"/>
Sugano, et al. Standards Track [Page 16] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 16] RFC 3863 Presence Information Data Format August 2004
<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: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="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="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="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:complexType name="note"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute ref="xml:lang"/> </xs:extension>
Sugano, et al. Standards Track [Page 17] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 17] RFC 3863 Presence Information Data Format August 2004
</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: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>
<!-- 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>
5. IANA Considerations
5. IANA Considerations
This memo calls for IANA to:
This memo calls for IANA to:
- register a new MIME content-type application/pidf+xml, per [MIME],
- register a new MIME content-type application/pidf+xml, per [MIME],
- register a new XML namespace URN per [XML-Registry].
- register a new XML namespace URN per [XML-Registry].
- register a new XML namespace URN for status extensions per [XML-
Registry].
- register a new XML namespace URN for status extensions per [XML- Registry].
The registration templates for these are below. For more information on status extensions, see section 4.2.5.
The registration templates for these are below. For more information on status extensions, see section 4.2.5.
5.1. Content-type registration for 'application/pidf+xml'
5.1. Content-type registration for 'application/pidf+xml'
To: ietf-types@iana.org Subject: Registration of MIME media type application/pidf+xml
To: ietf-types@iana.org Subject: Registration of MIME media type application/pidf+xml
MIME media type name: application
MIME media type name: application
MIME subtype name: pidf+xml
MIME subtype name: pidf+xml
Required parameters: (none)
Required parameters: (none)
Sugano, et al. Standards Track [Page 18] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 18] RFC 3863 Presence Information Data Format August 2004
Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is
UTF-8.
Optional parameters: charset Indicates the character encoding of enclosed XML. Default is 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.
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC 3023], section 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.
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.
Interoperability considerations: This content type provides a common format for exchange of presence information across different CPP compliant protocols.
Published specification:
RFC 3863
Published specification: RFC 3863
Applications which use this media type:
Presence and instant messaging systems.
Applications which use this media type: Presence and instant messaging systems.
Additional information:
Magic number(s): File extension(s): Macintosh File Type Code(s):
Additional information: Magic number(s): File extension(s): Macintosh File Type Code(s):
Person & email address to contact for further information:
Hiroyasu Sugano EMail: sugano.h@jp.fujitsu.com
Person & email address to contact for further information: Hiroyasu Sugano EMail: sugano.h@jp.fujitsu.com
Intended usage:
LIMITED USE
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>.
Author/Change controller: This specification is a work item of the IETF IMPP working group, with mailing list address <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.
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.
5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf'
5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf'
URI
urn:ietf:params:xml:ns:pidf
URI urn:ietf:params:xml:ns:pidf
Sugano, et al. Standards Track [Page 19] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 19] RFC 3863 Presence Information Data Format August 2004
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.
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.
Registrant Contact
IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
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
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'
5.3. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:status'
URI
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.
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.
Registrant Contact
IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
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 version="1.0"?>
Sugano, et al. Standards Track [Page 20] RFC 3863 Presence Information Data Format August 2004
Sugano, et al. Standards Track [Page 20] RFC 3863 Presence Information Data Format August 2004
<!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-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
6. Security Considerations
6. Security Considerations
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を保護する能力がなければなりません、雨垂れや、不正や、タンパーや反射攻撃などのように。 これらのセキュリティー対策は中古のpresentitiesとウォッチャーの間の終わりから終わりであることをできるに違いありません、ウォッチャーとpresentityが異なった存在プロトコルを使い、CPPゲートウェイを通って交信しても。 'アプリケーション/pidf+xml'MIMEの種類がこのPIDFドキュメントのために定義されるので、PIDFのためにMIMEレベル(S/MIME[RFC3851]がある)でセキュリティを上演するのは適切に見えます。 したがって、PIDFはコアCPP仕様で与えられたS/MIME(最小のciphersuitesを含んでいる)の使用のための標準の推薦に続くはずです。
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を見る)におけるタイムスタンプの使用が反射攻撃に対する何らかの初歩的な保護を提供できることに注意してください。 ウォッチャーが存在情報を受け取るなら、それは時代遅れであり、それはSHOULDです。無視されます。 ウォッチャーは、存在情報が多くのファッションで時代遅れであると決心できます。 存在情報で最も新しいタイムスタンプが最終で最も新しいタイムスタンプが存在情報を受け取ったより古いなら、最もかなり、それは時代遅れであると考えられるべきです。 アプリケーションとプロトコルも存在情報がどれくらい頻繁にリフレッシュされるべきであるかを決定するためのそれら自身の規則を採用するように教えられます。 例えば、存在情報が1時間以上目であるように見えるなら、それは時代遅れであると考えられるかもしれません(この存在情報のために発生する通知はウォッチャーに届くにはそのような長い時かからないでしょう、そして、presentityが最後の時間に存在状態をリフレッシュしていないなら、たぶんオフラインです)。
Sugano, et al. Standards Track [Page 21] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[21ページ]。
7. Internationalization Considerations
7. 国際化問題
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].
この仕様へのすべてのプロセッサconformantが、UTF-8がコード化していると発生して、受け入れることができなければならなくて、XMLのための義務的なキャラクタencodingsのこの存在1も、プロセッサを従わせて、また、RFC2277[RFC2277]を始められた方針が必要です。
Other character encodings MAY be accepted (but CPP compliant processors are strongly discouraged from emitting anything other than UTF-8).
他のキャラクタencodingsを受け入れるかもしれません(CPP対応することのプロセッサはUTF-8以外の何でも放って、強くがっかりしています)。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3023] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、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>
T.、パオリ、J.、Sperberg-マックィーン、C.、およびE.Maler、「拡張マークアップ言語(XML)1.0(第2版)」を[XML]は、いななかせます、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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996.
N.とN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、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)は4を分けます」。 「登録手順」、BCP13、RFC2048、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を分けます」。 「順応評価基準と例」、RFC2049、11月1996日
Sugano, et al. Standards Track [Page 22] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[22ページ]。
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, March 1995.
[RFC3066]Alvestrand、H.、「言語の識別のためのタグ」、BCP47、RFC3066、1995年3月。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]Klyne(G.とC.ニューマン)は「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、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.Layman、「XMLの名前空間」、W3C推薦: xml-名前、<が>とhttp://www.w3.org/TR/REC-xml命名する1999年1月14日
[URI] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[URI]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[つぼ]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[URN-NS-IETF] Moats, R., "A URN Namespace for IETF Documents", RFC
2648, August 1999.
[つぼのナノ秒IETF、]、モウツ、R.、「IETFドキュメントのためのつぼの名前空間」、RFC2648、8月1999日
[XML-Registry] Mealling, M., "The IETF XML Registry", RFC 3688,
January 2004.
[XML-登録] 食事、M.、「IETF XML登録」、RFC3688、2004年1月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、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/>。
8.2. Informative References
8.2. 有益な参照
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February
2000.
2000年2月の[RFC2778]日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent,
"Instant Messaging / Presence Protocol Requirements",
RFC 2779, February 2000.
[RFC2779] 日、M.とAggarwalとS.とモーア、G.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、2000年2月。
[CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[CPIM] ピーターソン、J.、「インスタントメッセージング(CPIM)のための一般的なプロフィール」、RFC3860、2004年8月。
[CPP] Peterson, J., "Common Presence for Presence (CPP)",
RFC 3859, August 2004.
[CPP] ピーターソン、J.、「存在(CPP)のための一般的な存在」、RFC3859、2004年8月。
[vCard] Dawson, F. and T. Howes, "vCard MIME Directory
Profile", RFC 2426, September 1998.
[vCard] ドーソンとF.とT.ハウズ、「vCard MIMEディレクトリプロフィール」、RFC2426、1998年9月。
Sugano, et al. Standards Track [Page 23] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[23ページ]。
[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は仕様を通信する」RFC3851、7月2004日
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002.
[RFC3282]Alvestrand(H.、「満足している言語ヘッダー」、RFC3282)は2002がそうするかもしれません。
Sugano, et al. Standards Track [Page 24] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[24ページ]。
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」形式のためのDocument Type Definitionは説明されます。 ここのDTDが提示される、唯一、そうするかもしれないそれらにおける情報、XML Schema定義には、なじみ深くはありません。
Note: the DTD does not show where extension elements can be added. See the XML Schema for that information.
以下に注意してください。 DTDは、どこで拡大要素を加えることができるかを示しません。 その情報に関してXML Schemaを見てください。
<!ENTITY % URL "CDATA"> <!ENTITY % URI "CDATA"> <!ENTITY % TUPLEID "CDATA"> <!ENTITY % DATETIME "CDATA"> <!ENTITY % VALUETYPE "CDATA"> <!ENTITY % PRIORITY "CDATA"> <!ENTITY % NOTE "CDATA">
<!実体%URL、「CDATA、「><!実体%ユリ、「CDATA「><!実体%TUPLEID」CDATA「><!実体%DATETIME」CDATA「><!実体%VALUETYPE」CDATA、「><!実体%優先権、「CDATA、「><!実体%が注意する、「CDATA">"
<!ELEMENT presence ((tuple*),note?)>
<!ATTLIST presence
xmlns %URI; #REQUIRED
entity %URL; #REQUIRED
>
<!ELEMENT存在((tuple*)、注意?)><!ATTLIST存在xmlns%URI。 #REQUIRED実体%URL。 #必要な>。
<!ELEMENT tuple (status,contact?,note?,timestamp?)>
<!ATTLIST tuple
id %TUPLEID; #REQUIRED
>
<!ELEMENT tuple、(状態、接触?、注意?、タイムスタンプ)?><!ATTLIST tupleイド%TUPLEID。 #必要な>。
<!ELEMENT status (basic?)> <!ELEMENT basic CDATA>
<!ELEMENT状態(基本的な?)><!ELEMENTの基本的なCDATA>。
<!ELEMENT contact %URL;>
<!ATTLIST contact
priority %PRIORITY; #IMPLIED
>
<!ELEMENTは%URLに連絡します。><!ATTLISTは優先権%PRIORITYに連絡します。 #暗示している>。
<!ELEMENT note %NOTE;>
<!ELEMENTは%注意に注意します。>。
<!ELEMENT timestamp %DATETIME;>
<!ELEMENTタイムスタンプ%DATETIME。>。
Sugano, et al. Standards Track [Page 25] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[25ページ]。
Authors' Addresses
作者のアドレス
Hiroyasu Sugano Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan
寛裕菅野株式会社富士通研究所64、大久保町明石日本西脇674-8555
EMail: sugano.h@jp.fujitsu.com
メール: sugano.h@jp.fujitsu.com
Shingo Fujimoto Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan
Shingo藤本株式会社富士通研究所64、大久保町明石日本西脇674-8555
EMail: shingo_fujimoto@jp.fujitsu.com
メール: shingo_fujimoto@jp.fujitsu.com
Graham Klyne Nine by Nine
グラハムKlyne9時9分前
EMail: GK@ninebynine.org
メール: GK@ninebynine.org
Adrian Bateman VisionTech Limited Colton, Staffordshire, WS15 3LD United Kingdom
エードリアンBateman VisionTechはColton、スタッフォードシャー、WS15 3LDイギリスを制限しました。
EMail: bateman@acm.org
メール: bateman@acm.org
Wayne Carr Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 USA
ウェインカーインテル社2111NE第25Avenueヒースボロー、または97124米国
EMail: wayne.carr@intel.com
メール: wayne.carr@intel.com
Sugano, et al. Standards Track [Page 26] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[26ページ]。
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar Inc.1800サター通りスイート570一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz
Sugano, et al. Standards Track [Page 27] RFC 3863 Presence Information Data Format August 2004
菅野、他 規格は存在インフォメーション・データ形式2004年8月にRFC3863を追跡します[27ページ]。
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Sugano, et al. Standards Track [Page 28]
菅野、他 標準化過程[28ページ]
一覧
スポンサーリンク
