Network Working Group J. Rosenberg Request for Comments: 3840 dynamicsoft Category: Standards Track H. Schulzrinne Columbia University P. Kyzivat Cisco Systems August 2004 セッション開始プロトコル(SIP)における ユーザーエージェント能力の指定 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配布は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本仕様は、セッション開始プロトコル(Session Initiation Protocol / SIP) のユーザーエージェントが、他のユーザーエージェントおよびドメインのレジ ストラに対し、自身の能力および特性を伝達できる仕組みについて定義する。 この能力はContactヘッダーフィールドのパラメータとして伝達される。 Rosenberg, et al. Standards Track [Page 1] RFC 3840 SIP Capabilities August 2004 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. 定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. コンテンツネゴシエーションフレームワークの用法 . . . . . . . . 6 5. 能力の算出 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. 登録における能力表現 . . . . . . . . . . . . . . . . . . . . . 10 7. リモートターゲットURIにおけるフィーチャーセット指定 . . . . . . 12 8. OPTIONS処理 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Contactヘッダーフィールド . . . . . . . . . . . . . . . . . . . 13 10. メディアフィーチャータグ定義 . . . . . . . . . . . . . . . . . 14 10.1. オーディオ . . . . . . . . . . . . . . . . . . . . . . 15 10.2. アプリケーション . . . . . . . . . . . . . . . . . . . 16 10.3. データ . . . . . . . . . . . . . . . . . . . . . . . . 16 10.4. 制御 . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.5. ビデオ . . . . . . . . . . . . . . . . . . . . . . . . 17 10.6. テキスト . . . . . . . . . . . . . . . . . . . . . . . 18 10.7. 自動装置 . . . . . . . . . . . . . . . . . . . . . . . 18 10.8. クラス . . . . . . . . . . . . . . . . . . . . . . . . 19 10.9. 双方向性 . . . . . . . . . . . . . . . . . . . . . . . 20 10.10. 移動性 . . . . . . . . . . . . . . . . . . . . . . . . 20 10.11. 説明: . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.12. イベントパッケージ . . . . . . . . . . . . . . . . . . 22 10.13. 優先順位 . . . . . . . . . . . . . . . . . . . . . . . 22 10.14. メソッド . . . . . . . . . . . . . . . . . . . . . . . 23 10.15. 拡張 . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.16. スキーマ . . . . . . . . . . . . . . . . . . . . . . . 24 10.17. アクター . . . . . . . . . . . . . . . . . . . . . . . 25 10.18. フォーカスかどうか . . . . . . . . . . . . . . . . . . 26 11. セキュリティの考慮 . . . . . . . . . . . . . . . . . . . . . . 26 11.1. メディアフィーチャータグの考慮 . . . . . . . . . . . . 26 11.2. 登録の考慮 . . . . . . . . . . . . . . . . . . . . . . 27 11.3. OPTIONS応答の考慮 . . . . . . . . . . . . . . . . . . . 28 11.4. ダイアログ開始メッセージの考慮 . . . . . . . . . . . . 28 12. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.1. SIPメディアフィーチャータグの登録ツリー . . . . . . . . 28 12.2. メディアフィーチャータグ . . . . . . . . . . . . . . . 29 12.3. SIPオプションタグ . . . . . . . . . . . . . . . . . . . 30 13. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . 31 14.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . 31 付録 RFC2533の概要 . . . . . . . . . . . . . . . . . . . . . 33 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . . 36 Rosenberg, et al. Standards Track [Page 2] RFC 3840 SIP Capabilities August 2004 1. はじめに セッション開始プロトコル(Session Initiation Protocol / SIP) (参考文献 [1])のユーザーエージェントが示す能力やデバイスのタイプは広範に渡る。他 のSIP要素がSIP UAの能力や特性を知ることが重要なことはよくある。この情 報に関するアプリケーションには、以下のものが含まれる。 o あるユーザーエージェントは、PCペースのアプリケーションだが、機能が 限定されたているデバイスに組み込まれている別のユーザーエージェント とやり取りしている。PCは、相手側が対応していない機能や能力を示す ユーザーインターフェースのコンポーネントを「淡色表示」できるように したい。そうするには、ダイアログ内で能力情報を交換する方法が必要に なる。 o あるユーザーは利用できるデバイスを2個持っている。1個はビデオ電話 で、もう1個は音声のみのワイヤレス電話である。発呼側はビデオを使って そのユーザーと交流したい。そのため、ビデオに対応するデバイスへ呼を 優先的にルートさせたい。そうするために、INVITEリクエストには、特定 の能力を持つデバイスへルートするためのプリファレンスを表すパラメー タを含めることができる(参考文献[11])。 o あるネットワークアプリケーションは、MESSAGE(参考文献[16])リクエスト で、ユーザーエージェントへ情報を非同期に送信したい。だが、送信前 に、UAがそのメッセージを受信するために必要な能力を持っているかどう かを知りたい。そうするために、こうした情報を保持しているドメインが 管理しているユーザーデータベースを完全にクエリーする。このような データベースの集合は、UAが登録の一部として能力を伝達することを要求 する。したがって、REGISTERリクエストで能力を伝達する必要がある。 SIPには能力の拡張に対応するものがいくつかある。Allow、Accept、Accept- Language、Supportedヘッダーフィールドは、ユーザーエージェントの能力に 関する情報の一部を伝達する。だが、これらのヘッダーフィールドは必要な情 報のごく一部しか伝達しない。これらは、能力を表現するための一般的なフ レームワークを提供していない。さらに、これらは能力を間接的に指定してい るだけである。というのも、ヘッダーフィールドは、実際のところ、リクエス トへ適用するときに、UAの能力を示すためである。また、SIPは、特性(UAを説 明する情報)を伝達する能力はない。 結果として、本仕様は、SIPにおいて能力および特性を示すための、より一般 的なフレームワークを提示する。UAに関する能力と特性の情報は、Contact Rosenberg, et al. Standards Track [Page 3] RFC 3840 SIP Capabilities August 2004 ヘッダーフィールドのパラメータとして伝達される。これらのパラメータは、 REGISTERリクエストと応答、および、ダイアログを生成するリクエストと応答 (例えばINVITE)の中で使用することができる。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119のBCP 14(参考文献[2])に 記載されるとおりに解釈されるべきであり、CPL準拠の実装のための実装レベ ルを示すものである。 3. 定義 フィーチャー(Feature): RFC2703(参考文献[17])に定義されているように、 メッセージ伝達システム(message passing system)のコンポーネント、ま たはデータリソースの特性を操作するメディアに関する1つの情報である。 例えば、あるUAが対応する複数のSIPメソッドは、1つのフィーチャーであ る。 フィーチャータグ(Feature Tag): RFC2703(参考文献[17])に定義されているよ うに、フィーチャータグは、フィーチャーを識別する名称である。例とし て、「sip.methods」が挙げられる。 メディアフィーチャー(Media Feature): RFC2703(参考文献[17])に定義されて いるように、メディアフィーチャーとは、メッセージコンテンツを正しく レンダリングしたり、あるいは提示する上で利用できると推測される機能 を示す情報である。メッセージ送信に影響する情報をメディアフィー チャーへ含める目的はない。 本仕様内では、メディアフィーチャーとは、コンテンツに特化したもので はなく、SIPリクエストを操作する機能に関わる情報を指す。この意味にお いては、フィーチャーの同意語として使用される。 フィーチャーコレクション(Feature Collection): RFC2533(参考文献[4])に定 義されているように、フィーチャーコレクションとは、異なるメディア フィーチャーと、それに関連する値のコレクションである。ドキュメント またはリソースのうち、特定のインスタンスの特定のレンダリングを記述 する場合に使われる可能性がある。 フィーチャーセット(Feature Set): RFC2703(参考文献[17])に定義されている ように、フィーチャーセットは、メッセージ転送時に、送信者や受信者、 その他参加者が操作可能なフィーチャー一式を記述する情報である。 「フィーチャー」は1個のリソースにつき1個の識別属性を記述するが、 「フィーチャーセット」は、可能性のある属性すべての1セットを記述す る。 Rosenberg, et al. Standards Track [Page 4] RFC 3840 SIP Capabilities August 2004 フィーチャーパラメータ(Feature Parameters): Contactヘッダーフィールド に出てくる可能性のある、SIPのヘッダーフィールドパラメータのセット。 フィーチャーパラメータはフィーチャーセットのエンコーディングを表 す。フィーチャーパラメータの各セットは、フィーチャーセット述部 (predicate)にマップされる。 能力(Capability): RFC2703(参考文献[17])に定義されているように、能力と は、メッセージコンテンツの特定のタイプを生成または処理する能力を示 す、送信側または受信側(受信側の場合が多い)の属性である。能力と特性 の違いは、能力は特定の呼で利用の有無を選択できるが、特性はUAのネゴ シエート不可能な属性である点である。SIPでは、能力を呼で使用するかど うかについてネゴシエートすることがよくある。 特性(Characteristic): 特性は能力に似ているが、ネゴシエートできないUAの 特徴を表すものである。たとえば、UAが携帯電話かどうかは特性だが、能 力ではない。この仕様のセマンティクスでは能力と特性に違いはないが、 説明の便宜上、区別している。以下の説明でも、特記しない場合、「能 力」は能力と特性の両方を指す。 フィルタ(Filter): フィーチャーセットの述部にある単式 (singleexpression)。 シンプルフィルタ: フィーチャータグとフィーチャー値の比較(等価か不等価 か)を示す、フィーチャーセット述部にある式。 論理和(Disjunction): 複数項(term)のブールOR演算。 論理積(Conjunction): 複数項のブールAND演算。 述部(Predicate): ブール式。 フィーチャーセット述部: RFC2533(参考文献[4])によると、フィーチャー セット述部とは、ブールの結果を返す、任意のフィーチャーコレク ショ ン値の関数である。TRUEという結果は、述部が定義する能力を操 作する メディアフィーチャーのセットいずれかに、対応するフィー チャーコレ クションが所属する、ということを意味する。 Contact述部: REGISTERリクエストのContactヘッダーフィールドに登録されて いるURIに関連付けられるフィーチャーセット述部。Contact述部は、 Contactヘッダーフィールドのフィーチャーパラメータに含まれる。 Rosenberg, et al. Standards Track [Page 5] RFC 3840 SIP Capabilities August 2004 4. コンテンツネゴシエーションフレームワークの用法 本仕様では、IETF内で運営され、いくつかのRFCにドキュメント化されている コンテンツネゴシエーション(content negotiation)研究で使用される用語と 概念を多用する。本仕様に関連するものとして、メディアフィーチャータグを 登録するためのテンプレートを供給するRFC2506(参考文献[3])、メディア フィーチャーセットのための構文とマッチングアルゴリズムを提示する RFC2533(参考文献[4])、RFC2738(参考文献[5])(RFC2533のマイナーアップデー ト)、コンテンツネゴシエーションの一般的なフレームワークを提供する RFC2703(参考文献[17])が挙げられる。 読者がこうした仕様を読む時間がない場合は、本仕様を理解する上で重要なこ れらドキュメントのうち、概念と用語の簡単な概要が付録Aに記載されてい る。 コンテンツネゴシエーション研究は、本来、ドキュメントや他のリソースに考 えうるレンダリングのセットを適用する用途だったため、SIPのユーザーエー ジェントのひな形として、どのように使用するかについてはすぐに明らかには ならない。フィーチャーセットは一組のフィーチャーコレクションから構成さ れ、各々は、フィーチャーセットが示すエンティティが対応する特定のレンダ リングを表す。SIPユーザーエージェントの範囲では、フィーチャーコレク ションは瞬間的な様相(instantaneous modality)を表す。つまり、SIP UAのラ ンタイム処理を観察し、適切な時間にスナップショットをとった場合、その フィーチャーコレクションは、まさにその瞬間に何をしていたかを表すのであ る。 このモデルは重要である。なぜなら、特定のフィーチャータグの値は何か、ま たはフィーチャータグ自体が何かを決定する方法について、ガイダンスを提供 するためである。2つの特性がUAから同時に提示される可能性がある場合、ど ちらも瞬間的な様相にあるため、異なるメディアフィーチャータグで表される 必要がある。例えば、UAはいくつかのメディアタイプ(音声、ビデオ)に対応・ 制御できる場合がある。それぞれが1個の「media-types」に対して異なる値を 持つべきだろうか、あるいは、それぞれが別個のブール型フィーチャータグを 持つべきだろうか?本モデルはその回答を提供する。どの瞬間においても、UA は音声とビデオの両方を操作できるため、別個のメディアフィーチャータグを 持つ必要がある。だが、UAが対応するSIPメソッドはそれぞれ、同じメディア フィーチャータグ(「sip.methods」タグ)に対して異なる値で表される可能性 がある。なぜなら、基本的に、1個のUAが同時に処理するのは1個のリクエスト であるという理由からである。マルチスレッドなのでそう見えないかもしれな いが、純粋な機能レベルにおいては事実である。 明らかにこのモデルには弱点はあるが、RFC2533の概念をすぐにこの問題に適 用するために、有用なガイドラインを提示する。 Rosenberg, et al. Standards Track [Page 6] RFC 3840 SIP Capabilities August 2004 5. 能力の算出 能力を示すContactヘッダーフィールドパラメータのセットを構築するには、 UAはそのContactに関するフィーチャー述部を構築する。この処理は、RFC2533 (参考文献[4])(および、マイナーアップデートのRFC2738(参考文献[5]))の構 文と構成概念、それに続き、本仕様で使用される構文への変換という観点で解 説される。一方で、処理の論理フローを示す。仲介段階で実際にRFC2533構文 を実装が使用する必要はない。 UAは、IANA経由でSIPツリー(セクション12.1に記載)に登録されているフィー チャータグ、またはIETFつまりグローバルツリー(参考文献[3])で登録されて いるフィーチャータグをすべて使用してもよい[MAY]。本文書でもSIPツリーに フィーチャータグをいくつか登録する。本仕様で議論されるフィーチャータグ はベースタグとして参照される。他のタグを使用できる一方で、それらを フィーチャーパラメータとして識別するために(他のSIP拡張のためのパラメー タとは対照的に)、これらはContactヘッダーフィールド内で先頭に「+」記号 付きでエンコードされる。また、ベンダー独自のフィーチャータグを表現する 場合、URIツリー(参考文献[3])を使用してもよい。また、IANA経由で作成され るその他ツリーのフィーチャータグを使用してもよい[MAY]。 「sip.methods」フィーチャータグを使用する場合、UAは、IETFの標準化過 程のRFCで標準化されていないメソッドに相当する値を含めてはならない [MUSTNOT]。「sip.events」フィーチャータグを使用する場合、UAはIETFの標 準化過程のRFCで標準化されていないイベントパッケージに相当する値を含め てはならない[MUST NOT]。「sip.schemes」フィーチャータグを使用する場 合、UAはIETFの標準化過程のRFCで標準化されていないスキームに相当する値 を含めてはならない[MUST NOT]。「sip.extensions」フィーチャータグを使用 する場合、UAはIETFの標準化過程のRFCで標準化されていないオプションタグ に相当する値を含めてはならない[MUST NOT]。 「sip.schemes」フィーチャータグは、登録されたURLのスキームを示すもので はないということに注意。むしろ、これはUAがリクエストを送ることのできる 宛先のスキームを指すと言えるため、このようなURIはWebページや、リダイレ クト応答のContactヘッダーフィールドで受信されるべきである。 UAは、自身のContact述部で完全な情報を提供することが推奨される [RECOMMENDED]。言い替えると、できるだけ多くのフィーチャータグに関する 情報を提供すべきであるということである[SHOULD]。本仕様の仕組みは、ユー ザーエージェントが完全なフィーチャーセットを登録する場合に、最もよく機 能する。さらに、UAが特定のフィーチャータグに対して値を登録する場合は、 対応するすべての値を列挙しなければならない[MUST]。例えば、「sip. methods」フィーチャータグを含める場合、UAは対応するすべてのメソッドを 列挙しなければならない[MUST]。 UAが構築するContact述部は、複数項のAND(論理積と呼ぶ)でなければならない [MUST]。各々の項は、複数のシンプルフィルタまたはシンプルフィルタのネゴ シエーションのOR(論理和と呼ぶ)、あるいは、1個のシンプルフィルタまたは1 Rosenberg, et al. Standards Track [Page 7] RFC 3840 SIP Capabilities August 2004 個のシンプルフィルタのネゴシエーションである。論理和の場合、論理和内の 各フィルタは、同じフィーチャータグに対するフィーチャー値を示さなければ ならない[MUST](言い替えると、論理和は特定のフィーチャータグに対する値 のセットを表す)し、一方で、論理積の各要素は異なるフィーチャータグのた めのものでなければならない[MUST]。各シンプルフィルタは等式の可能性があ り、また、数値のフィーチャータグの場合、不等式や範囲の可能性がある。シ ンプルフィルタの値に文字列(RFC2533(参考文献[4])で定義)を使用する場合、 その値には「<」または「>」を含めてはならない[MUST NOT]。シンプルフィル タを否定(negate)してはならない[MUST NOT]。その値は、特定フィーチャータ グ用の唯一のシンプルフィルタでなければならない[MUST]。それから、この Contact述部は、後述で概要説明される手順に従って、フィーチャーパラメー タのリストへ変換される。 Contact述部は、複数項の論理積である。各項は、1個のフィーチャータグに対 する制限を示し、また、各項は、Contactヘッダーフィールドで提示する別個 のフィーチャーパラメータで表される。このパラメータの構文は、フィー チャータグよって変わる。フィーチャータグ内の各スラッシュは一重引用符 に変換され、各コロンは感嘆符に変換される。ベースタグ、つまり本仕様に記 載されるフィーチャータグ(sip.audio、sip.automata、sip.class、 sip.duplex、sip.data、sip.control、sip.mobility、sip.description、 sip.events、sip.priority、sip.methods、sip.extensions、sip.schemes、 sip.application、sip.video、language、type、sip.isfocus、sip.actor、 sip.text)が存在する場合は、外す。この一覧にない「sip.」で始まるフィー チャータグが存在する場合は、外してはならない[MUST NOT]。また、プラス記 号(「+」)をContactヘッダーフィールドの先頭文字に追加しなければならない [MUST]。その結果はフィーチャーパラメータ名になる。この規則の結果、ベー スタグは、接頭辞に「+」も「sip.」付かず、Contactヘッダーフィールドに 「裸」の状態で示される。他のすべてのタグは、Contactヘッダーフィールド で提示される場合、必ず先頭に「+」が付く。さらに、タグがSIPツリーにある 場合は、「sip.」が付く。 フィーチャーパラメータの値は、論理積の項によって変わる。その項がTRUEの 値を持つブール表現の場合、言い替えると(sip.audio=TRUE)の場合、その Contactパラメータは値を持たない。論理積のその項が論理和の場合、Contact パラメータの値は、引用符付き文字列である。引用符付き文字列とは、カンマ で区切られた文字列のリストであり、論理和にある複数項のひとつから取得さ れる個々を指す。論理積の項が否定(negation)の場合、Contactパラメータの 値は引用符付きの文字列である。この引用符付きの文字は、感嘆符(!)で始ま り、残りの部分は否定される式で構成される。 残る操作は、初期のフィルタから文字列を算出することである。フィルタが数 値を比較するシンプルフィルタの場合、文字列はシャープ(#)で始まり、フィ Rosenberg, et al. Standards Track [Page 8] RFC 3840 SIP Capabilities August 2004 ルタ内の比較演算子(=または>=、<=)が続き、フィルタの値が続く。フィルタ の値が有理式(X / Y)で表される場合、XとYは割られて小数となり、この小数 は文字列へ出力される。 RFC2533は、有理数を記述するために、分数表記(fractional notation) を 使用している。本仕様は小数点書式を使用する。上記のテキスト は、2つ の表現間で変換されることがまれにある。実際には、いずれの 場合でも数 値は同じなので、変換する必要はない。ただ、実装時に、 このセクション の規則で生成される述部をRFC2533の実装に直接当ては めたい場合のため に、記載している。 フィルタが範囲(foo=X..Y)の場合、XとYが分数(A / B)から小数の同値へ変換 されたので、この文字列はX:Yと同等である。 フィルタがトークンまたはブールと同等の場合、そのトークン値またはブール 値(「TRUE」または「FALSE」)は文字列に出力される。 フィルタが引用符付きの文字列と同等の場合、出力は、小なり記号(<)に、引 用符付きの文字列が続き、さらに、大なり記号(>)が続く。 一例として、以下のフィーチャー述部を挙げる。 (& (sip.mobility=fixed) (| (! (sip.events=presence)) (sip.events=message-summary)) (| (language=en) (language=de)) (sip.description="PC") (sip.newparam=TRUE) (rangeparam=-4..5125/1000)) これは、以下のフィーチャーパラメータへ変換される。 mobility="fixed";events="!presence,message-summary";language="en,de" ;description="";+sip.newparam;+rangeparam="#-4:+5.125" このフィーチャータグは、Contactヘッダーフィールドの一部として示され る。 Contact: ;mobility="fixed";events="!presence,message-summary" ;language="en,de";description="" ;+sip.newparam;+rangeparam="#-4:+5.125" sip.mobility、sip.events、sip.descriptionの各フィーチャータグが、 Contactヘッダーフィールドでエンコードされる前に、先頭の「sip.」が削除 Rosenberg, et al. Standards Track [Page 9] RFC 3840 SIP Capabilities August 2004 された点について注意すること。削除されたのは、これらのフィーチャータグ が前述したベースタグに含まれているためである。また、これらのフィー チャータグの先頭に「+」を付けてエンコードされなかったのも、この理由か らである。一方で、sip.newparamタグは、「+」と先頭の「sip.」付きでエン コードされ、rangeparamも先頭の「+」付きでエンコードされた。これは、ど ちらのフィーチャータグも本仕様で定義されていないためである。したがっ て、先頭の「sip.」は削除されず、「+」が追加された。 6. 登録における能力表現 UAが登録するとき、UAは登録されるコンタクトと関連づけられるフィーチャー セットを指定するかどうかを選択できる。UAがそれを実行するかどうかは、そ の登録されたURIが何であるかに依存する。登録されたURIがUAのインスタンス である場合(登録時に一般的なケース)、本仕様に準拠するUAは、ここに記載さ れる仕組みを使用するフィーチャーセットを示すべきである[SHOULD]。だが、 登録されたURIが、1個のフィーチャーセットで表すことのできないAddress-of -Recordやその他のリソースである場合、フィーチャーセットは含むべきでは ない[SHOULD NOT]。例えば、あるユーザーが sip:user1@example.com から sip:user2@example.org へ呼を転送(forward)したい場合、(部分的だが)以下 のような登録が生成される可能性がある。 REGISTER sip:example.com SIP/2.0 To: sip:user1@example.com Contact: sip:user2@example.org この場合、登録されたコンタクトはUAを識別するものというよりは、別の Address-of-Recordである。このような場合、登録されたコンタクトはフィー チャーセットを示すものではない。 だが、UAがAddresses-of-Recordに対してフィーチャーパラメータを表示した い場合もある。一例として、ホームネットワーク内にある様々なデバイスを表 し、また、ユーザーの家にあるプロキシサーバーへルートするAOR[訳注: Addresses-of-Record]が挙げられる。家庭内のすべてのデバイスは個人利用の ためなので、AOR自体は「class="personal"」フィーチャーパラメータととも に記載することができる。このホームAORへ呼を転送(forward)する登録は、そ のフィーチャーパラメータを利用できる。一般的に、そのAddresses-of- Recordに結びつけられるすべてのデバイスが、フィーチャーパラメータに対す る値のセットとまったく同じものを共有する場合、フィーチャーパラメータ は、1個のAddresses-of-Recordのみと関連づけられる。 同様に、場合によってはUAは何らかの特性を提示できるが、事前にその特性を 知られることはない。たとえば、UAは、デバイスが応答マシンの組み込まれて いる電話であると示すことができる。このようなデバイスを扱うための理想的 な方法は、電話(応答マシンではない)と応答マシン(電話ではない)という2つ Rosenberg, et al. Standards Track [Page 10] RFC 3840 SIP Capabilities August 2004 のデバイスを前面に持つ実際のプロキシのように作成することである。このデ バイスからの登録は、前述の手順のように、AORであるように構築される。通 常、これは、複数の論理デバイスの中で特性を特定できない場合、その特性は 実際のデバイスによって生成される登録には存在しないということを意味す る。 以降、このセクションでは、1個のフィーチャーセットと登録している1個の ContactとをUAは関連づけたいもの、と仮定して進める。このフィーチャー セットは、セクション5に記載される通り、一連のContactヘッダーフィールド パラメータへ構築・変換され、さらに、これらのフィーチャーパラメータは、 パラメータが適用されるURIを含むContactヘッダーフィールド値へ追加され る。Allow、Accept、Accept-Language、Allow-Events(参考文献[9])ヘッダー フィールドは、REGISTERリクエストに使用でき、能力を示すこともできる。た だし、REGISTERのセマンティクスはさまざまであり、応答の生成でレジストラ が使用する能力を示す。したがって、これらはContactフィーチャーパラメー タの代替ではなく、一般的に言うと、UAの能力を示すものである。 クライアントがレジストラが本仕様で定義される拡張を理解しているかどうか を確認したい場合、REGISTERリクエストに「pref」という値を持つRequire ヘッダーフィールドを含めるてもよい[MAY]。これは、レジストラはフィー チャーパラメータを保持し、また、それらをドメイン内のロケーションサービ スへアクセスする要素が利用できるようにする、ということを意味する。 Requireヘッダーフィールドがない場合、本仕様を理解しないレジストラは、 単にContactヘッダーフィールドパラメータを無視するだけである。 UAが別個の複数のAddresses-of-Recordに対して登録する場合、また、それぞ れに登録されたContactが異なる能力を持っている場合、UAは各登録内の異な るURIを使用しなければならない[MUST]。これによって、送られてくるリクエ ストのリクエストURIと関連づけられるフィーチャーセットを、UAが一意に決 定できる。 たとえば、audioとvideoのメディアタイプに対応し、携帯性のないUAであるボ イスメールサーバーの場合、以下のようなフィーチャー述部を構成する。 (& (sip.audio=TRUE) (sip.video=TRUE) (sip.actor=msg-taker) (sip.automata=TRUE) (sip.mobility=fixed) (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS) (sip.methods=ACK) (sip.methods=CANCEL))) Rosenberg, et al. Standards Track [Page 11] RFC 3840 SIP Capabilities August 2004 これらはフィーチャーパラメータに変換され、REGISTERリクエストに含められ る。 REGISTER sip:example.com SIP/2.0 From: sip:user@example.com;tag=asd98 To: sip:user@example.com Call-ID: hh89as0d-asd88jkk@host.example.com CSeq: 9987 REGISTER Max-Forwards: 70 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 Contact: ;audio;video ;actor="msg-taker";automata;mobility="fixed" ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" Content-Length: 0 ボイスメールサーバーは、通常、自動装置(automata)であり、メッセージ取得 機(message taker)であるということに注意。 UACが登録を更新するときは、アクティブな状態を保つ場合、フィーチャーパ ラメータをその更新に含めなければならない[MUST]。さらに、レジストラが 200 OK応答を返すときは、各Contactヘッダーフィールド値に、そのURIと関連 付けられたすべてのフィーチャーパラメータを含めなければならない[MUST]。 7. リモートターゲットURIにおけるフィーチャーセット指定 ターゲット更新リクエストおよび応答は、ダイアログ内のリモートターゲット URIを確立および変更するために使用される。リモートターゲットURIは Contactヘッダーフィールドで伝達される。UACまたはUASは、UAの能力を指定 する目的で、ターゲット更新リクエストおよび応答中のContactヘッダー フィールド値にフィーチャーパラメータを追加してもよい[MAY]。それを実行 するために、セクション5に従ってフィーチャーパラメータのセットを構築す る。それから、これらは、リクエストまたは応答内で、Contactヘッダー フィールドパラメータとして追加される。 フィーチャーパラメータは、最初のリクエストとダイアログ内リクエストの双 方に含まれる可能性があり、UA能力の変更を示すためにダイアログ内を変更し てもよい[MAY]。 Allow、Accept、Accept-Language、Allow-Eventsヘッダーフィールド(参考文 献[9])に関する着呼側能力の仕組みには重複があり、また、これはターゲット 更新リクエストにも使用される可能性がある。特に、Allowヘッダーフィール ドと「sip.methods」フィーチャータグは、同じ情報を示す。Acceptヘッダー フィールドと「type」フィーチャータグは同じ情報を示す。Accept-Language ヘッダーフィールドと「language」フィーチャータグは同じ情報を示す。 Allow-Eventsヘッダーフィールドと「sip.events」フィーチャータグは同じ情 報を示す。将来的に定義される別のヘッダーフィールドとフィーチャータグも Rosenberg, et al. Standards Track [Page 12] RFC 3840 SIP Capabilities August 2004 また、重複するという可能性はある。SIPヘッダーフィールドに相当する可能 性もある能力を記述するフィーチャータグが存在する場合、UAはその 能力を 記述するためにそのヘッダーフィールドを使わなければならない[MUST]。ヘッ ダーフィールドとフィーチャータグの両方を含むメッセージを受け取ったUA は、フィーチャータグではなく、ヘッダーフィールドを使用しなければならな い[MUST]。 8. OPTIONS処理 本仕様に準拠するUASがOPTIONSリクエストを受け取る場合、UAの能力を示す目 的で、OPTIONS応答のContactヘッダーフィールドにフィーチャーパラメータを 追加してもよい[MAY]。それを実行するために、セクション5に従ってフィー チャーパラメータのセットを構築する。さらに、これらはOPTIONS応答におい てContactヘッダーフィールドパラメータとして追加される。実際、フィー チャーパラメータがそのUAが生成する登録に含まれる場合、その同じパラメー タはOPTIONS応答で使用されるべきである[SHOULD]。 セクション7には、SIPヘッダーフィールドでさまざまな着呼側能力のフィー チャータグが重複することに関するのガイドラインが記載されているが、これ はOPTIONS応答の生成にも同様に適用できる。特に、Contactヘッダーフィール ドでOPTIONS応答を生成したUAを記述する場合に適用される。OPTIONS応答の Contactヘッダーフィールドが異なるUAを示す場合、重複はない。 9. Contactヘッダーフィールド 本仕様はContactヘッダーフィールドを拡張する。具体的には、Contactヘッ ダーフィールドパラメータがfeature-paramを含めることができるようにす る。feature-paramは、ContactヘッダーフィールドにあるURIと関連づけられ るUAのフィーチャーを記述するフィーチャーパラメータである。フィーチャー パラメータは、既知の基本的なフィーチャータグのセットに所属するか、ある はプラス記号で始まるため、識別することができる。 feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list / string-value ) RDQUOT] enc-feature-tag = base-tags / other-tags base-tags = "audio" / "automata" / "class" / "duplex" / "data" / "control" / "mobility" / "description" / "events" / "priority" / "methods" / "schemes" / "application" / "video" / "language" / "type" / "isfocus" / "actor" / "text" / "extensions" other-tags = "+" ftag-name ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / "." / "-" / "%" ) Rosenberg, et al. Standards Track [Page 13] RFC 3840 SIP Capabilities August 2004 tag-value-list = tag-value *("," tag-value) tag-value = ["!"] (token-nobang / boolean / numeric) token-nobang = 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) boolean = "TRUE" / "FALSE" numeric = "#" numeric-relation number numeric-relation = ">=" / "<=" / "=" / (number ":") number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">" qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D / %x3F-5B / %x5D-7E / UTF8-NONASCII tag-value-listでは、引用符付き文字列内(行の折り返しは実行できない)で示 すため、COMMA構文ではなく実際にカンマを使用するということに注意。 qdtextはRFC3261(参考文献[1])で提示されている。 BNFで表すことのできないプリファレンスの使用においては、別の制限があ る。feature-paramに存在するのは、いかなるフィーチャータグでも1個のイン スタンスのみでなければならない[MUST]。フィーチャーパラメータにあるどの 数値も、ANSI Cの倍精度実数を使って表せなければならない[MUST]。 以下の提示は、contact-paramsに対するRFC3261(参考文献[1])の記載を更新す る。 contact-params = c-p-q / c-p-expires / feature-param / contact-extension 10. メディアフィーチャータグ定義 本仕様は、本仕様で使用するメディアフィーチャータグの初期セットを定義す る。このセクションは、これらのフィーチャータグのIANA登録として機能し、 SIPメディアフィーチャータグのツリーに登録される。新規のメディアフィー チャータグは、フィーチャータグ登録(参考文献[3])で定義されている手順 に従ってIETFつまりグローバルツリーに登録されるか、あるいはセクション 12.1で定義されている手順に従ってSIPツリーに登録される。 すべての登録済みのフィーチャータグは、本仕様とともに使用してもよい [MAY]。実際、既存のいくつかは特に適用可能であると思われる。これらに は、UAで表される人物や自動装置の言語を指定するために使用できるlanguage フィーチャータグ(参考文献[6])、SIP UAがSIPメッセージで受け取り可能な MIMEタイプを指定するために使用できるtypeフィーチャータグ(参考文献[7]) が含まれる。ただし、SIPツリーのaudio、video、application、data、 controlフィーチャータグ(それぞれ、RFC2327(参考文献[8])で定義されるよう に、メディアタイプを示す)は、異なる。これらは、SIPリクエストで受け取り Rosenberg, et al. Standards Track [Page 14] RFC 3840 SIP Capabilities August 2004 可能なトップレベルのMIMEタイプを示さない。その代わり、これらはメディア ストリームで使用可能なメディアタイプを示す。結果として、RFC2327(参考文 献[8])で定義されるタイプにマッチする。 新規のSDPメディアタイプ、例えば「message」が定義された場合、それに対し て新規のフィーチャータグ登録もSIPツリーに作られるべきである[SHOULD]。 フィーチャータグ名は、「sip.」とメディアタイプ名を連結したものと同じで なければならない[MUST]。ただし、新規のメディアタイプと既存のフィー チャータグ登録とで、万が一、名前が衝突する場合は、この限りではない。結 果として、名前がぶつからなければ、新たなメディアタイプが登録される前 に、実装で発呼側プリファレンスと着呼側能力を安全に構築することができ る。 本仕様とともに使用する意図で新規のメディアフィーチャータグが登録される 場合、エンコードされていない書式のタグで登録される(セクション5参照)。 言い替えると、新規のフィーチャータグ「foo」がIETFツリーに登録される場 合、IANA登録は、タグ「+foo」ではなく、タグ「foo」に対するものになる。 同様に、新規のフィーチャータグ「sip.gruu」がSIPツリーに登録される場 合、IANA登録は、タグ「+sip.gruu」または「gruu」ではなく、タグ 「sip.gruu」に対するものになる。したがって、SIPツリーへの登録には、す べて接頭辞に「sip.」が付く。 このセクションのフィーチャータグはすべて、セクション12.1で作成される SIPメディアフィーチャータグのツリーに登録される。 10.1. オーディオ メディアフィーチャータグ名: sip.audio ASN.1識別子: 1.3.6.1.8.4.1 このタグで示されるメディアフィーチャーの概要: このフィーチャータグは、 デバイスがストリーミングメディアタイプとしてaudioに対応することを示 す。 このフィーチャータグの使用に適切な値: ブール。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: オーディオに対応可能な電話へ呼をルートするとき。 関連する規定またはドキュメント: RFC3840 Rosenberg, et al. Standards Track [Page 15] RFC 3840 SIP Capabilities August 2004 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.2. アプリケーション メディアフィーチャータグ名: sip.application ASN.1識別子: 1.3.6.1.8.4.2 このタグで示されるメディアフィーチャーの概要: このフィーチャータグは、 デバイスがストリーミングメディアタイプとしてapplicationに対応すると いうことを示す。このフィーチャータグは、主に補完のためにある。あま りにも多くのMIMEタイプがapplication以下にあるため、applicationに対 応する能力を示すことは、あまり有益な情報とは言えない。 このフィーチャータグの使用に適切な値: ブール。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、通信アプリケー ションで、電話やPDAなどのデバイスの能力を記述する場合に最も有効であ る。 一般的な使用例: メディア制御アプリケーションに対応できる電話へ呼をルー トするとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.3. データ メディアフィーチャータグ名: sip.data ASN.1識別子: 1.3.6.1.8.4.3 このタグで示されるメディアフィーチャーの概要: このフィーチャータグは、 デバイスがストリーミングメディアタイプとしてdataに対応するというこ とを示す。 このフィーチャータグの使用に適切な値: ブール。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 Rosenberg, et al. Standards Track [Page 16] RFC 3840 SIP Capabilities August 2004 一般的な使用例: データストリーミングアプリケーションに対応可能な電話へ 呼をルートするとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.4. 制御 メディアフィーチャータグ名: sip.control ASN.1識別子: 1.3.6.1.8.4.4 このタグで示されるメディアフィーチャーの概要: このフィーチャータグは、 デバイスがストリーミングメディアタイプとしてcontrolに対応するという ことを示す。 このフィーチャータグの使用に適切な値: ブール。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: フロア制御アプリケーションに対応できる電話へ呼をルート するとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.5. ビデオ メディアフィーチャータグ名: sip.video ASN.1識別子: 1.3.6.1.8.4.5 このタグで示されるメディアフィーチャーの概要: このフィーチャータグはデ バイスがストリーミングメディアタイプとしてvideoに対応することを示 す。 このフィーチャータグの使用に適切な値: ブール。 Rosenberg, et al. Standards Track [Page 17] RFC 3840 SIP Capabilities August 2004 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: ビデオに対応する電話へ呼をルートするとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.6. テキスト メディアフィーチャータグ名: sip.text ASN.1識別子: 1.3.6.1.8.4.6 このタグで示されるメディアフィーチャーの概要: このフィーチャータグは、 デバイスがストリーミングメディアタイプとしてtextに対応するというこ とを示す。 このフィーチャータグの使用に適切な値: ブール。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: テキストに対応可能な電話へ呼をルートするとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.7. 自動装置 メディアフィーチャータグ名: sip.automata ASN.1識別子: 1.3.6.1.8.4.7 このタグで示されるメディアフィーチャーの概要: sip.automataフィーチャー タグは、UAが自動装置(例えばボイスメールサーバーや会議サーバー、 IVR、録音装置)か、あるいは人物かを表す、ブール型の値である。 Rosenberg, et al. Standards Track [Page 18] RFC 3840 SIP Capabilities August 2004 このフィーチャータグの使用に適切な値: ブール。TRUEはUAが自動装置を表す ことを示す。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: 自動サービスが受け入れ不可能とわかる場合、自動装置との 通信を拒否。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.8. クラス メディアフィーチャータグ名: sip.class ASN.1識別子: 1.3.6.1.8.4.8 このタグで示されるメディアフィーチャーの概要: このフィーチャータグは、 コミュニケーションデバイスがビジネス用途か個人用途かという設定を示 す。 このフィーチャータグの使用に適切な値: 等式関係を持つトークン。通常、以 下の値が含まれる。 business: デバイスはビジネス上のコミュニケーションに使用される。 personal: デバイスは個人のコミュニケーションに使用される。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、通信アプリケー ションで、電話やPDAなどのデバイスの能力を記述する場合に最も有効であ る。 一般的な使用例: 会社の電話か自宅の電話かを選択するとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 Rosenberg, et al. Standards Track [Page 19] RFC 3840 SIP Capabilities August 2004 10.9. 双方向性 メディアフィーチャータグ名: sip.duplex ASN.1識別子: 1.3.6.1.8.4.9 このタグで示されるメディアフィーチャーの概要: sip.duplexメディアフィー チャータグは、コミュニケーションデバイスが同時にメディアを送受信で きるか(「full」)、あるいは送信と受信を交互に行うか(「half」)、受信 のみか(「receive-only」)、送信のみか(「send-only」)を示す。 このフィーチャータグの使用に適切な値: 等式関係を持つトークン。通常、以 下の値が含まれる。 full: デバイスは同時にメディアを送受信できる。 half: デバイスは、メディアの送信と受信を交互に行える。 receive-only: デバイスはメディアの受信のみ行える。 send-only: デバイスはメディアの送信のみ行える。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: 呼に案内を聞かせる場合に、通常の電話とは異なり、ブロー ドキャストサーバーとやり取りすることを選択するとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.10. 移動性 メディアフィーチャータグ名: sip.mobility ASN.1識別子: 1.3.6.1.8.4.10 このタグで示されるメディアフィーチャーの概要: sip.mobilityフィーチャー タグはデバイスが固定か(ネットワークと接続する1個の固定ポイントに関 連づけられるという意味)、あるいはモバイルか(接続する1個の固定ポイン Rosenberg, et al. Standards Track [Page 20] RFC 3840 SIP Capabilities August 2004 トに関連づけられないという意味)を示す。この定義に基づくと、コードレ ス電話はモバイルではなく固定であるということに注意。 このフィーチャータグの使用に適切な値: 等式関係を持つトークン。通常、以 下の値が含まれる。 fixed: デバイスは固定である。 mobile: デバイスはユーザーとともに移動する可能性がある。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: 机の上に電話の代わりに、ワイヤレス電話とやり取りするこ とを選択するとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.11. 説明: メディアフィーチャータグ名: sip.description ASN.1識別子: 1.3.6.1.8.4.11 このタグで示されるメディアフィーチャーの概要: sip.descriptionフィー チャータグは、デバイスのテキストによる説明を提示する。 このフィーチャータグの使用に適切な値: 等式関係を持つ文字列。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: デバイスが特定の種類や型であるということを示すとき。 関連する規定またはドキュメント: RFC3840 Rosenberg, et al. Standards Track [Page 21] RFC 3840 SIP Capabilities August 2004 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.12. イベントパッケージ メディアフィーチャータグ名: sip.events ASN.1識別子: 1.3.6.1.8.4.12 このタグで示されるメディアフィーチャーの概要: sip.events(複数であるこ とに注意)フィーチャータグの各値は、SIP UAが対応するSIPイベントパッ ケージ(参考文献[9])を示す。このタグの値は、各イベントパッケージが登 録しているイベントパッケージ名と一致する。 このフィーチャータグの使用に適切な値: 等式関係を持つトークン。値は、 IANAのSIPイベントタイプの名前空間登録から取られる。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: ボイスメールサーバー(参考文献[12])のように、メッセージ 待ちイベントパッケージに対応するサーバーとやり取りすることを選択す るとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.13. 優先順位 メディアフィーチャータグ名: sip.priority ASN.1識別子: 1.3.6.1.8.4.13 このタグで示されるメディアフィーチャーの概要: sip.priorityフィーチャー タグは、デバイスが操作したい呼の優先順位を示す。値Xは、デバイスが優 先順位X以上のリクエストを受けたいということを意味する。これは、電話 は優先順位の低い呼を拒否しなければならない、ということを意味しな い。通例通り、このような呼に対する対処方法は、ローカルポリシーの問 題である。 Rosenberg, et al. Standards Track [Page 22] RFC 3840 SIP Capabilities August 2004 このフィーチャータグの使用に適切な値: 整数。整数値はそれぞれ、SIP(参考 文献[1])で規定されるようにPriorityヘッダーフィールドとして可能性な 値に対応する。マッピングは以下のように定義される。 non-urgent: 整数値10。デバイスは緊急ではない呼に対応する。 normal: 整数値20。デバイスは通常の呼に対応する。 urgent: 整数値30。デバイスは緊急の呼に対応する。 emergency: 整数値40。デバイスは非常時の呼に対応する。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのような デバイスの能力を表す、コミュニケーションアプリケーションに最適である。 一般的な使用例: ユーザーの緊急連絡用携帯電話とやり取りすることを選択す るとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.14. メソッド メディアフィーチャータグ名: sip.methods ASN.1識別子: 1.3.6.1.8.4.14 このタグで示されるメディアフィーチャーの概要: sip.methods(複数であるこ とに注意)フィーチャータグの各値は、UAが対応するSIPメソッドを示す。 この場合、「対応する」とは、UAがこのメソッドを持つリクエストを受信 することができるということを意味する。この意味では、Allowヘッダー フィールドと同じ意味を持つ。 このフィーチャータグの使用に適切な値: 等式関係を持つトークン。値はIANA のSIPパラメータ登録で定義されているメソッドテーブルから取られる。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 Rosenberg, et al. Standards Track [Page 23] RFC 3840 SIP Capabilities August 2004 一般的な使用例: PC上の電話アプリケーションではなく、PC上のプレゼンスア プリケーションとやり取りすることを選択するとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.15. 拡張 メディアフィーチャータグ名: sip.extensions ASN.1識別子: 1.3.6.1.8.4.15 このタグで示されるメディアフィーチャーの概要: sip.extensionsフィー チャータグ(複数であることに注意)の各値は、UAが理解しているSIP拡張 (IANAに登録されているoption-tagで定義済みのもの)である。「理解して いる」とは、ここでは、リクエストのSupportedヘッダーフィールドに optionタグが含まれるということを意味する。 このフィーチャータグの使用に適切な値: 等式関係を持つトークン。値はIANA のSIPパラメータ登録にあるオプションタグテーブルから取られる。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: QoS前提条件に対応しない電話ではなく、対応する電話とや り取りすることを選択するとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.16. スキーマ メディアフィーチャータグ名: sip.schemes ASN.1識別子: 1.3.6.1.8.4.16 このタグで示されるメディアフィーチャーの概要: sip.schemes(複数であるこ とに注意)メディアフィーチャータグの各値は、UAが対応するURIスキーム (参考文献[10])を示す[訳注: 原文の(not the plurality - 複数ではない) は誤植で、10.14にもある「note the ...」が正しいと思われる]。「対応 Rosenberg, et al. Standards Track [Page 24] RFC 3840 SIP Capabilities August 2004 する」とは、例えば、UAが、リダイレクト応答のContactヘッダーフィール ドにあるスキームのURIをどのように操作すべきかをUAが理解しているとい うことを含んでいる。 このフィーチャータグの使用に適切な値: 等式関係を持つトークン。値はIANA のURIスキーム登録から取られる。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: 着呼側パーティがビジーの場合、Webではなく、電話番号へ リダイレクトさせることを選択するとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.17. アクター メディアフィーチャータグ名: sip.actor ASN.1識別子: 1.3.6.1.8.4.17 このタグで示されるメディアフィーチャーの概要: このフィーチャータグは、 このURIで利用可能なエンティティのタイプを示す。 このフィーチャータグの使用に適切な値: 等式関係を持つトークン。以下の値 が定義される。 principal: このデバイスは、デバイスと関連付けられる本人(principal) との通信を提供する。これは、特定の人物であることが多いが、自動装 置である可能性もある(たとえば、音声受付への発呼など)。 attendant: このデバイスは、デバイスに関連付けられる本人に連絡すると きに、仲介として動作する自動装置または人物、つまり代理人との通信 を提供する。 msg-taker: このデバイスは、メッセージを取得して本人に配信する自動装 置または人物との通信を提供する。 information: このデバイスは、本人に関する情報を提供する自動装置また は人物との通信を提供する。 Rosenberg, et al. Standards Track [Page 25] RFC 3840 SIP Capabilities August 2004 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: ボイスメールへ呼をルートしないように要求するとき。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 10.18. フォーカスかどうか メディアフィーチャータグ名: sip.isfocus ASN.1識別子: 1.3.6.1.8.4.18 このタグで示されるメディアフィーチャーの概要: このフィーチャータグは、 UAがカンファレンスサーバー(フォーカスとしても知られている)であるこ とを示し、同じURIへのすべての呼のメディアをミックスする(参考文献 [13])。 このフィーチャータグの使用に適切な値: ブール。 フィーチャータグの主な用途(アプリケーション、プロトコル、サービス、ネ ゴシエーションのメカニズム): このフィーチャータグは、電話やPDAのよ うなデバイスの能力を表す、コミュニケーションアプリケーションに最適 である。 一般的な使用例: UAが接続しているサーバーがカンファレンスサーバーである ことを、UAに示す場合。 関連する規定またはドキュメント: RFC3840 セキュリティの考慮: このメディアフィーチャータグに関するセキュリティの 考慮は、RFC 3840のセクション11.1に記載されている。 11. セキュリティの考慮 11.1. メディアフィーチャータグの考慮 このセクションでは、本仕様などのメディアフィーチャータグについて、セ キュリティの考慮事項を記載する。 Rosenberg, et al. Standards Track [Page 26] RFC 3840 SIP Capabilities August 2004 セクション10のメディアフィーチャータグは、タグに記述されているユーザー またはユーザーエージェントに関する機密情報を明かすものである。フィー チャータグの一部には、エージェントに関する能力情報を伝達するものがあ る。たとえば、対応可能なメディアタイプ、対応可能なSIPメソッド、対応可 能なSIP拡張などである。能力情報は、たとえば産業スパイに使用される可能 性があるため、保護することが重要である。mobility、priority、isfocus属 性など、他の属性はユーザーエージェントの特性を明かすものである。これら の属性は能力情報よりも機密性が高い。これらは、ユーザーがユーザーエー ジェントをどのように利用しているかを説明するものなので、ユーザーが呼を 処理する際の優先順位と方法に関する情報を明かすことになる。languagesな ど、一部のフィーチャータグはユーザー自身の情報を明かす。したがって、こ れらのメディアフィーチャータグを利用するアプリケーションは、機密性 (confidentiality)を確保する手段を提供するべきである[SHOULD]。 メディアフィーチャータグは、アプリケーションの動作に影響を与える方法で 使用される可能性がある。たとえば、SIPの発呼側プリファレンス拡張(参考文 献[11])によって、これらのパラメータ値に基づいて、呼のルーティング判断 をすることができる。そのため、攻撃者がこれらのフィーチャータグの値を変 更できる場合、アプリケーションの動作に影響を与える可能性がある。した がって、これらのメディアフィーチャータグを利用するアプリケーションは、 整合性(integrity)を確保する手段を提供するべきである[SHOULD]。同様に、 メディアフィーチャータグは、フィーチャータグに記述されたユーザーまたは ユーザーエージェントが発信元である場合にのみ、有効なタグとして信頼され るべきである。以上を受けて、フィーチャータグを伝達する仕組みは、信頼性 (authenticity)を保証する仕組みを提供するべきである[SHOULD]。 11.2. 登録の考慮 セクション11.1に記載されている一般的な要件のように、メディアフィー チャータグが登録で伝達される場合、信頼性、機密性および整合性が提供され る必要がある。これを実現するために、能力情報を含む登録は、登録のあて先 をSIPS URIにして作成されるべきである[SHOULD](言い替えると、example.com ドメインの登録を作成する場合、リクエストのRequest-URIはsips:example. comになる)。さらに、レジストラは、信頼性を検証するために、TLS上のダイ ジェスト認証を使用してUAにチャレンジすべきである[SHOULD]。TLSとダイ ジェスト認証の組み合わせによって、必要な整合性、機密性、信頼性が提供さ れる。 登録のContact自体にSIPS URIを含む必要はない。これは、UAに送信される受 信リクエストでは、フィーチャータグが伝達されないためである。 Rosenberg, et al. Standards Track [Page 27] RFC 3840 SIP Capabilities August 2004 11.3. OPTIONS応答の考慮 OPTIONSリクエストに対する応答に能力に関する情報を含める場合、(ユーザー インターフェースまたは事前設定によって)能力情報がリクエスト側に公表 されるかどうかについて、UAはユーザーを検証すべきである[SHOULD]。リクエ スト側の身元を(ダイジェスト認証またはSIPアイデンティティ拡張(参考文献 [15])を使用して)暗号的に検証できない場合、ユーザーはそのことについて警 告され、また、こうした情報を公表するかどうか選択できるようにするべきで ある[SHOULD]。 ユーザーに能力情報をリクエスト側に明かす意思がなく、機密性を確保したい 一方で、SIPSを使用してリクエストが届かなかった場合、UASはリクエストを SIPS URIにリダイレクトすべきである。この結果、UACはOPTIONSリクエストを SIPSを使用して送信するため、セキュリティ保護された接続上で送信されるす べての応答について機密性が提供される。 さらに、OPTIONS応答でS/MIMEを使用してもよい[MAY]。この場合、能力情報 は、セキュリティ保護されたS/MIMEボディにのみ含まれ、OPTIONS応答のヘッ ダーフィールドには含まれない。 11.4. ダイアログ開始メッセージの考慮 UASがダイアログを開始する応答を生成し、Contactヘッダーフィールドに能力 情報を含めたい場合、セクション11.3に記載されているのと同じ事項が適用さ れる。 UACがダイアログを開始するリクエストを生成する場合、リクエストのContact ヘッダーフィールドに能力情報を含める前に、(ユーザーインターフェースま たは事前設定によって)ユーザーの許可を得るべきである[SHOULD]。情報の機 密性と整合性は、SIPSを使用して提供されるべきである[SHOULD]。S/MIMEを使 用してもよい[MAY]。 12. IANA条項 本仕様には関連するIANA条項が数多くある。 12.1. SIPメディアフィーチャータグの登録ツリー 本仕様には、RFC2506(参考文献[3])のセクション3.1.4に記載されているガイ ドラインに従って、新規のメディアフィーチャータグの登録ツリーを作成する 役割がある。このツリーの名称は「SIPメディアフィーチャータグ登録ツリー (SIP Media Feature Tag Registration Tree)」であり、接頭辞は「sip.」で Rosenberg, et al. Standards Track [Page 28] RFC 3840 SIP Capabilities August 2004 ある。これはセッション開始プロトコルに適用可能なメディアフィーチャータ グの登録のため使用され、この用途に限定して意味が定義される。 登録へのエントリ追加は、RFC2434(参考文献[18])で定義されているように、 IETFの合意によって行われる。エントリ追加には、登録を含むRFCの発行が 必要である。登録に必要な情報は、IETFツリーと同様である。従って、登録へ のエントリ追加の仕様には、RFC2506のセクション3.4で提供されているテンプ レートを使用するべきである。SIPツリーに登録されているすべてのメディア フィーチャータグには、名前に「sip.」という接頭辞が付くということに注意 すること。メディアフィーチャータグツリーの登録では、「+」は先頭に付か ない。 12.2. メディアフィーチャータグ 本仕様は、RFC2506(参考文献[3])の手順に基づき、多くのメディアフィー チャータグを登録する。登録はすべて、メディアフィーチャータグのために新 規に作成されたSIPツリーに作成される。登録は以下の通り。 sip.audio: sip.audioメディアフィーチャータグの登録情報は、セクション 10.1に記載されている。 sip.application: sip.applicationメディアフィーチャータグの登録情報は、 セクション10.2に記載されている。 sip.data: sip.dataメディアフィーチャータグの登録情報は、セクション10.3 に記載されている。 sip.control: sip.controlメディアフィーチャータグの登録情報は、セクショ ン10.4に記載されている。 sip.video: sip.videoメディアフィーチャータグの登録情報は、セクション 10.5に記載されている。 sip.text: sip.textメディアフィーチャータグの登録情報は、セクション10.6 に記載されている。 sip.automata: sip.automataメディアフィーチャータグの登録情報は、セク ション10.7に記載されている。 sip.class: sip.classメディアフィーチャータグの登録情報は、セクション 10.8に記載されている。 sip.duplex: sip.duplexメディアフィーチャータグの登録情報は、セクション 10.9に記載されている。 Rosenberg, et al. Standards Track [Page 29] RFC 3840 SIP Capabilities August 2004 sip.mobility: sip.mobilityメディアフィーチャータグの登録情報は、セク ション10.10に記載されている。 sip.description: sip.descriptionメディアフィーチャータグの登録情報は、 セクション10.11に記載されている。 sip.events: sip.eventsメディアフィーチャータグの登録情報は、セクション 10.12に記載されている。 sip.priority: sip.priorityメディアフィーチャータグの登録情報は、セク ション10.13に記載されている。 sip.methods: sip.methodsメディアフィーチャータグの登録情報は、セクショ ン10.14に記載されている。 sip.extensions: sip.extensionsメディアフィーチャータグの登録情報は、セ クション10.15に記載されている。 sip.schemes: sip.schemesメディアフィーチャータグの登録情報は、セクショ ン10.16に記載されている。 sip.actor: sip.actorメディアフィーチャータグの登録情報は、セクション 10.17に記載されている。 sip.isfocus: sip.isfocusメディアフィーチャータグの登録情報は、セクショ ン10.18に記載されている。 12.3. SIPオプションタグ 本仕様は1個のSIPオプションタグ「pref」を登録する。この登録に必要な情報 は、RFC3261(参考文献[1])に規定されているが、以下の通りである。 名前: pref 説明: このオプションタグは、レジストラが確実に発呼側プリファレンス に対応するように、登録のRequireヘッダーフィールドで使用される。 13. 謝辞 本仕様で使われているメディアフィーチャータグの初期セットは、 ScotPetrackのCMA設計に影響を受けた。Jonathan Lennox、Bob Penfield、 BenCampbell、Mary Barnes、Rohan Mahy、John Heartyの各氏から有益なコメ ントをいただいた。RFC2533の用法についてGraham Klyne氏に援助していただ いた。Allison Mankin氏のコメントと助力、Ted Hardie氏のメディアフィー チャータグ用法に関する指導に感謝を述べたい。 Rosenberg, et al. Standards Track [Page 30] RFC 3840 SIP Capabilities August 2004 14. 参考文献 14.1. 規範となる参考文献 [1] 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. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999. [4] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999. [5] Klyne, G., "Corrections to "A Syntax for Describing Media Feature Sets"", RFC 2738, December 1999. [6] Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, November 2000. [7] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000. [8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [9] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 14.2. 有益な参考文献 [11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [12] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004. Rosenberg, et al. Standards Track [Page 31] RFC 3840 SIP Capabilities August 2004 [13] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, May 2003. [14] Howes, T. and M. Smith, "LDAP: String Representation of Search Filters", Work in Progress, March 2003. [15] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, March 2003. [16] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [17] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999. [18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Rosenberg, et al. Standards Track [Page 32] RFC 3840 SIP Capabilities August 2004 付録A. RFC2533の概要 このセクションでは、コンテンツのネゴシエーションフレームワークを構築す る、RFC2533と関連する仕様について概要を説明する。このセクションの内容 は、規範的な動作ではない。このチュートリアル資料とRFC2533の規範が衝突 する場合は、RFC2533の方が優先される。 このフレームワークの重要な概念は、フィーチャーセットである。フィー チャーセットは、エンティティ(本書の場合はUA)に関する情報であり、処理可 能なフィーチャー(機能)のセットを表す。フィーチャーセットは、N次元空間 の領域と考えることができる。この空間の各次元は、異なるメディアフィー チャーであり、メディアフィーチャータグで識別される。たとえば、ある次元 (または軸)は言語を示し、別の次元はメソッドを示し、また別の次元はMIMEタ イプを示す場合がある。フィーチャーコレクションは、この空間の1点を示 す。また、エンティティ(本書の場合はUA)の特定のレンダリングまたはインス タンスを示す。たとえば、UAの「レンダリング」によって、UAがサポートでき る即時の操作様式が定義される。このようなレンダリングによって、INVITEメ ソッド(application/sdp MIMEタイプを伝達)が処理され、英語を話せるユー ザーのUAに送信される。 したがって、フィーチャーセットは、フィーチャーコレクションのセットと定 義できる。言い替えると、フィーチャーセットは、N次元のフィーチャー空間 の1領域であり、その領域は、空間を構築する点(フィーチャーコレクション) のセットによって定義される。特定のフィーチャーコレクションが空間にある 場合、そのフィーチャーコレクションによって表されるレンダリングは、その フィーチャーセットを使用するデバイスでサポートされる、ということを意味 する。 フィーチャーセットを表す方法を説明する。N次元空間を表す方法は数多くあ る。たとえば、数学関数を指定して輪郭(contour)を特定する方法である。明 らかにこれは複雑すぎて便利ではない。RFC2533で取られた解決策は、フィー チャーセット述部を使用して空間を定義する方法である。フィーチャー述部に よって、N次元空間上の関係性を定義する。入力は、その空間(つまりフィー チャーコレクション)にある任意の点であり、領域内にあり、したがって定義 済みであるすべての点について真である。 RFC2533では、このN次元のブール型関数を記述した構文が説明されている。こ れは、LDAP(参考文献[14])から取り入れたものである。ここでは、非常にわか りやすいprolog型の構文を使用している。この表現は、フィーチャーセット述 部と呼ばれる。述部の基本単位はフィルタであり、丸かっこで囲まれるブール Rosenberg, et al. Standards Track [Page 33] RFC 3840 SIP Capabilities August 2004 型の式である。他のフィルタの論理積と論理和が含まれる場合は、フィルタが 複雑になる可能性はあるが、そうでなければ単純になる。シンプルフィルタ は、1つのメディアフィーチャータグで比較演算子を表すものである。 たとえば、以下のようなフィーチャーセット述部がある。 (& (foo=A) (bar=B) (| (baz=C) (& (baz=D) (bif=E)))) これによって、foo、bar、baz、bifという4つのメディアフィーチャーに関す る機能が定義される。fooイコールA、barイコールB、bazイコールCまたはD、 bifイコールEという条件をすべて満たすフィーチャー空間の点は、すべてこの フィーチャーセット述部で定義されるフィーチャーセットに含まれる。 述部では、フィーチャー空間の次元数については何も示していないことに注 意。述部は、任意の次元数のフィーチャー空間で機能するが、foo、bar、 baz、bifと名付けられた次元のフィーチャー空間でのみ機能する。したがっ て、他のメディアフィーチャーの値は重要ではない。フィーチャーコレクショ ン {foo=A,bar=B,baz=C,bop=F} は、メディアフィーチャータグ「bop」に触れ ていなくても、述部で記述されるフィーチャーセットに含まれる。したがっ て、フィーチャーセット述部は、デフォルトですべてを含んでいる。フィー チャーコレクションは、ブール型述部で除外されていなければ、存在する。こ れは、RFC2533の意図的な設計選択である。 RFC2533にも、プリファレンスと能力セットのマッチングについて書かれてい る。これは、2つをフィーチャーセットで示すことで実現する。プリファレン スは、フィーチャーセットである。プリファレンスは、多数のフィーチャーコ レクションの仕様であり、そのすべてが送信者の要件を満たす。能力もフィー チャーセットである。能力は、受信者が対応するフィーチャーコレクションの 仕様である。双方のフィーチャーセットで定義される空間が重複する場合、 マッチングが存在する。重複する場合、両フィーチャーセットに存在する フィーチャーコレクションが1つ以上ある。つまり、送信者が希望し、受信者 が対応する、様式またはレンダリングが存在する。 これは、マッチングの定義に直接結びつく。両フィーチャーセットに存在する フィーチャーコレクションが1つ以上ある場合、2つのフィーチャーセットは マッチする。 2つの一般的なフィーチャーセット述部のマッチングを算出するのは、容易で はない。RFC2533のセクション5では、任意の式を論理積標準系 (disjunctive normal form)に拡張することで算出するアルゴリズムについて 説明している。ただし、本仕様で使用するフィーチャーセット述部は、制約が ある。本仕様のフィーチャーセット述部は、異なるメディアフィーチャーの値 を記述する論理積に各項がある、常に論理積標準系である。そのため、マッチ Rosenberg, et al. Standards Track [Page 34] RFC 3840 SIP Capabilities August 2004 ングの算出は簡単になる。各メディアフィーチャーで独立してマッチングを算 出し、両フィーチャーセットで指定されているメディアフィーチャーが重複す れば、2つのフィーチャーセットは重複する。1つのメディアフィーチャーの重 複を算出することは非常に簡単であり、2つの有限なセットが重複するかどう かを算出する単純な問題となる。 著者の連絡先 Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue BXB500 C2-2 Boxboro, MA 01719 US EMail: pkyzivat@cisco.com Rosenberg, et al. Standards Track [Page 35] RFC 3840 SIP Capabilities August 2004 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP78に含まれる権 利、ライセンス、制限の対象となり、BCP78に記載されている例外に従い、著 者はすべての権利を持つ。 本文書と含まれる情報は、「保証なし(AS IS)」原則で提供される。また、寄 稿者、寄稿者が代表する組織、または(存在する場合)寄稿者のスポンサーであ る組織、インターネット協会(Internet Society)およびIETF(Internet Engineering Task Force)は、本書の情報の使用が、特定用途に関する商品適 格性または適合性の何らかの権利または暗示される保証を侵害しない、という 保証をはじめとして、すべての保証(明示または暗示)を放棄する。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書に関する手順の情報は、BCP78とBCP79を参照のこと。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、本規格の実装に必要になる可能性がある技術の範囲に及ぶ可能性があ る、任意の著作権、特許、特許アプリケーション、その他の所有権への配慮 を、関係者に依頼している。情報については、IETFの ietf-ipr@ietf.org ま で連絡されたい。 謝辞 RFC編集者職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2004年 ----------------------------------------------------------------------- Rosenberg, et al. Standards Track [Page 36]