Network Working Group J. Rosenberg Request for Comments: 3858 dynamicsoft Category: Standards Track August 2004 ウォッチャー情報のための拡張可能マークアップ言語(XML)ベースの書式 An Extensible Markup Language (XML) Based Format for Watcher Information 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 ウォッチャー(watcher)は、リソースに関する情報を要求する(つまりサブスク ライブする)エンティティと定義されている。このサブスクリプションに関連 付けられているステートは、実に複雑である。特定のリソースに対するすべて のサブスクリプションについて、ステートを結合したものは、そのリソースの ウォッチャー情報(watcher information)と呼ばれる。このステートは動的で あり、サブスクライバの行き来に応じて変わる。結果として、特定リソースの ウォッチャー情報にサブスクライブすることは、可能であり、また実際に有益 である。サブスクライブを可能にするために、リソースに関するウォッチャー のステートを記述する書式が必要とされる。本仕様では、このようなステート 用に、拡張可能マークアップ言語(Extensible Markup Language/XML)ドキュメ ントの書式について説明する。 目次 1. はじめに ................................................... 2 2. 用語 ...................................................... 2 3. ウォッチャー情報の構築 ..................................... 2 4. ドキュメントからのウォッチャーリスト算出 ................... 5 5. 例 ...................................................... 6 6. XMLスキーマ ................................................ 6 7. セキュリティの考慮.......................................... 8 8. IANA条項 ................................................... 9 8.1. application/watcherinfo+xml MIME登録 .................. 9 8.2. urn:ietf:params:xml:ns:watcherinfoのURN下位名前登録 ... 10 9. 規範となる参考文献 ......................................... 10 10. 有益な参考文献 ............................................ 11 Rosenberg Standards Track [Page 1] RFC 3858 Watcher Info August 2004 11. 謝辞 ...................................................... 11 12. 寄稿者 .................................................... 12 13. 著者の連絡先 .............................................. 13 14. 完全な著作権表示 .......................................... 14 1. はじめに ウォッチャー(watcher)は、RFC3265(参考文献[1])のSIPイベントパッケージを 使用して、リソースに関する情報を要求する(つまりサブスクライブする)エン ティティと定義されている。このサブスクリプションに関連付けられているス テートは、実に複雑である。このステートには、サブスクライバのアイデン ティティ、サブスクリプションのステートなどが含まれる。特定のリソースに 対するすべてのサブスクリプションについて、ステートを結合したものは、そ のリソースのウォッチャー情報(watcher information)と呼ばれる。このス テートは動的であり、サブスクライバの行き来に応じて変わる結果として、特 定リソースのウォッチャー情報にサブスクライブすることは、可能であり、ま た実際に有益である。重要な用途は、ユーザーが、自分のプレゼンティティに 対するサブスクライバのセットを検出することができる機能である。これに よって、ユーザーは、サブスクリプションに対して認可の判断を行うことがで きる。 ウォッチャー情報に対するサブスクリプションに対応するために、2つの要素 が必要である。1つ目は、ウォッチャー情報用のSIPイベントテンプレートパッ ケージの定義である。もう1つは、ウォッチャー情報を表すデータ書式の定義 である。1つ目は参考文献[2]で既定されており、2つ目は本文書で既定する。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119のBCP 14(参考文献[3])に 記載されるとおりに解釈されるべきであり、CPL準拠の実装のための実装レベ ルを示すものである。 本文書では、サブスクライバ(subscriber)、ウォッチャー(watcher)、サブス クリプション(subscription)、通知(notification)、ウォッチャー情報サブス クリプション(watcherinfo subscription)、ウォッチャー情報サブスクライバ (watcherinfo subscriber)、ウォッチャー情報通知(watcherinfo notification)という用語も使用するが、意味は参考文献[2]を参照のこと。 3. ウォッチャー情報の構築 ウォッチャー情報は、整形済みのXMLドキュメントでなければならない [MUST]。また有効なXMLドキュメントであるべき[SHOULD]である。ウォッ チャー情報ドキュメントは、XML 1.0に基づかなければならず[MUST]、また UTF-8を使用してエンコードされなければならない[MUST]。本仕様は、ウォッ チャー情報ドキュメントとドキュメントの断片を特定するために、XML名前空 間を利用する。本仕様で定義される要素に対する名前空間URIは、URN(参考文 献[5])であり、参考文献[6]で定義され、参考文献[7]で拡張される名前空間識 別子「ietf」を使用している。このURNを以下に示す。 Rosenberg Standards Track [Page 2] RFC 3858 Watcher Info August 2004 urn:ietf:params:xml:ns:watcherinfo ウォッチャー情報ドキュメントは、ルート要素タグ「watcherinfo」で始ま る。watcherinfoの下位要素として、任意数の「watcher-list」がある。各 watcher-listは、特定リソースのウォッチャーリストである。拡張性の目的か ら、異なる名前空間から他の要素を提示してもよい[MAY]。未知の名前空間に ある要素または属性は、無視しなければならない[MUST]。「watcherinfo」要 素に関連付けられる属性は2つあり、いずれも、以下を示さなければならない [MUST]。 version: この属性によって、受信者は、ウォッチャー情報ドキュメントを適 切に順序付けできる。versionは0で始まり、ウォッチャー情報サブスクラ イバへ送信される新規ドキュメントごとに1ずつインクリメントする。 versionは、ウォッチャー情報サブスクリプションの範囲内である。 versionは、32ビット整数を使って表現可能でなければならない[MUST]。た だし、versionはラップしない。 state: この属性は、ドキュメントに完全なウォッチャー情報ステートが含ま れるか、または、前のドキュメント以降にステートが変わったウォッ チャーに関する情報のみが含まれる(部分的)かを示す。 各「watcher-list」要素には、「watcher」要素のリストが含まれ、各 「watcher」要素には、特定リソースに関するウォッチャーが記述される。拡 張性の目的から、異なる名前空間から他の要素を提示してもよい[MAY]。未知 の名前空間にある要素または属性は、無視しなければならない[MUST]。 「watcher-list」要素に関連付けられる属性は2つあり、いずれも、以下を示 さなければならない[MUST]。 resource: この属性には、そのリストのウォッチャーによってウォッチされて いるリソースのURIが含まれる。これは必須である。 package: この属性には、そのリソースに関するウォッチャー情報を提供する イベントパッケージを示す、トークンが含まれる。これは必須である。 「watcher」要素には、ウォッチャーリストのウォッチャーを記述する。 「watcher」の値は、ウォッチャーのURIである。このURIは、サブスクリプ ションを処理するサーバーによる判断どおりに、ウォッチャーの認証済みアイ デンティティにすべきである[SHOULD]。したがって、このURIは、デバイスの アドレス(たとえばsip:joe@192.0.2.3)とは対照的に、通常、Addresses-of- Record(たとえばsip:joe@example.com)になる。提示が必要な[MUST]必須の属 性は、3つある。 Rosenberg Standards Track [Page 3] RFC 3858 Watcher Info August 2004 id: ウォッチャー要素によって記述されるサブスクリプションの固有な識別 子。idは、RFC3261参考文献[8]で既定されるトークンの文法を使用して、 表現可能でなければならない[MUST]。idは、特定のウォッチャー情報サブ スクリプションに関する通知で送信された、ドキュメントに報告されてい る他のウォッチャーすべての中で、固有でなければならない[MUST]。 status: サブスクリプションのステータス。多様なステータスの意味が、 ウォッチャー情報イベントパッケージ(参考文献[2])に定義されている。 event: 現在のステータスへ移行するきっかけとなったイベント。イベント は、ウォッチャー情報イベントパッケージ(参考文献[2])に定義されてい る。 また、オプションとして、ウォッチャー要素の参考になる属性がいくつかあ る。これを以下に示す。 display-name: サブスクライバ名のテキスト表記。 expiration: サブスクリプションが期限切れになるまでの総時間(現在の時間 からの秒数)。 duration-subscribed: サブスクリプションを作成したSUBSCRIBEが受信された 時間から、現在の時間までの総時間(秒単位)。 「xml:lang」属性は、「watcher」要素とともに使用して、「display-name」 の言語を使用してもよい[MAY]。 各リソースごとに存在するウォッチャーの数と、列挙されるリソースのセット は、提示されるデータの種類と、提示先の相手によって変わる。 たとえば、ウォッチャー情報を使用するプレゼンスシステムがあるとする。あ るシナリオでは、ユーザーAは、他のユーザーであるBのプレゼンスにサブスク ライブする。Aは、そのサブスクリプションのステータスについて検出するこ とを望む。この場合、Aは、Bのプレゼンスに関するウォッチャー情報にサブス クライブする。Aは、Bのプレゼンスについて、すべてのウォッチャーのステー タスを知る権限はない。結果として、Aに送信されるウォッチャー情報には、1 つのウォッチャー、つまりA自身のみが含まれる。 別のシナリオでは、ユーザーBは、Bのプレゼンスにサブスクライブしたユー ザー達を知りたいと望んでいる。この場合、Bは、Bのプレゼンスに関する ウォッチャー情報にサブスクライブする。Bには、Bのプレゼンスについて、す べてのウォッチャーを知る権限がある。結果として、Bに送信されるウォッ チャー情報には、Bのプレゼンスの全ウォッチャーが含まれる。 Rosenberg Standards Track [Page 4] RFC 3858 Watcher Info August 2004 管理者が、システムの現在のステータスを知りたい場合、ウォッチャー情報に は、すべてのリソースに対するすべてのウォッチャーを含むことができる。 4. ドキュメントからのウォッチャーリスト算出 通常、ウォッチャー情報のNOTIFYには、ステートが変わったウォッチャーに関 する情報のみが含まれる。全ウォッチャーのステート全体の整合性がとれた ビューを構築するために、ウォッチャー情報のサブスクライバは、長期間に 渡って受け取ったNOTIFYをバインドする必要がある。ウォッチャー情報サブス クライバは、情報を受信した各ウォッチャーリストごとに1つの表を保持す る。各ウォッチャーリストは、「watcher-list」要素の「resource」属性に含 まれるURIによって、固有に識別される。各表には、そのウォッチャーリスト の各ウォッチャーごとに1行が登録されている。各行はそのウォッチャー用の 固有なIDによってインデックスされる。IDは、「watcher」要素の「id」属性 で伝達される。各行のコンテンツには、「watcher」要素で伝達された、その ウォッチャーのステートが含まれる。また、この表は、バージョン番号にも関 連付けられる。バージョン番号は、最初に受け取ったドキュメントの 「watcherinfo」の「version」属性の値で初期化されなければならない [MUST]。新規ドキュメントを受信するたびに、ローカルのバージョン番号値 と、新規ドキュメント内の「version」値が比較される。新規ドキュメントの 値がローカルのバージョン番号より1大きい場合、ローカルのバージョン番号 は1増加され、ドキュメントが処理される。ドキュメントの値がローカルの バージョン番号より2以上大きい場合、ローカルのバージョン番号は新規ド キュメントの値に設定され、ドキュメントは処理される。また、ウォッチャー 情報サブスクライバは更新リクエストを生成して、完全なステート通知のトリ ガとすべきである[SHOULD]。ドキュメントの値がローカルのバージョン番号未 満の場合、そのドキュメントは破棄され、処理は行われない。 ウォッチャー情報ドキュメントの処理は、含まれているのが完全なステートか 部分的なステートかによって異なる。ドキュメントに完全なステートが含まれ る場合(「watcherinfo」要素の「state」属性値で示される)、このウォッ チャー情報サブスクリプションに関連付けられるすべての表のコンテンツは消 去される(flushed)。表のコンテンツは、ドキュメントから改めて組み込まれ る。新規の表は、各「watcher-list」要素ごとに作成され、各表の新規の行 は、各「watcher」要素ごとに作成される。ウォッチャー情報に部分的なス テートが含まれている場合(「watcherinfo」要素の「state」属性値で指定さ れる)、ドキュメントは既存の表を更新するために使用される。ウォッチャ ー情報サブスクライバは、各「watcher-list」要素ごとに、そのリストに対応 する表が存在するかどうかを確認する。このチェックは、「watcher-list」要 素の「resource」属性に含まれるURIと、表に関連付けられているURIとを比較 することで行われる。そのリストに対応する表が存在しない場合、表が作成さ れる。ウォッチャー情報サブスクライバは、登録内の各「watcher」要素ごと に、そのウォッチャーに対応する行が存在するかどうかを確認する。この Rosenberg Standards Track [Page 5] RFC 3858 Watcher Info August 2004 チェックは、「watcher」要素の「id」属性にあるIDと、行に関連付けられて いるIDとを比較することで実行される。ウォッチャーが表に存在しない場合、 行が追加され、ステートとして「watcher」要素の情報に設定される。ウォッ チャーが存在する場合、そのステートは、「watcher」要素の情報に更新され る。行が更新または作成されると、ステートはterminatedになるので、そのエ ントリは、いつでも表から削除してよい[MAY]。 5. 例 次に、professorというプレゼンティティのウォッチャー情報という例を 示す。ユーザーAとユーザーBという2つのウォッチャーがある。 sip:userA@example.net sip:userB@example.org 6. XMLスキーマ watcherinfoドキュメント書式のXMLスキーマ定義を以下に示す。 Rosenberg Standards Track [Page 7] RFC 3858 Watcher Info August 2004 7. セキュリティの考慮 ウォッチャー情報は、機密情報である。配信に使用するプロトコルでは、プラ イバシ、メッセージの整合性、認証を確証すべきである[SHOULD]。さらに、プ ロトコルでは、他人のウォッチャー情報を誰が参照できるかについて制限す る、アクセス制御を提供すべきである。 8. IANA条項 本文書は、新規のMIMEタイプapplication/watcherinfo+xmlを登録し、新規の XML名前空間を登録する。 8.1. application/watcherinfo+xml MIME登録 MIMEメディアタイプ名: application MIMEサブタイプ名: watcherinfo+xml 必須のパラメータ: なし オプションのパラメータ: RFC3023(参考文献[9])で規定される application/xmlの文字セットパラメータと同様。 エンコーディングの考慮: RFC3023(参考文献[9])で規定される application/xmlのエンコーディングの考慮と同様。 セキュリティの考慮: RFC3023(参考文献[9])のセクション10と、本仕様のセク ション7を参照のこと。 相互運用性の考慮: なし。 発行済みの仕様: 本文書。 Rosenberg Standards Track [Page 8] RFC 3858 Watcher Info August 2004 このメディアタイプを使用するアプリケーション: このドキュメントタイプ は、SIPベースのプレゼンス(参考文献[10][2])向けに、サブスクライバの 認可機能に対応するために使用されてきた。 補足情報: マジックナンバー: なし ファイルの拡張子: .wif または .xml Macintoshのファイルタイプコード: 「TEXT」 より詳しい情報についての連絡先窓口とe-mailアドレス: Jonathan Rosenberg, 意図される用法: 汎用 著者/改版管理者:IETF。 8.2. urn:ietf:params:xml:ns:watcherinfoのURN下位名前登録 このセクションでは、参考文献[7]の指針に従って、新規のXML名前空間を登録 する。 URI: この名前空間のURIは、urn:ietf:params:xml:ns:watcherinfoである。 登録者の連絡先: IETF、SIMPLE ワーキンググループ、 Jonathan Rosenberg . XML: BEGIN Watcher Information Namespace

Namespace for Watcher Information

urn:ietf:params:xml:ns:watcherinfo

See RFC3858.

Rosenberg Standards Track [Page 9] RFC 3858 Watcher Info August 2004 END 9. 規範となる参考文献 [1] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [2] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible Markup language (XML) 1.0 (second edition)," W3C Recommendation REC-xml-20001006, World Wide Web Consortium (W3C), Oct. 2000. Available at http://www.w3.org/XML/. [5] Moats, R., "URN Syntax", RFC 2141, May 1997. [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [9] Murata, M., Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [10] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. 10. 有益な参考文献 [11] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. 11. 謝辞 Sean Olson、Steve Donovan、Cullen Jenningsの各氏からいただいた、XMLス キーマに関する詳細なコメントと補助に対して感謝を述べたい。 Rosenberg Standards Track [Page 10] RFC 3858 Watcher Info August 2004 12. 寄稿者 本仕様の初版を開発した元の設計チームとして、以下の寄稿者が参加してい た。 Dean Willis dynamicsoft 5100 Tennyson Parkway, Suite 1200 Plano, Texas 75024 EMail: dwillis@dynamicsoft.com Robert Sparks dynamicsoft 5100 Tennyson Parkway, Suite 1200 Plano, Texas 75024 EMail: rsparks@dynamicsoft.com Ben Campbell EMail: ben@nostrum.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 EMail: schulzrinne@cs.columbia.edu Jonathan Lennox Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 EMail: lennox@cs.columbia.edu Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: huitema@microsoft.com Rosenberg Standards Track [Page 11] RFC 3858 Watcher Info August 2004 Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 EMail: bernarda@microsoft.com David Gurle Reuters Corporation EMail: David.Gurle@reuters.com Jonathan Lennoxは、本仕様の初期バージョンに含まれていた、DTDとその用法 に関するテキストを寄稿した。 13. 著者の連絡先 Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 EMail: jdrosen@dynamicsoft.com Rosenberg Standards Track [Page 12] RFC 3858 Watcher Info August 2004 14. 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP78に含まれる権 利、ライセンス、制限の対象となり、BCP78に記載されている例外に従い、著 者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネットソサエティおよびIETFは、この情報がいかなる権利も侵害していな いという保証、商用利用および特定目的への適合性への保証を含め、また、こ れらだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書に関する手順の情報は、BCP78とBCP79を参照のこと。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、本規格の実装に必要になる可能性がある技術の範囲に及ぶ可能性があ る、任意の著作権、特許、特許アプリケーション、その他の所有権への配慮 を、関係者に依頼している。情報については、IETFの ietf-ipr@ietf.org ま で連絡されたい。 謝辞 RFC編集者職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2004年 ----------------------------------------------------------------------- Rosenberg Standards Track [Page 13]