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 プレゼンス情報データ書式(PIDF) Presence Information Data Format (PIDF) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書は、プレゼンスのための共通プロファイル(Common Profile for Presence / CPP)のプレゼンス情報データ書式(Presence Information Data Format / PIDF)を規定する。これは、CPP準拠のプレゼンスプロトコルのため の共通プレゼンスデータ書式として規定されるものであり、また、新規メディ アタイプ「application/pidf+xml」を定義してPIDF用のXML MIMEエンティティ を表す。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 用語と条約 . . . . . . . . . . . . . . . . . . . . . . . 3 2. 設計上の判断 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. 最小モデル . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. 付加機能 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. XMLエンコーディング上の判断 . . . . . . . . . . . . . . 5 3. プレゼンス情報データ書式の概要 . . . . . . . . . . . . . . . . 5 3.1. 「application/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 4.1.1. 要素 . . . . . . . . . . . . . . . . . 6 4.1.2. 要素 . . . . . . . . . . . . . . . . . . . 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. 他の拡張要素を使用するプレゼンス . . . . . . . . 15 4.3.3. 理解する必要のある要素例 . . . . . . . . . . . . 16 4.4. XMLスキーマ定義 . . . . . . . . . . . . . . . . . . . . 16 5. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. 「application/pidf+xml」のcontent-type登録 . . . . . . . 18 5.2. 「urn:ietf:params:xml:ns:pidf」の URN下位名前空間登録 . . . . . . . . . . . . . . . . . . . . 19 5.3. 「urn:ietf:params:xml:ns:pidf:status」の URN下位名前空間登録 . . . . . . . . . . . . . . . . . . . . 20 6. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 21 7. 国際化の考慮事項 . . . . . . . . . . . . . . . . . . . . . . . 22 8. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 22 8.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 23 付録 A. ドキュメントタイプ定義 . . . . . . . . . . . . . . . . . . 25 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . . 28 1. はじめに インスタントメッセージングのための共通プロファイル(Common Profiles for Instant Messaging / CPIM)[CPIM]、プレゼンスのための共通プロファイル (Common Profiles for Presence/CPP)[CPP]の仕様では、RFC 2779[RFC2779]に 適合する異なるインスタントメッセージングおよびプレゼンスプロトコル間 で、相互運用性を実現するための操作とパラメータの一式が定義されている。 本文書では、さらにCPP準拠のプレゼンスプロトコルに共通するプレゼンス データ書式として、プレゼンス情報データ書式(Presence Information Data Format/PIDF)を定義する。これによって、修正を加えずに、CPP準拠プロトコ ルの範囲を越えてプレゼンス情報を転送できるようになる。また、セキュリ ティとパフォーマンスの利点もある。 Sugano, et al. Standards Track [Page 2] RFC 3863 Presence Information Data Format August 2004 本文書で規定される書式では、RFC 2779で必須とされている基本のプレゼンス 書式と拡張性を定義する。本文書は、IMPPモデル文書[RFC2778]で定義され る、プレゼンスステータス値の最小セットを定義する。一方で、プレゼンスア プリケーションは、本文書で提供される拡張性フレームワークを使用して、独 自のステータス値を定義することができる。こうした拡張ステータス値を定義 する方法は、本文書の範囲外である。 また、本文書はプレゼンスデータペイロードの書式と、その書式の拡張性フ レームワークのみを定義するものである、ということに注意。プレゼンスデー タを特定のプロトコルのフレームワーク内で転送する方法は、プロトコルの仕 様で別に定義される。 1.1. 用語と規約 本文書は、IMPPモデル文書[RFC2778]で定義されている語彙を利用している。 本文書にある<クローズド>(CLOSED)、<インスタントメッセージ>(INSTANT MESSAGE)、<オープン>(OPEN)、<プレゼンスサービス>(PRESENCE SERVICE)、 <プレゼンティティ>(PRESENTITY)、<ウォッチャー>(WATCHER、および<ウォッ チャーユーザーエージェント>(WATCHER USER AGENT)などの語の用法は、RFC 2778で定義されているものと同じである。 [訳注: 訳文では、RFC 2778の用語(すべて大文字で書かれている用語)を < > で囲みます。初出時は「<日本語訳>(原文)」と記載し、2回 目以降は「<日本語訳>」で統一します。 例: 初出 <プレゼンスサービス>(PRESENCE SERVICE) 2回目以降 <プレゼンスサービス>] 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、 RFC 2119[RFC2119]のBCP 14に記載されるとおりに解釈されるべきである。 2. 設計上の判断 ここでは、IMPPのモデルと要件の文書[RFC2779、RFC2778]を、議論の起点とし て採用した。この2つのRFCには、プレゼンス情報に関する多くの事項が記述さ れている。これは、書式設定に関する制約の基本セットとしてみなすことがで きる。また、これに基づいた設計に対して最小の対処方法を採用した。最小モ デルから始めるため、具体的な問題を解決するときに必要な機能のみを含め た。 2.1. 最小モデル 本仕様は、IMPPモデルと要件の文書から抜粋した最小モデルに基づく。このモ デルは以下の項目から構成される。各項目には、典拠として、対応するRFCと セクション番号が併記されている。たとえば、(RFC2778:Sec.2.4)は、RFC 2778のセクション2.4を指す。 (a) <プレゼンス情報>(PRESENCE INFORMATION)は、1つまたは複数の<プレゼン スタプル>(PRESENCE TUPLES)から構成される。<プレゼンスタプル>は、 <ステータス>(STATUS)、オプションの<通信アドレス>(COMMUNICATION ADDRESS)、およびオプションの<その他プレゼンスマークアップ>(OTHER PRESENCE MARKUP)から構成される。<通信アドレス>にある<コンタクトア ドレス>(CONTACT ADDRESS)は、本文書では、URIのみを指すものとする (RFC2778:Sec.3)。 Sugano, et al. Standards Track [Page 3] RFC 3863 Presence Information Data Format August 2004 (b) <ステータス>(STATUS)には、最低でも排他的な値の<オープン>(OPEN)およ び<クローズド>(CLOSED)がある。これは、<インスタントメッセージ> (INSTANT MESSAGES)の受け入れに関する意味がある。また、他の<通信手 段>(COMMUNICATION MEANS)に関する意味を持つ場合もある。他に、<イン スタントメッセージ>の受け入れに関する意味を何も持たない<ステータ ス>値も存在する可能性がある。こうした他の<ステータス>値は、<オープ ン>と<クローズド>と組み合わせることができたり、あるいは、これらの 値とは排他的である可能性がある(RFC2778:Sec.3、RFC2779:Sec.4.4.1- 4.4.3)。 (c) <ステータス>は、単一または複数の値から構成される(RFC2778: Sec.2.4)。 (d) 共通書式に含まれない付加情報を表すために、共通プレゼンス書式を拡張 する手段が必要である。プレゼンス情報スキーマのために、拡張と登録の 仕組みを定義しなければならない。これには、<その他プレゼンスマーク アップ>用の新規<ステータス>条件や新規書式も含まれる(RFC2779: Sec.3.1.4-3.1.5)。 (e) 共通プレゼンス書式には、報告される<プレゼンス情報>の所有者である <プレゼンティティ>を、一意に特定する手段を含める必要がある (RFC2779:Sec.3.1.2)。 (f) 共通プレゼンス書式によって、<プレゼンティティ>は<ウォッチャー>に送 信されるプレゼンス情報をセキュリティ保護できる必要がある。この書式 は、整合性、機密性、認証という特性をプレゼンス情報に適用できるよう にする必要がある(RFC2779:Sec5.2.1、5.2.4、5.3.1、5.3.3)。 2.2. 付加機能 上記の最小モデルに加え、本仕様で規定される書式には以下の機能がある。 (a) コンタクトアドレスの相対的優先度(relative priorities)を指定可能。 これは、<プレゼンス情報>の送信元が、受信側である<ウォッチャーユー ザーエージェント>に対して、複数の接続手段を使って優先度を送信でき るようにするためである。 (b) プレゼンス書式には、<プレゼンス情報>作成のタイムスタンプを含める ことができる。プレゼンス文書のタイムスタンプによって、受信側は、そ のデータを含むメッセージ送信が遅延しても、データの作成時刻を知るこ とができる。また、基礎となる署名メカニズムに依存せずに、リプレイ攻 撃の検出に使用することもできる。注意が必要なのは、このメカニズム は、ウォッチャーとプレゼンティティ用の地球時間の同期(global time synchronization)システムを想定するものではないということである (RFC2779の付録A、8.1.4 A7を参照)。そうではなく、プレゼンス情報が古 くなったとみなされるまでの最小時間長が十分長いので、システムクロッ Sugano, et al. Standards Track [Page 4] RFC 3863 Presence Information Data Format August 2004 ク間の軽微なばらつきによって、プレゼンス情報の新しさが誤判断される ことはない、と想定している。 2.3. XMLエンコーディング上の判断 プレゼンス情報データ書式は、XML(eXtensible Markup Language [XML])で プレゼンス情報をエンコードする。上述の<プレゼンス情報>の機能に関して は、階層構造を持ち、さらに全体的に拡張可能であるため、XMLはvCard [vCard]などの候補の中で、最も望ましいフレームワークであるとみなされて いる。 3. プレゼンス情報データ書式の概要 このセクションでは、本文書で定義されるプレゼンスデータ書式の概要を説明 する。 3.1. 「application/pidf+xml」のContent-Type 本文書は、XML MIMEエンティティ用に、新規のコンテンツタイプ 「application/pidf+xml」を定義する。これにはプレゼンス情報が含まれる。 本仕様は、[RFC3023]に記載されている推奨と条項に従い、タイプ(「+xml」接 尾辞)の命名規則と「charset」パラメータの用法を含む。 オプションとして定義されているが、「charset」パラメータの使用が推奨さ れる[RECOMMENDED]。「charset」パラメータが指定されていない場合、XMLプ ロセッサへの適合は、[XML]のセクション4.3.3に記載される要件に従わなけれ ばならない[MUST]。 3.2. プレゼンス情報のコンテンツ このサブセクションでは、「application/pidf+xml」文書内の情報について概 要を説明する。PIDFコンテンツの完全な定義は、セクション4に記載されてい る。 o <プレゼンティティ>URL: <プレゼンティティ>の「pres」URLを指定。 o <プレゼンスタプル>一覧 - 識別子: プレゼンス情報内のこのタプルを特定するトークン。 - <ステータス>: <オープン>/<クローズド>または拡張ステータス値。 - <通信アドレス>: このタプルの<通信手段>と<コンタクトアドレス>。 (オプション) - 相対優先度: この<通信アドレス>の優先度を示す数値。(オプション) - タイムスタンプ: このタプルが変更されたときのタイムスタンプ。(オプ ション) - 可読コメント(Human readable comment): このタプルに関する任意のテキ ストメモ。(オプション) Sugano, et al. Standards Track [Page 5] RFC 3863 Presence Information Data Format August 2004 o <プレゼンティティ>可読コメント(PRESENTITY human readable comment): プレゼンティティに関する任意のテキストメモ。(オプション) 4. XMLエンコードされたプレゼンスデータ書式 このセクションでは、CPP準拠システムで使用するための、XMLエンコードされ たプレゼンス情報データ書式(PIDF)を定義する。この書式のプレゼンスペイ ロードは、プレゼンティティ(プレゼンス情報の送信元)が生成することが期待 されている。 4.1. XML書式の定義 PIDFオブジェクトは、整形済みのXML文書である。 XML宣言が存在しなければならない[MUST]。また、XML宣言にエンコーディング の宣言(例 「」)を含めるべきであ る[SHOULD]。MIMEのcontent-type定義にcharsetパラメータが存在し、また、 エンコーディングの宣言と異なる場合、charsetパラメータが優先される。 本仕様に適合するすべてのアプリケーションは、UTF-8文字エンコーディング を受け入れて、最小限の相互運用性を確保しなければならない[MUST]。 4.1.1. 要素 PIDF要素は、XML名前空間名「urn:ietf:params:xml:ns:pidf」に関連付けら れ、[XML-NS]によって、xmlns属性を使用して宣言される。この名前空間は、 デフォルトの名前空間であるか、あるいは、特定の名前空間接頭辞(セクショ ン4.2.2の例を参照)と関連付けられる可能性がある。 「application/pidf+xml」オブジェクトのルートは、プレゼンス情報名前空間 に関連付けられる要素である。これには、0を含む任意数の 要素が含まれ、0を含む任意数の要素が続き、その他の名前空間から任 意数のオプションの[OPTIONAL]拡張要素が続く。 要素には「entity」属性が存在しなければならない[MUST]。 「entity」属性の値は、このプレゼンス文書を発行する<プレゼンティティ>の 「pres」URLである。要素には、名前空間の宣言(「xmlns」)を含め て、プレゼンス文書の基礎となる名前空間を示さなければならない[MUST]。 本仕様に準拠するプレゼンス文書には、名前空間「urn:ietf:params:xml:ns: pidf:」が存在しなければならない[MUST]。 Sugano, et al. Standards Track [Page 6] RFC 3863 Presence Information Data Format August 2004 その他の名前空間の宣言は、プレゼンスのXML文書で使用される拡張用に含め てもよい[MAY]。 4.1.2. 要素 要素は<プレゼンスタプル>を伝達する。その構成は、必須の 要素、次にオプション[OPTIONAL]で任意数の拡張要素が続き(他の名前空間か らである可能性あり)、次にオプション[OPTIONAL]で要素が続き、次 にオプション[OPTIONAL]で任意数の要素が続き、次にオプション [OPTIONAL]で要素が続く。 タプルはプレゼンス情報をセグメント化する方法を提供する。プロトコルまた はアプリケーションは、プレゼンティティに関連付けられるプレゼンス情報を セグメント化することを、さまざまな理由から、選択してもよい。たとえば、 あるプレゼンティティの完全なプレゼンス情報の構成要素が、別個のデバイ ス、あるいは同じデバイス上の異なるアプリケーションから来た場合、あるい は、異なる時間に生成された場合など。複数のPIDFインスタンスを作成するな ど、プレゼンス情報をセグメント化するその他の方法よりも、タプルの方を選 ぶべきである。 要素には、「id」属性を含めなければならない[MUST]。「id」属性 は、このタプルを、同じ<プレゼンティティ>にある他のタプルと区別するとき に使用される。属性の値は、同じ<プレゼンティティ>のタプルが持つ 「id」属性の中で、一意でなければならない[MUST]。「id」値はプレゼンス文 書を処理するアプリケーションで使用され、同じ<プレゼンティティ>で取得済 みの<プレゼンス情報>で対応するタプルを特定する。「id」属性の値は任意の 文字列であり、上記の通り、値を区別する手段を提供する以上の意味 はない。 要素はオプション[OPTIONAL]である。理由は、<プレゼンティティ> が<通信アドレス>を隠さなければならない場合や、<通信手段>に関連しないタ プルが存在する場合があるためである。ステータス要素を含むタプル には、アドレスを含めるべきである。タプルには、競合するプレゼ ンスステータスを含めてもよい[MAY]。たとえば、同じアドレスを含 むのうち、一方のがOPENの を提示し、同じ PIDFにある別のが<クローズド>の を含んでもよい。 <ウォッチャーユーザーエージェント>が、セグメント化されたプレゼンス情報 を知る手法は、当該の<ウォッチャーユーザーエージェント>とプレゼンスアプ リケーションの機能に依存している部分が大きい。タプルの意味を知るため の、アプリケーション独自またはプロトコル独自の方法がない場合、<ウォッ チャーユーザーエージェント>は以下の指針に従ってもよい[MAY]。<ウォッ チャーユーザーエージェント>は、各の「id」を以前の通知で受け取っ たものと関連付けることによって、また、(存在する場合は)タプルにある Sugano, et al. Standards Track [Page 7] RFC 3863 Presence Information Data Format August 2004 値と要素を比較することによって、最後の通知以降に、 PIDFにあるどのタプルがステートを変更したかについて注意すべきである。 4.1.3. 要素 要素には、1つのオプション[OPTIONAL]の要素が含まれ、次に オプション[OPTIONAL]で任意数の拡張要素が続き(他の名前空間からである可 能性あり)、また、その要素には、最低でも1つの子要素が存在する、 という制限がある。の子要素には、このタプルのステータス値が含ま れる。単一の要素に複数のステータス値を許容することで、ステータ ス値の異なる値(たとえば到達可能性や場所)は、で表すことができ る。複数のステータス値に関する例は、セクション4.3を参照のこと。 本文書は、ステータス値要素のみを定義する。標準の拡張性フレーム ワーク(セクション4.2.4参照)を使用して、他のステータス値を含めてもよ い。アプリケーションが内で認識できない要素に遭遇した場合、 mustUnderstand="true"属性またはmustUnderstand="1"属性が存在しなけれ ば、無視してもよい(セクション4.2.3を参照)。 要素は最低でも1つのステータス値要素を持たなければならないが、 このステータス値は要素ではない可能性がある、という点に注意する こと。 4.1.4. 要素 要素には、"open"または"closed"という文字列のいずれかが含まれ る。 「open」と「closed」の値は、がインスタントメッセージングのアド レスを示す場合、<インスタントメッセージ>を受け入れられるかどうかを示 す。また、一般的に、他の通信手段を利用できるかどうかについても示す。だ が、このメモでは、詳細を規定しない。 open: <インスタントメッセージ>の文脈で、この値は、関連する要 素(もしあれば)が、<インスタントメッセージ>を受け入れ可能な<インスタ ント受信トレイ>(INSTANT INBOX)に相当する、ということを意味する。 closed: <インスタントメッセージ>の文脈で、この値は、関連する 要素(もしあれば)が、<インスタントメッセージ>を受け入れ不可能な<イン スタント受信トレイ>に相当する、ということを意味する。 4.1.5. 要素 要素には、コンタクトアドレスのURIが含まれる。オプションで 「priority」属性を持ち、その値は、このコンタクトアドレスを他と比較し た、相対的優先度を意味する。属性の値は、小数点の後に最大3桁を持つ0〜1 Sugano, et al. Standards Track [Page 8] RFC 3863 Presence Information Data Format August 2004 の小数でなければならない[MUST]。値が高いほど、高い優先度を示す。優先値 は、たとえば、0、0.021、0.5、1.00である。「priority」属性が省略された 場合、アプリケーションは、そのコンタクトアドレスに低い優先度を割り当て なければならない[MUST]。「priority」値が範囲外である場合、アプリケー ションは単に値を無視すべきであり[SHOULD]、また属性が存在しなかった場合 と同様に処理すべきである[SHOULD]。 アプリケーションは、高い優先度を持つコンタクトを、より低い優先度を持つ ものより優位であるように対処すべきである[SHOULD]。実際の対処方法は本仕 様の範囲外である。また、同じ優先度を持つコンタクトの操作方法は、実装に 任せられる。 4.1.6. 要素 要素には、文字列値が含まれ、通常、人間が読めるコメントに使用され る。要素は、の子要素として、あるいは、要素の子 要素として使用してもよい[MAY]。前者の場合、コメントは<プレゼンティ ティ>に関するものであり、後者の場合、コメントは特定のタプルに関するも のである。 どこに使用されている場合でも、相互運用できない親要素のステータスの代わ りに、要素を使用および解釈すべきではない[SHOULD NOT]。 要素は、[XML]のセクション2.12で定義されるように、特殊な属性 「xml:lang」を持ち、また、この要素のコンテンツで使用される言語を指定す べきである。この属性の値は、[RFC3066]で定義されている言語識別子であ る。使用される言語が、コンテンツのエンコーディング情報など、囲んでいる XML要素のxml:lang属性、あるいは囲んでいるMIMEラッパーのContent- languageヘッダー[RFC3282]など、より大きなコンテキストで示される場合、 省略してもよい[MAY]。 4.1.7. 要素 要素には、このタプルのステータスが変更された日時を示す文字 列が含まれる。この要素の値は、IMPP日時書式[RFC3339]に従わなければなら ない[MUST]。「T」または「Z」を含むタイムスタンプは、大文字の書式を使用 しなければならない[MUST]。 正確なステータス変更時間を判定できるのであれば、セキュリティ手段とし て、要素をすべてのタプルに含めるべきである[SHOULD]。タイム スタンプを含むプレゼンス情報を受け取ったウォッチャー用のセキュリティ指 針は、「セキュリティの考慮」を参照のこと。 <プレゼンティティ>は、同じタイムスタンプを含む要素を連続して 生成してはならない[MUST NOT]。 Sugano, et al. Standards Track [Page 9] RFC 3863 Presence Information Data Format August 2004 4.2. プレゼンス情報の拡張性 プレゼンス情報の拡張性フレームワークは、XML名前空間に基づく[XML-NS]。 RFC 2779では、を超えるように値を拡張する手段を、PIDFが 持つことを必要としている。こうした拡張は、を知る方法を変更した り、あるいはPIDFボディ自体の構造やセマンティクスを変更してはならない [MUST NOT]。こうした拡張によって可能なのは、単に、プロトコルとアプリ ケーションがより多くのプレゼンスデータを定義することのみである。 4.2.1. XML名前空間の環境 全要素と一部の属性は、「名前空間」に関連付けられる。この名前空間はさら にグローバルに一意のURIに関連付けられる。どの開発者でも独自の要素名を 組み込むことができるが、適切な名前空間のURIを選択して競合しないように する必要がある。 プレゼンスデータ内で、要素、または属性名は、名前空間の接頭辞によって、 特定の名前空間に関連付けられる。この接頭辞は名前の先頭部分であり、以下 のようにコロン(「:」)が続く。 ... この例の「prefix」はヘッダー名の接頭辞で、「element-name」は、 「prefix」に関連付けられる名前空間がスコープする名前である。「prefix」 の選択は完全に任意であるということに注意すること。これは、命名範囲を定 義する対応URIである。2つの異なる接頭辞が同じ名前空間のURIに関連付けら れる場合、同じ名前空間を指す。 デフォルトの名前空間を、名前空間接頭辞なしで、XML要素用に宣言すること ができる。デフォルトの名前空間は属性名には適用しない[NOT]が、接頭辞の ない属性(unprefixed attribute)の解釈は、含む要素によって判断することが できる。 名前空間はURIによって特定される。この用法では、URIは単にグローバルに一 意な識別子として使用され、また、Webリソースの取得やその他の用途に使用 できる要件はない。名前空間を特定するために、文法にそった(legal)グロー バルに一意なURIを使用してもよい[MAY]。(本文書で「グローバルに一意」と は、同じURIを他者が異なる用途に使用しないことを予測できるように、特定 の規則セットに沿って構築されるものである。) 詳細は、XML名前空間の仕様を参照のこと[XML-NS]。 Sugano, et al. Standards Track [Page 10] RFC 3863 Presence Information Data Format August 2004 4.2.2. プレゼンス情報のXML名前空間 <プレゼンス情報>データにおいて名前空間識別子として使用されるURIは、RFC 2396[URI]に記載される完全な絶対URI(full absolute-URI)でなければならな い[MUST]。(識別子の断片を含んでいる相対URI(relative URIs)とURI参照(URI -references)を、この用途に使用してはならない[MUST NOT]。) 本仕様で定義される要素用の名前空間URIはURN[URN]であり、次に示すよう に、[URN-NS-IETF]で定義され、[XML-Registry]で拡張された、名前空間識別 子「ietf」を使用している。 urn:ietf:params:xml:ns:pidf したがって、単純なプレゼンスデータは次のようになる。 open tel:+09012345678 デフォルトのXML名前空間を使用すると、次のようになる。 open tel:+09012345678 名前空間を使用するXMLの場合に一般的なことだが、xmlns属性は、プレゼンス 情報において、デフォルトの名前空間や名前空間接頭辞に関連付けられる名前 空間を定義するために、すべての要素で使用される可能性がある。 Sugano, et al. Standards Track [Page 11] RFC 3863 Presence Information Data Format August 2004 4.2.3. 未認識要素名の操作 下記の場合を除き、<プレゼンス情報>のプロセッサは、未認識のXML要素(言い 替えると、未認識の名前空間のURI、またはその名前空間内にある未認識の ローカル名を持つもの)はすべて無視しなければならない[MUST]。これは、要 素が認識されている名前の要素を含むような場合を含め、要素のコンテンツす べてに該当する。 本来、PIDFの拡張は情報提供の文書だが、ステータス以外の付加情報 が記載されている。ただし、複雑な拡張を理解するために、拡張の要素内にネ ストされた要素は、必須としてマークする必要が出てくる可能性がある。この ような場合、要素名は、mustUnderstand='true' または mustUnderstand='1' 属性で修飾(qualified)される。例はセクション4.3.3を参照のこと。 注意: 無視されている要素内にあるmustUnderstand='true' または mustUnderstand='1' 属性自体も、無視される。ネストされた理解必須 (mandatory-to-understand)情報を記載した側は、必要であれば、囲んでい るすべての要素にも mustUnderstand='true' または mustUnderstand='1' 属性のラベルが付けられていることを確認する責任を持つ。 本仕様は、CPPプレゼンスデータにおいて認識しなければならない[MUST] 「urn:ietf:params:xml:ns:pidf」名前空間内の要素を定義する(セクション4. 1)。プロセッサは、mustUnderstand属性が含まれていない場合でも、本仕様に 記載される通り、これらの要素を処理しなければならない[MUST]。XMLスキー マ定義(セクション4.4)で、有効なプレゼンス情報ドキュメントに提示されな ければならない[MUST]、これらの要素を示している。 エージェントが、mustUnderstand='true' (or '1') 属性を持つ未認識要素を 含むブロックがある<プレゼンス情報>を受け取った場合、要素全体お よびすべてのコンテンツを未認識として扱うべきであり、処理を試行するべき ではない。 最低限の実装でも、基本的なPIDF情報を適切に処理できることを保証するため に、mustUnderstand属性は、要素でネストされるオプションの要素内 でのみ使用しなければならない[MUST]。これによって、拡張を処理する問題は 拡張内に限定されることになり、本仕様で定義される基本PIDF情報処理への影 響はない。 4.2.4. ステータス値の拡張性 このメモは、「open」および「closed」の値を持つステータス値のみ を定義する。他のステータス値は、前述で定義されている標準的な名前空間 ベースの拡張性規則に沿って、利用できる。 Sugano, et al. Standards Track [Page 12] RFC 3863 Presence Information Data Format August 2004 たとえば、locationのステータス値は次のように含められる。 open home im:someone@example.com 新規のステータス値によっては、要素の値を「拡張」する場合もあ る。たとえば、インスタントメッセージングの用途に定義されるステータス値 には、「away」、「busy」、および「offline」等の値を含む可能性がある。 新規の拡張を認識しないユーザーエージェントで、一定レベルの相互運用性を 維持するには、ステータス値も含めなければならない。つまり、拡張 には、各値から<オープン>または<クローズド>へのマッピングを定義する義務 はない、ということを意味する。 4.2.5. ステータス拡張の標準化 既存のPIDF定義によって、任意の要素を要素に入れることができるよ うになったが、拡張のステータス要素とそのセマンティクスを標準化する方が よい場合もある(特定ステータスの意味、どのように解釈するべきか)。 URN「urn:ietf:params:xml:ns:pidf:status」は、規定されるPIDF要 素の拡張の下にある包括的な名前空間として規定された(例: urn:ietf:params:xml:ns:pidf:status:my-extension)。この名前空間以下の新 しい値は、標準化過程のRFCで定義しなければならない[MUST]。 次のXMLスキーマ例は、「home」、「office」、または「car」という値を持つ 可能性がある、プレゼンス情報の拡張を定義する。要素 が標準化された場合、本文書は、拡張の使用に関する情報とともに、RFCで利 用可能になる。このうよな拡張は、名前空間「urn:ietf:params:xml:ns:pidf: status」を使用すべきであり、また、拡張を定義する各RFCは、その名前空間 内の拡張名をIANAに登録すべきである。 拡張を有効にするXMLスキーマ、拡張名のIANAへの登録に加え、拡張を定義す るRFCは以下の事項を検討しなければならない[MUST]。 - 拡張の適用範囲。この拡張は、IMクライアント、電話、ジオロケータなど、 特定用途専用か。どのような種類のプレゼンスアプリケーションがこの拡張 を使用するか。また、どのように環境で使用するか。 - 拡張で定義されるプレゼンスステータスのセマンティクス。どの処理によっ て、自動化されたプレゼンティティに状態Xにあると宣言させるか。あるい は、ユーザーがドラッグダウンメニューからXを選択するか。状態Yを持つプ レゼンス情報のウォッチャー用に一般的な指針はあるか(たとえば、仮にプ リンシパルが状態Yにあるとき、プレゼンティティと通信を試みる上で最適 な方法は何か)。 また、拡張は以下の事項についても検討すべきである[SHOULD]。 - 拡張で定義されるプレゼンスステータス(が仮にある場合)は、、 またはRFCとして発行された関連する拡張と、どのように関連するか。たと えば、「状態Zは<オープン>を意味する。そのため、<クローズド>の基本状 態が示される場合に使用してはならない[MUST NOT]」、あるいは「以下のよ うな状況の場合、RFC QQQQの拡張ではなく、本文書の拡張を使用すべきであ る。」など。 4.3. 例 4.3.1. ステータス拡張を使用するデフォルトの名前空間 次のインスタンスドキュメントでは、仮想的な'pidf:im' XML名前空間を、 PIDF用に開発されたステータス拡張例として使用している。 Sugano, et al. Standards Track [Page 14] RFC 3863 Presence Information Data Format August 2004 open busy home im:someone@mobilecarrier.net Don't Disturb Please! Ne derangez pas, s'il vous plait 2001-10-27T16:49:29Z open mailto:someone@example.com I'll be in Tokyo next week 4.3.2. 他の拡張要素を使用するプレゼンス open Extended value in tuple tel:+09012345678 open im:someone@mobilecarrier.net My extended presentity information Sugano, et al. Standards Track [Page 15] RFC 3863 Presence Information Data Format August 2004 4.3.3. 理解する必要のある要素例 open val1 val2 tel:+09012345678 My extended presentity information このは理解する必要がある。これが認識できない場合、 を無視しなければならない[MUST]。 とは、認識できない場合、無視してもよい[MAY]。 4.4. XMLスキーマ定義 このセクションでは、「application/pidf+xml」形式のXMLスキーマ定義 [XMLSchema1]について説明する。これは、「application/pidf+xml」形式の正 式な定義として提示される。XMLスキーマ定義は、プレゼンスXMLドキュメント のオンザフライ検証に使用する目的のものではない、ということに注意するこ と。 Sugano, et al. Standards Track [Page 16] RFC 3863 Presence Information Data Format August 2004 Sugano, et al. Standards Track [Page 17] RFC 3863 Presence Information Data Format August 2004 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. 5. IANA条項 本文書は、IANAに以下のことを要求している。 - 新規のMIME content-type「application/pidf+xml」を、[MIME]に従って登 録すること。 - 新規のXML名前空間「URN」を[XML-Registry]に従って登録すること。 - ステータス拡張用に、新規のXML名前空間「URN」を[XML-Registry]に従って 登録すること。 登録のテンプレートは後述。ステータスの拡張について詳しくは、セクション 4.2.5を参照のこと。 5.1. 「application/pidf+xml」のcontent-type登録 To: ietf-types@iana.org 件名: MIMEメディアタイプ「application/pidf+xml」の登録 MIMEメディアタイプ名: application MIMEサブタイプ名: pidf+xml 必須のパラメータ: なし Sugano, et al. Standards Track [Page 18] RFC 3863 Presence Information Data Format August 2004 オプションのパラメータ: charset 囲まれるXMLの文字エンコードを示す。デフォルトはUTF-8。 エンコーディングの考慮: 使用される文字エンコーディングに応じて、8-bit文字を採用できるXMLを 使用すること。RFC 3023 [RFC 3023]のセクション3.2を参照のこと。 セキュリティの考慮: このcontent-typeは、個人情報の可能性があるプレゼンスデータを伝達す るために設計されている。この情報の公開には、あらかじめ適切な注意を 払って制限を適用すべきである。 相互運用性の考慮: このcontent-typeは、異なるCPP準拠プロトコル間でプレゼンス情報を交換 するために、共通形式を提供する。 発行済みの仕様: RFC 3863 このメディアタイプを使用するアプリケーション: プレゼンスおよびインスタントメッセージングシステム。 補足情報: マジックナンバー: ファイルの拡張子: Macintoshファイルタイプコード: より詳しい情報についての連絡先窓口とe-mailアドレス: Hiroyasu Sugano EMail: sugano.h@jp.fujitsu.com 意図される用法: 限定された使用法 著者/改版管理者: 本仕様は、IETFのIMPPワーキンググループの研究項目であり、メーリング リストのアドレスはである。 その他の情報: このメディアタイプは、application/xml[RFC 3023]を専門化したものであ り、RFC 3023に記載されている多くの事項は、application/pidf+xmlにも 適用される。 5.2. 「urn:ietf:params:xml:ns:pidf」のURN下位名前空間登録 URI urn:ietf:params:xml:ns:pidf Sugano, et al. Standards Track [Page 19] RFC 3863 Presence Information Data Format August 2004 説明: これは、CPPプレゼンス情報をcontent-type「application/pidf+xml」で記 述するために、RFC 3863で定義されるXML要素のXML名前空間URIである。 登録者の連絡先: IETF, IMPP working group, Hiroyasu Sugano, XML: BEGIN Namespace for CPP presence information

Namespace for CPP presence information

urn:ietf:params:xml:ns:pidf

See RFC3863.

END 5.3. 「urn:ietf:params:xml:ns:pidf:status」のURN下位名前空間登録 URI urn:ietf:params:xml:ns:pidf:status 説明: これは、CPPプレゼンス情報のステータスに対する拡張をコンテンツタイプ 「application/pidf+xml」で記述するために、RFC 3863で定義されるXML 要素のXML名前空間URIである。 登録者の連絡先: IETF, IMPP working group, Hiroyasu Sugano, XML BEGIN Sugano, et al. Standards Track [Page 20] RFC 3863 Presence Information Data Format August 2004 Namespace for CPP status extensions

Namespace for CPP presence information extensions

urn:ietf:params:xml:ns:pidf:status

See RFC3863.

END 6. セキュリティの考慮事項 プレゼンスは非常に個人的かつ機密の情報なので、プレゼンス情報のプロトコ ルは、盗聴、不正行為、改ざん、リプレイ攻撃など、発生しうる脅威からPIDF を保護する機能を持たなければならない[MUST]。こうしたセキュリテイの仕組 みは、プレゼンティティとウォッチャー間のエンドツーエンドで使用すること ができなければならない。これは、ウォッチャーとプレゼンティティが異なる プレゼンスプロトコルを採用している場合や、CPPゲートウェイ経由で通信し ている場合も含む。「application/pidf+xml」MIMEタイプがこのPIDF文書で定 義されているため、PIDF向けのセキュリティはMIMEレベル(S/MIME [RFC3851]) で実行するのが適当と考えられる。そのため、PIDFは、CPPのコア仕様で提示 されている、S/MIMEを使用するための規範的な勧告(最小の暗号スイートを含 む)に従うべきである。 PIDF(セクション4.1.7参照)でタイムスタンプを使用することによって、リプ レイ攻撃に対して、ある程度の基本的な保護が可能になる、ということに注意 すること。ウォッチャーが期限切れのプレゼンス情報を受け取った場合、無視 するべきである[SHOULD]。ウォッチャーは、さまざまな方法で、プレゼンス情 報が期限切れであることを判断できる。最も重要なことは、プレゼンス情報に 含まれる最新のタイムスタンプが、最後に受け取ったプレゼンス情報に含まれ る最新のタイムスタンプよりも古い場合、期限切れと見なすべきである、とい う点である。アプリケーションおよびプロトコルもまた、プレゼンス情報の更 新頻度を判断するために、独自の規則を適用することが推奨される。たとえ ば、プレゼンス情報が1時間より古いような場合、期限切れと見なすことがで きる(このプレゼンス情報用に生成される通知は、ウォッチャーに到達するま でにそのような長時間はかからないし、プレゼンティティがプレゼンスステー トを1時間以内に更新しなかったということは、オフラインの可能性がある)。 Sugano, et al. Standards Track [Page 21] RFC 3863 Presence Information Data Format August 2004 7. 国際化の考慮事項 本仕様に適合するすべてのプロセッサは、UTF-8エンコーディングを生成およ び受け入れできなければならない[MUST]。これは、XMLに適合するプロセッサ 用に必須の文字エンコーディングの1つであり、また、RFC 2277 [RFC2277]で 提示されているポリシーでも必要とされている。 他の文字エンコーディングを受け入れてもよい[MAY](ただし、CPP準拠プロ セッサがUTF-8以外を発行することは、まったく推奨できない)。 8. 参考文献 8.1. 規範となる参考文献 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000, [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. Sugano, et al. Standards Track [Page 22] RFC 3863 Presence Information Data Format August 2004 [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, March 1995. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [XML-NS] Bray, T., Hollander, D., and A. Layman "Namespaces in XML", W3C recommendation: xml-names, 14 January 1999, [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [URN] Moats, R., "URN Syntax", RFC 2141, May 1997. [URN-NS-IETF] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [XML-Registry] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [XMLSchema1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC- xmlschema-1, May 2001, . 8.2. 有益な参考文献 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004. [CPP] Peterson, J., "Common Presence for Presence (CPP)", RFC 3859, August 2004. [vCard] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998. Sugano, et al. Standards Track [Page 23] RFC 3863 Presence Information Data Format August 2004 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. Sugano, et al. Standards Track [Page 24] RFC 3863 Presence Information Data Format August 2004 付録 A. ドキュメントタイプ定義 「application/pidf+xml」形式のドキュメントタイプ定義(Document Type Definition / DTD)について説明する。このDTDのセクションは、XMLスキーマ 定義になじみのない読者向けの情報提供のためだけに記載されている。 注意: DTDは、拡張を追加できる場所を示すものではない。 この情報用のXMLスキーマを参照すること。 Sugano, et al. Standards Track [Page 25] RFC 3863 Presence Information Data Format August 2004 著者の連絡先 Hiroyasu Sugano Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan EMail: sugano.h@jp.fujitsu.com Shingo Fujimoto Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan EMail: shingo_fujimoto@jp.fujitsu.com Graham Klyne Nine by Nine EMail: GK@ninebynine.org 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 EMail: wayne.carr@intel.com Sugano, et al. Standards Track [Page 26] RFC 3863 Presence Information Data Format August 2004 Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz Sugano, et al. Standards Track [Page 27] RFC 3863 Presence Information Data Format August 2004 完全な著作権表示 Copyright (C) The Internet Society (2004).本文書は、BCP 78に含まれる権 利、ライセンス、制限の対象となり、BCP 78に記載されている例外に従い、著 者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、インター ネット協会およびIETFは、この情報がいかなる権利も侵害していないという保 証、商用利用および特定目的への適合性への保証を含め、また、これらだけに 限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載され ている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性があ る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権 について、すべての関連団体に対して配慮するよう依頼している。情報につい ては、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Sugano, et al. Standards Track [Page 28]