Network Working Group J. Rosenberg Request for Comments: 4485 Cisco Systems Category: Informational H. Schulzrinne Columbia University May 2006 セッション開始プロトコル(SIP)拡張の 著者に関するガイドライン Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティに情報を提供するためのものであ る。いかなるインターネット標準も規定しない。本文書の配信は無制限で ある。 著作権表記 Copyright (C) The Internet Society (2006). 概要 セッション開始プロトコル(Session Initiation Protocol/SIP)は、インター ネット全体の双方向通信セッションを確立するための柔軟だがシンプルな ツールである。この柔軟性の要素として、拡張が容易な点がある。効率的で 相互運用可能なSIP拡張を促進するために、SIP拡張を開発する際にいくつか のガイドラインに従う必要がある。本文書では、SIP拡張の著者向けにこの ようなガイドラインを概説する。 Rosenberg & Schulzrinne Informational [Page 1] RFC 4485 SIP Guidelines May 2006 目次 1. はじめに ....................................................... 2 2. 用語 ........................................................... 3 3. SIP拡張を定義すべきか ......................................... 3 3.1. SIPの解決策空間 ........................................... 4 3.2. SIPアーキテクチャモデル ................................... 5 4. 対応する必要がある問題 ......................................... 7 4.1. 下位互換性 ............................................... 7 4.2. セキュリティ ............................................ 10 4.3. 用語 .................................................... 10 4.4. 構文上の問題 ............................................ 10 4.5. セマンティクス、セマンティクス、セマンティクス .......... 13 4.6. 例のセクション .......................................... 14 4.7. 概要のセクション ........................................ 14 4.8. IANA条項のセクション .................................... 14 4.9. 文書命名の規則 .......................................... 16 4.10. 新規メソッドに関するその他の考慮事項 .................... 16 4.11. 新規ヘッダーフィールドに関するその他の考慮事項 .......... 17 4.12. 新規ボディタイプに関するその他の考慮事項 ................ 18 5. SIP機能との相互作用 .......................................... 18 6. セキュリティの考慮事項 ........................................ 19 7. 謝辞 .......................................................... 19 8. 参考文献 ...................................................... 19 8.1. 規範となる参考文献 ...................................... 19 8.2. 有益な参考文献 .......................................... 20 1. はじめに セッション開始プロトコル(Session Initiation Protocol/SIP) [2]は、イン ターネット全体の双方向通信セッションを確立するための柔軟だがシンプル なツールである。この柔軟性の要素として、(新規メソッド、新規ヘッダー フィールド、新規ボディタイプ、新規パラメータの)拡張が容易な点がある。 また、単に拡張するための提案が無数にあった。また、SIPプロトコルの拡 張を作成する方法について定義したIETF処理が導入された[10]。 この処理の目的は、(他のプロトコルではなく)SIPに適した拡張が作成され ること、SIPが提供するモデルとフレームワーク内に拡張が適合しSIPの運用 と矛盾がないこと、拡張が特定の使用例ではなく問題を一般的に解決するこ とである。ただし、この処理に役立つ技術的ガイドラインを[10]は提供して いない。本仕様は、この要件を満たすために寄与する。 本仕様では、まず最初に、機能の特定部分をSIPで実行するのが適当かどう かを決定する際に役立つガイドライン群を提供する。機能が適切と仮定され たら、拡張の仕様内で対処すべきである問題を指摘する。最後に、既存の Rosenberg & Schulzrinne Informational [Page 2] RFC 4485 SIP Guidelines May 2006 SIP機能との一般的な相互作用について論じる(それによって拡張が困難にな ることがよくある)。 2. 用語 本文書では、以下のキーワードはRFC 2119 [1]の記述に従って解釈されるべ きであり、準拠する実装に対する要求レベルを示すものである。「MUST」、 「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、 「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」 3. SIP拡張を定義すべきか SIP拡張を定義する際に対処する必要がある最初の問題は、その問題解決に SIP拡張が最適なのかどうか、という点である。SIPは、モビリティ、構成と 管理、QoS制御、呼制御、発呼側プリファレンス、デバイス制御、サード パーティ呼制御、MPLSパスセットアップなど、多数の問題に対する1つの解 決策として提案された。明らかなことだが、すべての問題が1つのSIP拡張で 解決できるわけではない。さらに重要なことは、1つのSIP拡張でいくつかの 問題を解決できても、解決すべきではない場合があるということである。 SIP拡張がその問題に対する適切な解決策かどうかを技術者が判断する際の 一助となるように、本文書では2つの広範な基準を提示する。 第一に、問題は、SIPの解決策空間の一般的な範囲に適合すべきである [SHOULD]。第二に、解決策は一般的なSIPアーキテクチャモデルに準拠しな ければならない[MUST]。 第一基準は明白なようだが、SIPも話すデバイスで何らかの機能が必要だと いう理由で、多数のSIP拡張が提案されてきたと我々は気づいた。一般的に、 「多数のプロトコルより1つのプロトコルを実装したい」ということが論じ られる。 たとえば、他のすべてのIPホストと同様に、ユーザーエージェントには自身 のIPアドレスを取得する何らかの方法が必要である。この処理は一般的に DHCP [11]を使用して行われる。 SIPのマルチキャスト登録メカニズムは、IPアドレスを取得する代替的な方 法を提供する可能性がある。これによって、クライアントにDHCPの必要性が なくなる。ただし、本文書ではこのような拡張を適切とは考えない。 また、1組のデバイス間に必要なすべてのプロトコルについて定義するので はなく、特定の狭い範囲の機能を提供するためにプロトコルを定義すべきで あると考える。プロトコル設計に対する前者のアプローチは、応用が広範な モジュラープロトコルを生み出す。また、拡張性と発展も促進される。とい うのも、単一のプロトコルは、全体のプロトコルに影響を及ぼすことなく、 削除および変更することができるためである。プロトコル設計に対するこの アプローチは、オブジェクト指向のソフトウェア設計に酷似していること に我々は気づいた。 拡張は一般的なSIPアーキテクチャモデルに準拠しなければならないという 第二基準によって、プロトコルの管理性と広範な適用可能性が保たれる。 Rosenberg & Schulzrinne Informational [Page 3] RFC 4485 SIP Guidelines May 2006 3.1. SIPの解決策空間 第一基準を評価するために、SIPの解決策空間に含まれるものと含まれないも のを正確に定義する必要がある。 SIPは、双方向セッションを開始、変更、および停止するためのプロトコル である。この処理には、どこにいるかわからないユーザー(または、より一 般的に言うと、音声メールや翻訳デバイスなどのサービスを含め、通信可能 なエンティティ)の発見を伴う。そのため、セッションの説明をユーザーに 配信できる。このようなユーザーまたは通信エンティティは移動し、また時 間が経てばネットワークへの接続ポイントも変わると想定されている。SIP の主な目的はランデブー機能である。この機能によって、リクエストの開始 者は何らかのメッセージを受信者に配信できるようになる。こうしたラン デブーは、セッションの確立に必要だが、通信に関連する他の目的にも使用 できる。たとえば、能力の照会やインスタントメッセージの配信などであ る。 SIPの大部分は、こうした発見とランデブーの構成要素を中心に取り組んで いる。分岐する機能、登録機能、ルーティング機能はいずれも、どこにいる かわからない目的のユーザーを見つけるという1つの目的のために存在して いる。したがって、個人のモビリティ、自動通話配信、follow-meなどの特 性や機能は、SIPの解決策空間内に含まれる。 また、セッションの開始は、通話に参加するかどうかを判断するための、 セッションに関する十分な情報を着呼側パーティの機能が持っているかどう かに左右される。この情報には、発呼側に関するデータ、招待の目的、セッ ション自体のパラメータが含まれる。 この理由から、SIPはこのような種類の情報を含める。 セッション開始処理の一部として、進捗の通信と、セッション確立の最終的 な結果がある。SIPはこの情報も提供する。 SIP自体はセッションから独立しており、セッション記述はSIPメッセージ内 で不透明なボディとして配信される。開始および終了するセッションとSIP を独立させておくことは基礎である。したがって、SIPが明示的に提供しな い機能が多数ある。SIPはセッション管理プロトコルでもカンファレンス制 御プロトコルでもない。セッション内の通信の詳細は、SIPの範囲外であ る。これには、メディアトランスポート、投票や世論調査、仮想的なマイク の手渡し、議長選挙、フロア制御、セッション品質に関するフィードバック などの機能が含まれる。 SIPはセッションのリソース予約プロトコルではない。この根本的な理由は、 Rosenberg & Schulzrinne Informational [Page 4] RFC 4485 SIP Guidelines May 2006 (1) SIPは確立する基礎のセッションから独立しており、(2) SIPメッセージ のパスはセッションパケットが使用するパスとは完全に独立しているためで ある。パスの独立性とは、プロバイダネットワーク内および複数のプロバイ ダ群内のパスを指す。たとえば、SIPメッセージが、SIPが確立したセッショ ンの音声とはまったく異なる自立的システム群を経由することは完全に理に かなっている。 SIPは汎用的な転送プロトコルではない。また、SIP操作に関係がない大量の データを送信することは意図されていない。HTTPを置き換えることも意図さ れていない。SIPメッセージでペイロードを伝送することは常に良いことで はない、と言うつもりはない。多くの場合、データはSIP操作に非常に関連 性があるためである。このような場合、エンドツーエンドの輻輳制御された 伝送が重要である。 SIPを一般的なRemote Procedure Call (RPC)メカニズムにすることは意図さ れていない。SIPのユーザー検出機能と登録機能のいずれも、RPCには不要で あり、多くの場合、いずれもプロキシ機能である。 SIPは、厳密な公衆電話交換回線網(Public Switched Telephone Network/ PSTN)シグナリングの置き換えとして使用されることは意図されていない。 また、統合サービスデジタルネットワークユーザー部(Integrated Services Digital Network(ISDN) User Part (ISUP))の上位集合ではない。 PSTNシグナリングのゲートウェイ処理に対応し、PSTNで提示される多数の機 能を提供する可能性はあるが、PSTNに特性または機能があまりないことは、 SIPに含めることの正当性にはならない。電話に対応する必要がある拡張は、 本文書で説明する他の基準に対応しなければならない[MUST]。 SIPは弱い制御プロトコルである。SIPは、あるエンティティが他者に電話に 応答するように伝えるため、特定のコーディングを使用して音声を送信する ため、または設定パラメータに新しい値を設定するために使用されることは 意図されていない。制御プロトコルには、SIPで想定されているものとは異 なる信頼関係があり、アーキテクチャ内でSIPよりも集権的に管理されて いる。これは、SIPが非常に分散性が高いプロトコルのためである。 SIP機能の作成に必要なネットワーク層サービスは多数ある。 たとえば、サービス品質、モビリティ、セキュリティなどである。このよう な機能をSIP自体に組み込むのではなく、SIPの範囲外で開発し、使用すべき である[SHOULD]。 特に、SIPにも必要だが、他の多くのアプリケーション層プロトコルにも必 要なプロトコルメカニズムは、SIP内で対処すべきではない[SHOULD NOT]。 3.2. SIPアーキテクチャモデル ここでは、SIPの基礎となる主要なアーキテクチャ上の前提についていくつ か説明する。この前提条件に反する拡張は、SIPへの妥当性を判断するため に、より注意深く確認すべきである。 Rosenberg & Schulzrinne Informational [Page 5] RFC 4485 SIP Guidelines May 2006 セッションの独立性: SIPは確立したセッションからは独立している。これ には、音声、ビデオ、ゲーム、チャットセッション、仮想現実など、セッ ションの種類が含まれる。SIP操作は、セッションの何らかの特性に依存 すべきではない[SHOULD NOT]。SIPは音声のみに特化したものではない。 すべてのSIP拡張は、多様なセッションの種類に対するSIPの応用を考慮 しなければならない[MUST。 SIPとセッションパスの独立性: 前述したことだが、繰り返し言及する価値 はある。SIPメッセージが経由する一連のルーター、ネットワーク、自立 システムは、セッションパッケージが経由する一連のルーター、ネット ワーク、自立システムとは関係がない。場合によっては同じ可能性もあ るが、同じである必要はない、というのがSIPアーキテクチャの基礎で ある。シグナリングとセッションパスを一対にしたときにのみ機能する 標準化過程の拡張は定義してはならない[MUST NOT]。このような場合に のみ機能する拡張には、非標準のP-header拡張[10]が必要である。 マルチプロバイダとマルチホップ: SIPはメッセージがインターネットを経 由すると想定している。つまり、異なるプロバイダが管理する複数の ネットワークを経由してSIPは機能する。また、SIPメッセージは多数の ホップ(各ホップはプロキシ)を経由することも想定されている。 単一のホップまたは特化したネットワークトポロジーの想定のみの拡張 は、機能してはならない[MUST NOT]。単一のSIPプロバイダの想定は回避 すべきである[SHOULD](ただし、RFC 3427 [10]に従って、P-Headersの用 法を参照のこと)。 トランザクション性: SIPはリクエスト/応答プロトコルであり、恐らく中間 の応答で強化される。SIP操作の規則の多くは、リクエストと応答の全般 的な処理に基づいている。 これには信頼性メカニズム、ルーティングメカニズム、ステート維持規 則などが含まれる。拡張は、リクエスト-応答モデル内に含まれないメッ セージを追加すべきではない[SHOULD NOT]。 プロキシはボディを無視できる: プロキシの拡張性のために、最小限のメッ セージ処理で操作できる必要がある。SIPは、プロキシが常にボディを無 視できるように設計されてきた。 プロキシがボディを確認することを拡張が要求すべきではない[SHOULD NOT]。 プロキシはメソッドを理解する必要はない: プロキシのリクエスト処理はメ ソッドに依存しない。ただし、よく知られたメソッドのINVITE、ACK、 CANCELは例外である。これによって拡張性が見込まれる。プロキシが理 解する必要がある新規メソッドを拡張が定義してはならない[MUST NOT]。 Rosenberg & Schulzrinne Informational [Page 6] RFC 4485 SIP Guidelines May 2006 INVITEメッセージは完全なステートを伝達する: あるセッションに関する最初 のINVITEメッセージは、セッションの何らかの特性を変更するre-INVITE メッセージとほぼ同じである(例外はタグである)。この完全なステートの プロパティはSIPの基礎であり、SIPシステムの堅牢性に欠かせない。拡張 は、何らかの機能を実行するために複数のINVITEにまたがるデータを収 集するよう、INVITE処理を変更すべきではない[SHOULD NOT]。 汎用性は効率性より優先される: 可能な限り、狭い用途のコンポーネントよ りも汎用的なコンポーネントをSIPは優先してきた。あるサービスに対応 する機能が追加されるが、(複雑さやメッセージサイズを犠牲にして)や や広範な機能でより多様なサービスに対応できる場合、より広範な機能 の方を優先すべきである[SHOULD]。 Request-URIは転送の主要な鍵である: SIPサーバーにおけるロジックの転 送は、主にRequest-URIに依存する(これはSIPのリクエストルーティング とは異なる。リクエストルーティングでは、Routeヘッダーフィールドを 使用して中間プロキシ経由でリクエストを渡す)。Request-URI (通常の 操作では目的の受信者を解決する)がリソースを示すということは、SIP 操作の基礎である。拡張はRequest-URIのセマンティクスを変更すべきで はない[SHOULD NOT]。 多様性は規範である: SIPは多様なデバイスに対応している。SIPには、重複 するプロトコル機能群を決定するための組み込みメカニズムがある。す べてのデバイスがその拡張に対応する場合にのみ機能する拡張は、定義 すべきではない[SHOULD NOT]。 4. 対応する必要がある問題 前のセクションに記載したリトマス試験に拡張が合格した場合でも、すべて の拡張が考慮に入れるべき問題がいくつかある。 4.1. 下位互換性 考慮すべき最も重要な問題の1つは、新しい拡張が基礎のSIPと下位互換性が あるかどうかという点である。これは、Require、Proxy-Require、Supported ヘッダーフィールドの使用方法と密接に関係がある。 既存のメソッドを使用したリクエストにユーザーエージェントが挿入する新 規ヘッダーフィールドまたはヘッダーフィールドパラメータで拡張が構成さ れ、そのヘッダーフィールドまたはパラメータを理解しないプロキシまたは ユーザーエージェントがそのリクエストを適切に処理できない場合、拡張は リクエストにRequireまたはProxy-Requireヘッダーフィールドを使用するこ とを必須としなければならない[MUST]。このような拡張はSIPと下位互換性 Rosenberg & Schulzrinne Informational [Page 7] RFC 4485 SIP Guidelines May 2006 はない。こうしたヘッダーフィールドの使用を必須とする結果は、その拡張 も理解するエンティティとの通信でなければ、リクエストをサービスできな いことを意味する。一部のエンティティが拡張を理解しない場合、リクエス トは拒否される。UACはこの問題を2つの方法で処理できる。第一に、リクエ ストを単に失敗する方法である。この場合、サービスは提供できない。 これは基本的に相互運用エラーである。第二に、UACが拡張なしでリクエス トを再試行する方法がある。これによって相互運用性は保たれるが、UACの 「デュアルスタック」実装(拡張ありの操作となしの操作を考慮した処理規 則)は犠牲になる。拡張の数が増えるにしたがって、UACが実装する必要があ る処理規則の数は指数関数的に増大する。その結果、過度に複雑さが増す。 RequireとProxy-Requireの使用によって相互運用性と複雑さの問題が生じる 可能性があるため、本文書では以下のガイドラインが適切と考える。 o 基本的なSIPサービスのリクエスト(特に、セッションの開始と終了)にこ のようなヘッダーフィールドを使用することは推奨されない [NOT RECOMMENDED]。特定の拡張がリクエストで必須とされる頻度が少な くなるほど、そのヘッダーフィールドを使用することは妥当性が高まる。 o Proxy-Requireヘッダーフィールドはどのような犠牲を払っても回避すべ きである[SHOULD]。 個々のプロキシが失敗する可能性は一定だが、パスが失敗する可能性は ホップ数に比例して増加する。一方、Requireヘッダーフィールドは、単 一のエンティティであるUASがその拡張に対応することのみを必須とす る。したがって、Proxy-Requireの使用は、Requireヘッダーフィールド の使用よりも遙かに悪いと考えられる。 o 拡張でRequireまたはProxy-Requireを使用する場合、リクエストが420応 答で拒否されたときに基礎のSIP操作に戻る方法についてその拡張は論じ るべきである[SHOULD]。 新規メソッドを定義する拡張は、Requireヘッダーフィールドを使用する必要 はない。SIPは、新規メソッドをUASが理解しているかどうかをUACが知るこ とができるメカニズムを定義している。これには、OPTIONSリクエストと、 Allowヘッダーフィールドでの405 (Method Not Allowed)応答が含まれる。 プロキシは新規メソッドを処理するためにそのメソッドのセマンティクスを 理解する必要はない、というのはSIPの基礎である。プロキシが処理するに は理解する必要がある新規メソッドを拡張が定義する場合、Proxy-Require ヘッダーフィールドが必要である。前述したように、この種の拡張は推奨さ れない。 新規メソッドを定義する拡張の下位互換性を達成するために、Allowヘッ ダーフィールドが使用される。新規メソッドには2つの種類がある。1つは確 Rosenberg & Schulzrinne Informational [Page 8] RFC 4485 SIP Guidelines May 2006 立したダイアログに使用するもの(たとえば、INVITEで開始されたダイアロ グ)、もう1つは、最初のリクエストとしてUAに送信されたものである。 INVITEとその応答はどちにもAllowヘッダーフィールドを含めるべきなので [SHOULD]、UAは、そのダイアログ内で新規メソッドに対応できるかどうかを 容易に判断できる。たとえば、INVITEダイアログが確立されると、ユー ザーエージェントは、Allowヘッダーフィールドで提示されていることで REFERメソッド[12]に対応しているかどうかを判断できる。対応していな かった場合、呼の確立後に、UIの「転送」ボタンを「淡色表示」することが できる。 もう1種類の拡張は、ネットワークを経由するときにリクエストにヘッダー フィールドまたはヘッダーフィールドパラメータを挿入することをプロキシ に要求するもの、またはヘッダーフィールドまたはヘッダーフィールドパラ メータを応答に挿入することをUASに要求するものである。拡張によっては、 UACまたはUASがそのようなヘッダーフィールドを理解しない場合でも、メッ セージを正しく処理できることがある。このような拡張は完全に下位互換性 がある。 その他、このような種類の拡張のほとんどは、クライアントが理解している と確認できる場合にのみヘッダーフィールドまたはパラメータをサーバーが 挿入することを必須としている。この場合、その拡張は、Supportedリクエ ストヘッダーフィールドのメカニズムを利用する必要がある。このメカニズ ムによって、サーバーはクライアントが何らかの拡張を理解しているかどう かを判断できる。その結果、拡張を応答に適用することができる。この性質 から、拡張は常にすべての応答に適用できるわけではない。 正しく実行するために、プロキシがヘッダーフィールドまたはパラメータに 挿入すること、およびUACとUASの両方がヘッダーフィールドとパラメータを 理解する必要があることを拡張が必須とする場合、RequireとSupportedメカ ニズムの組み合わせを使用する必要がある。Supportedヘッダーフィールド が存在する場合、プロキシはRequireヘッダーフィールドをリクエストに挿 入できる。このような拡張の例として、SIPセッションタイマー[13]がある。 さらにもう1種類の拡張として、SIPメッセージで伝達する新規ボディタイプ を定義するものがある。SIP仕様に従うと、リクエストを処理するにはユー ザーエージェントがボディを理解する必要がある。したがって、相互運用性 の問題は新規メソッドの場合と似ている。ただし、クライアントまたはサー バーがメッセージボディがオプションであることを示すことができる、 Content-Dispositionヘッダーフィールドが定義された[2]。新規ボディタイ プを定義する拡張または必要とする拡張は、ユーザーエージェントが処理す る上でそのタイプをオプションとすべきである[SHOULD]。 リクエストまたは応答を正しく処理するためにボディを理解する必要がある 場合、受信側が新規ボディを理解しているかどうかを、前もって送信側エン ティティが知っていることが望ましい。ダイアログを確立するリクエストの 場合、リクエストとその成功応答にAcceptを含めることが推奨される Rosenberg & Schulzrinne Informational [Page 9] RFC 4485 SIP Guidelines May 2006 [RECOMMENDED]。こうすることで、双方のパーティは、相手側が対応してい るボディタイプを判断することができる。その相手との以降のメッセージ処 理には、理解されていると示されたボディタイプのみが含まれる。 4.2. セキュリティ セキュリティはどのプロトコルでも重要な要素の1つである。SIP拡張の設計 者は、RFC 3261に記載されている以外に追加のセキュリティ要件が必要かど うかを慎重に考慮する必要がある。 よくあることだが、認可要件とエンドツーエンドの完全性要件が最も見落と される。 SIP拡張は、一般的なSIPセキュリティメカニズムの使用に与える影響(または 影響があるかどうか)を考慮しなければならない[MUST]。ほとんどの拡張は、 汎用的なSIPの範囲を超える新規のセキュリティ機能は必要とすべきではな い。必要な場合、セキュリティメカニズムにはより汎用的な応用があり、独 自の権限で拡張を考慮すべきである可能性が高い。 全体的なシステムセキュリティでは、確立したSIPシグナリングとメディア セッションの両方をセキュリティで保護する必要がある。メディアセッショ ンは一般的に独自のセキュリティ技術を使用する。これはSIP自体が使用す るセキュリティ技術とはまったく異なる。拡張はこれら2つを結び付けない よう注意すべきである。ただし、何らかの方法でメディアセッションに影響 を及ぼす拡張を定義する仕様では、SIPとセッションセキュリティメカニズ ム間の相互作用について考慮すべきである[SHOULD]。 4.3. 用語 RFC 3261には、発呼側、着呼側、ユーザーエージェント、ヘッダーフィール ドなどの用語を定義した長文の用語セクションがある。すべてのSIP拡張は この用語に準拠しなければならない[MUST]。他のSIP仕様の用語ですでに定 義されている概念を説明するために、SIP拡張で新しい用語を定義してはな らない[MUST NOT]。新規用語が必要な場合、文書の最初の方で個別のセク ションに記載すべきである[SHOULD]。 用語の実際の使用については注意する必要がある。 たとえば、多くの文書は、ヘッダー、ヘッダーフィールド、ヘッダーフィー ルド値を誤用している。著者は、用語の正しい使用について、文書を注意し て読み直すべきである[SHOULD]。 4.4. 構文上の問題 新規メソッドを定義する拡張は、メソッド名にすべて大文字を使用すべきで ある[SHOULD]。メソッド名は10文字未満にすべきである[SHOULD]。またリク エストの一般的な意味を伝えるよう心がけるべきである[SHOULD]。メソッド 名は大文字と小文字が区別されるため、厳密には大文字にする必要はない。 Rosenberg & Schulzrinne Informational [Page 10] RFC 4485 SIP Guidelines May 2006 ただし、大文字にしたメソッド名を使用することで、SIPや他の類似プロト コル(HTTP [15]やRTSP [16]など)の長年にわたって続いている規約が維持さ れる。 多用が予想される新規ヘッダーフィールドを定義する拡張は、そのヘッダー フィールドが7文字以上になる場合、短縮形を定義してもよい[MAY]。 「多用」とは、すべての発行メッセージのうち、そのヘッダーフィールドを 含むメッセージの占める割合が30%を超えることを意味する。このような場 合に短縮形を使用することが単に「してもよい[MAY]」なのは、メッセージ のオーバーヘッドを削除できるより優れたアプローチがあるためである [20]。短縮形のヘッダーフィールドは1文字にしなければならない[MUST]。 26文字すべてが使用された場合、新規の短縮形は定義できない。ヘッダー フィールド名は、RFC 3261セクション25.1に記載されている「トークン」の 作成によって定義される。したがって、大文字、小文字、0〜9の数字、 HYPHEN-MINUS (-)、FULL STOP (.)、EXCLAMATION MARK (!)、PERCENT SIGN (%)、ASTERISK (*)、LOW LINE (_)、PLUS SIGN (+)、GRAVE ACCENT (`)、 APOSTROPHE (')、TILDE (~)が含まれる。ヘッダーフィールド名は内容がわ かるように、かつ適度に短くすべきである[SHOULD]。ヘッダーフィールド名 は大文字と小文字を区別しないが、文書内では1文字の一般的な大文字化を 使用すべきである[SHOULD]。ヘッダーフィールド名に記載する各英単語は1 文字目を大文字にすることが推奨される。たとえば、「ThisIsANewHeader」 である。 一例を挙げると、以下はヘッダーフィールド名として悪い選択例である。 ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName --.!A Function パラメータと値の大文字と小文字の区別は、常に混乱の元であり、RFC 2543 [17]を悩ませる問題でもある。この問題は、RFC 4234 [5]のBNF構成の使用 によって単純になった。RFC 4234には、大文字と小文字の区別と非区別につ いて明確な規則がある。 したがって、拡張のBNFは、マッチング規則を完全に定義している。 拡張は、大文字と小文字の区別についてSIP規約に準拠しなければならな い[MUST]。メソッドは大文字と小文字を区別しなければならない[MUST]。 ヘッダーフィールド名は大文字と小文字を区別してはならない[MUST]。 ヘッダーフィールドパラメータ名は大文字と小文字を区別してはならな い[MUST]。ヘッダーフィールド値とパラメータ値は、大文字と小文字が区別 されることもあるが、区別されないこともある。ただし、一般的には大文字 と小文字を区別すべきではない[SHOULD]。大文字と小文字を区別するコン ポーネントを定義するには、各文字をASCIIコードで明示的に列挙する必要 がある。 自由形式のテキストを含む拡張は、文字セットの使用に関するIETFのポリ シー[3]に従って、UTF-8のテキストを許容しなければならない[MUST]。これ によって、SIPが国際的な標準のまま維持される。一般的なガイドラインと して、プログラムでプロトコル処理を実行するために、自由形式のテキスト が必要になることはない。一般的に、このようなテキストはユーザーが入力 Rosenberg & Schulzrinne Informational [Page 11] RFC 4485 SIP Guidelines May 2006 し、ユーザーに表示するものである。拡張がUTF-8エンコードされた文字を 含む可能性があるパラメータを使用し、そのパラメータと他のパラメータを 比較する必要がある場合、比較は大文字と小文字を区別しなければならない [MUST]。現時点で、大文字と小文字を区別しないUTF-8用の比較規則は不可 能なので、回避しなければならない[MUST]。 日付を利用する拡張は、RFC 3261で定義されているSIP-Date BNFを使用しな ければならない[MUST]。その他の日付形式は許可されない。ただし、間隔を 決定する絶対日付(たとえば、何らかのタイマーが期限切れになる時間など) の使用は推奨されない[NOT RECOMMENDED]。その理由は、相手側との間で時 間を同期する必要があるためと、頻度が低い事例のためである。したがっ て、相対時間(秒数で表示)を使用すべきである[SHOULD]。 ネットワーク層アドレスを含む拡張は、ドット区切りの4桁セットのIPv4ア ドレス、[4]で記載されている書式のIPv6アドレス、およびドメイン名を許 可すべきである[SHOULD]。 URIを含むヘッダーフィールドがある拡張は、そのヘッダーフィールドに使 用できるURIスキームについて明示すべきである[SHOULD]。ヘッダーフィー ルドは、ヘッダーフィールドのセマンティクスに一致し、できるだけ広範 なURIスキーム群を許可すべきである[SHOULD]。 ヘッダーフィールドは以下に定義するSIPの標準書式に従わなければならな い[MUST]。 header = header-name HCOLON header-value *(COMMA header-value) header-name = token header-value = value *(SEMI value-parameter) value-parameter = token [EQUAL gen-value] gen-value = token / host / quoted-string value = token / host / quoted-string 場合によっては、この形式では不十分なこともある。たとえば、人間が使用 するための説明文を記載したヘッダーフィールドの場合である。一例を挙げ ると、SIP [2]のSubjectヘッダーフィールドである。この場合、代替の書式 は以下のようになる。 header = header-name HCOLON [TEXT-UTF8-TRIM] 拡張の開発者は、そのヘッダーフィールドに拡張パラメータを許容すべきで ある[SHOULD]。 Rosenberg & Schulzrinne Informational [Page 12] RFC 4485 SIP Guidelines May 2006 URIのリストを含むヘッダーフィールドは、SIPのContactヘッダーフィール ドと同じ構文に従うべきである[SHOULD]。。また、実装者は、このような URIを常に山かっこ「<」と「>」で囲むことも推奨される。我々はこの点が 最も多く誤って実装されている機能であると気づいた。 短縮形の他に、ヘッダーフィールド値の短縮バージョンを定義する必要はな い。SIPメッセージの圧縮は、より仮想の層で処理すべきである[SHOULD]。 たとえば、IPペイロード圧縮[18]またはシグナリング圧縮[20]を使用する。 ヘッダーフィールドの構文は、Augmented Backus-Naur書式で表現される。 また、RFC 4234 [5]の書式に従わなければならない[MUST]。拡張はRFC 3261 [2]で定義された原型のコンポーネントを利用しなければならない[MUST]。 BNF要素の構文が他の仕様で定義されている場合、その構文を複写するので はなく参照することが推奨される[RECOMMENDED]。参照には文書とセクショ ン番号の両方を含めるべである[SHOULD]。すべてのBNF要素は定義または参 照される必要がある。 BNFは、文書の末尾近くに単一のセクションにまとめることが推奨される [RECOMMENDED]。 すべてのトークンと引用符付き文字列は、明示的なリニアホワイトスペース で区切られる。リニアホワイトスペースは、良きにつけ悪きに付け、改行を 許容している。拡張は、代わりのリニアホワイトスペース規則を使用する新 規ヘッダーフィールドを定義してはならない[MUST NOT]。 すべてのSIP拡張は、その文法で定義するすべてのBNF作成が、他のSIP標準 化過程仕様に定義されている既存の文法と競合しないことを検証しなければ ならない[MUST]。 4.5. セマンティクス、セマンティクス、セマンティクス プロトコルの開発者は、セマンティクスに十分な時間を割かずに、構文の問 題に熱中することがよくある。ただし、プロトコルのセマンティクスの方が 遙かに重要である。SIP拡張は拡張のセマンティクスを明確に定義しなけれ ばならない[MUST]。特に、拡張は、UAC、UAS、プロキシがその拡張を処理す る際に期待される動作について規定しなければならない[MUST]。多くの場 合、これら3つの要素それぞれについて個別のセクションを用意すると、説 明が最適になる。各セクションには、最も一般的なメッセージングシナリオ を時系列で、処理規則を順を追って説明すべきである[SHOULD]。 処理規則は、一般的に、メッセージの受信時とタイマーの期限切れの際に、 (送信されるメッセージ、格納される変数、および従うべき規則の観点から) 取るべき行動を規定している。ある行動にメッセージ送信が必要な場合、規 則は、ヘッダーフィールドの挿入に関する要件または他の情報をメッセージ で概説すべきである[SHOULD]。 Rosenberg & Schulzrinne Informational [Page 13] RFC 4485 SIP Guidelines May 2006 拡張は、復元可能な例外的条件、または何らかのユーザー操作を必要とする 例外的条件の場合に取るべき手順を規定すべきである[SHOULD]。復元不可能 なエラーの処理には規定は必要ない。 4.6. 例のセクション 仕様には、コールフローとメッセージフォーマッティングの例を示したセク ションを含めるべきである[SHOULD]。重要な新しい構文を定義する拡張に は、その構文を含むメッセージ例を含めるべきである[SHOULD]。メッセージ フロー例は、一般的な事例と、少なくとも1つの失敗事例または異常事例を カバーすべきである。 優れた例のセクションを構築する一例として、Basic Call Flows仕様[21]に 定義されているメンバシップ プロバイダとメッセージフォーマッティング を参照のこと。完全なメッセージを使用すべき[SHOULD]ことに注意。タグ、 Viaヘッダーフィールド(分岐のIDクッキー付き)、Max-Forwards、 Content-Lengths、Record-Route、Routeの各ヘッダーフィールドを含める 際は、注意が必要である。たとえば、INVITEメッセージはセッション記述を 省略してもよい[MAY]ため、Content-Length値は値が提示されていないこと を示すために「...」に設定される可能性がある[MAY]。ただし、仕様は、 「...」の意味を明示的に呼びかけ、セッション記述が含まれていなかった ことを明示的に示さなければならない[MUST]。 4.7. 概要のセクション 全般的な操作概要を説明することなく、詳細な構文とセマンティクスに進む 拡張文書はあまりにも多い。この概要は拡張ヘッダーを理解させるものであ る。拡張は、拡張の基本操作について論じたプロトコルの概要セクションを 用意することが推奨される[RECOMMENDED]。基本操作は、拡張がカバーする 最も一般的な事例に関する一般的にメッセージフロー(時系列)で構成され る。コールフローの要素について最も重要な処理規則に言及すべきである [SHOULD]。概要セクションにおけるRFC 2119 [1]の用語の使用は推奨されな い[NOT RECOMMENDED]。また、仕様は、概要は本質的に指導書でしかないと いうことを明示すべきである。このセクションは、たとえそれがSIPシステ ムで一般的でも、すべての略語に拡大すべきである[SHOULD]。また、SIPの 専門家ではない読者でも理解できるようにすべきである[SHOULD]。[27]は、 優れた概要セクションを記述する際の追加のガイダンスを提供している。 4.8. IANA条項のセクション 新規SIP拡張を定義する文書には、IANA条項セクションが常にある。 拡張で新規イベントパッケージを定義する場合、そのパッケージを登録しな ければならない[MUST]。RFC 3265 [6]には登録のテンプレートが用意されて Rosenberg & Schulzrinne Informational [Page 14] RFC 4485 SIP Guidelines May 2006 いる。新規イベントパッケージの登録例については、[22]を参照のこと。 RFC 3427 [10]で論じられているように、標準化過程文書は新規のイベント テンプレートパッケージを登録することができる。標準化過程仕様と情報提 供仕様のどちらも、イベントパッケージを登録することができる。 拡張で新規ヘッダーフィールドを定義する場合、そのヘッダーフィールドを 登録しなければならない[MUST]。RFC 3261 [2]には登録のテンプレートが用 意されている。新規SIPヘッダーフィールドの登録方法の例については、RFC 3262 [23]のセクション8.2を参照のこと。標準化過程と情報提供のP-header 仕様はどちらも、新規ヘッダーフィールドを登録することができる[10]。 拡張で新規応答コードを定義する場合、その応答コードを登録しなければな らない[MUST]。RFC 3261 [2]には登録のテンプレートが用意されている。 新規SIP応答コードの登録方法の例については、RFC 3329 [19]のセクション 6.4を参照のこと。RFC 3427 [10]で論じられているように、標準化過程文書 は新規の応答コードを登録することができる。 拡張で新規SIPメソッドを定義する場合、そのメソッドを登録しなければな らない[MUST]。RFC 3261 [2]には登録のテンプレートが用意されている。新 規SIPメソッドの登録方法の例については、RFC 3311 [24]のセクション10を 参照のこと。RFC 3427 [10]で論じられているように、標準化過程文書は新 規のメソッドを登録することができる。 拡張が新規SIPヘッダーフィールドパラメータを定義する場合、RFC 3968 [7] のガイドラインに従ってヘッダーフィールドパラメータを登録しなければな らない[MUST]。この仕様のセクション4.1にテンプレートが用意されている。 IETFが承認した仕様のみが、新規ヘッダーフィールドパラメータを登録する ことができる。ただし、この仕様が標準化過程である必要はない。 拡張が新規SIP URIパラメータを定義する場合、RFC 3969 [8]のガイドライ ンに従ってURIパラメータを登録しなければならない[MUST]。 この仕様のセクション4.1にテンプレートが用意されている。標準化過程文 書のみが新規URIパラメータを登録することができる。 多くのSIP拡張は、Require、Proxy-Require、Supportedの各ヘッダーフィー ルドでオプションタグを利用している。セクション4.1では、このような ヘッダーフィールドの使用に関連するいくつかの問題について論じている。 拡張に本当に必要な場合、拡張用のオプションタグを登録しなければならな い[MUST]。RFC 3261 [2]には登録のテンプレートが用意されている。新規オ プションタグの登録方法の例については、RFC 3262 [23]のセクション8.1を 参照のこと。標準化過程RFCのみが新規オプションタグを登録することがで きる。 一部のSIP拡張には、そのIANA登録が確立する必要がある。RFC 2434 [25] は、IANA登録を確立する方法とタイミングに関するガイダンスを提供して いる。確立する方法の例については、RFC 3265 [6]のセクション6を参照の こと。 Rosenberg & Schulzrinne Informational [Page 15] RFC 4485 SIP Guidelines May 2006 4.9. 文書命名の規則 拡張に関して行われた重要な決定は、そのタイトルである。 タイトルは、その文書がSIP拡張であることを示すものにしなければならな い[MUST]。タイトルは、「A [機能の要約] for the Session Initiation Protocol (SIP)」という基本的な形式に従うことが推奨される [RECOMMENDED]。この機能の要約は、拡張を説明する1〜3単語である。たと えば、拡張が、コーヒーを作るためのMake-Coffeeという新規ヘッダー フィールドを定義する場合、タイトルは「Making Coffee with the Session Initiation Protocol (SIP)」のようになる。このような追加の単語は、 ヘッダーフィールドの命名というよりは、説明的にすることが推奨され る[RECOMMENDED]。たとえば、コーヒーを作る拡張は、「The Make-Coffee Header for the Session Initiation Protocol」と命名すべきではない。 新規メソッドを定義する拡張の場合、承認できるタイトルのテンプレート は、「The Session Initiation Protocol (SIP) X Method」である。このX はメソッド名である。 [26]に従って、RFCのタイトルのSIPという略語は略してはならない[MUST]こ とに注意。 4.10. 新規メソッドに関するその他の考慮事項 新規メソッドを定義する拡張は、以下の問題について考慮し、論じるべきで ある[SHOULD]。 o ボディを含むことができるか。可能な場合、そのボディの存在にはどの ような意味があるか。どのボディタイプが許可されるか。 o 同方向または逆方向で進行中の他のトランザクション中に、このリクエ ストメソッドとのトランザクションが発生する可能性はあるか。 o 拡張は、そのメソッドのリクエストで提示できるヘッダーフィールドにつ いて定義しなければならない[MUST]。この情報は、RFC 3261 [2]の表2/3 の新しい列として表記することが推奨される[RECOMMENDED]。表には、拡 張の執筆時点で標準化過程RFCに定義されているすべてのヘッダーフィー ルドについて、行を含めなければならない[MUST]。 o リクエストはダイアログ内で送信できるか。またはダイアログを確立す るか。 o ターゲット更新リクエストか。 o 新規メソッドを定義するSIP拡張は、オファーおよびアンサーがその メソッドまたは応答のリクエストに指定できるかどうかを規定してもよ い[MAY]。ただし、このような拡張は、[28]に規定されているプロトコル Rosenberg & Schulzrinne Informational [Page 16] RFC 4485 SIP Guidelines May 2006 規則に従わなければならない[MUST]。また、SIP [2]の規定に従って、オ ファーとアンサーに関する追加の制約に従わなければならない[MUST]。 o 新規メソッドが含まれるリクエストには信頼性の扱いという性質がある ため、これらのリクエストにはUASが直ちに応答する必要がある。応答の 生成に長時間を要するプロトコル拡張(人間の操作を必要とする新規メ ソッドなど)は、代わりに2つのトランザクション(1つはリクエストの送 信用、もう1つはリクエストの結果を伝達する逆方向のもの)を使用すべ きである[SHOULD]。この例については、SUBSCRIBEとNOTIFY [6]がある。 o SIP仕様[2]は、新規メソッドを使用するトランザクションを、CANCELリ クエストをでキャンセルできたかどうかを新規メソッドで規定すること を許容している。非INVITEトランザクションの詳細な研究[14]では、 非INVITEトランザクションをできるだけ早く完了する必要があることが 説明されている。新規メソッドは、CANCELの意味が出てくるくらい長い 間、トランザクションを保留するトランザクションを計画してはなら ない。したがって、新規メソッドは、そのメソッドが含まれるリクエス トで開始されたトランザクションをキャンセルできないことを宣言しな ければならない[MUST]。詳細な研究では、こうしたガイドラインを改訂 するポイントで、この制限を緩和している可能性がある。 o 新規ダイアログを確立する新規メソッドは、分岐の影響について論じなけ ればならない。このような新規メソッドの設計は、ダイアログを確立する リクエストから、逆方向で直ちにリクエストを送信する必要性のパターン に従うべきである。これは、サブスクリプションがRFC 3265 [8]に従って 作成されるときに直ちにNOTIFYを送信する場合と似ている。 すべての新規メソッドの信頼性メカニズムは、BYEと同じでなければならな い。INVITEの遅延応答機能はINVITEでのみ使用できる。新規メソッドには使 用できない。新規メソッドの設計では、即時の応答を推奨しなければなら ない。有効にするアプリケーションで遅延を必要とする場合、設計は複数ト ランザクションを使用したパターンに従うべきである[SHOULD]。これは、 RFC 3265に記載されている、SUBSCRIBEに対する応答で、異なる Subscription-Stateヘッダーフィールド値(特にpendingとactive)を含む NOTIFYの用法に似ている。 4.11. 新規ヘッダーフィールドまたはヘッダーフィールドパラメータに関する その他の考慮事項 新規ヘッダーフィールドまたはヘッダーフィールドパラメータを定義する拡 張にとって、最も重要な問題は下位互換性である。この問題の議論について は、セクション4.1を参照のこと。拡張は、下位互換性にどのように対処し たかについて、詳述しなければならない[MUST]。 ヘッダーフィールドまたはパラメータを使用して既存のメソッドを過負荷に することで、新規メソッドの作成を回避することは魅力的な場合が多い。 ヘッダーフィールドとパラメータは、基本的にリクエストのメソッドの意味 Rosenberg & Schulzrinne Informational [Page 17] RFC 4485 SIP Guidelines May 2006 を変えることは意図されていない。新規ヘッダーフィールドで、基本的なセ マンティクスとメソッドの処理規則を変更することはできない。メッセージ 名が足りなくなることはないため、拡張によってリクエストの基本的な意味 が変わる場合、新規メソッドを定義すべきである[SHOULD]。 新規ヘッダーフィールドを定義する拡張の場合、拡張は、ヘッダーフィール ドを指定できるリクエストメソッドと、使用できる応答を定義しなければな らない[MUST]。この情報は、RFC 3261 [2]の表2/3の新しい行として表記す ることが推奨される[RECOMMENDED]。表には、拡張の執筆時点で標準化過程 RFCに定義されているすべてのメソッドについて、列を含めなければならな い[MUST]。 4.12. 新規ボディタイプに関するその他の考慮事項 SIPはUDP上で実行できるため、大量のボディを含めることを規定した拡張 は、エンドツーエンドの輻輳制御されたトランスポートが保証されない限 り、失敗する。輻輳制御されたトランスポートが使用できる場合でも、可能 であれば、コンテンツは間接的に含めるべきである[9]。 ボディの存在によってメッセージの性質を変えてはならない[MUST NOT]こと に注意。つまり、ボディは、特定のメソッドのリクエストまたは応答の処理 と関係するステートマシンを変更できない。 ボディは、追加データを提供することでこの処理を強化する。 5. SIP機能との相互作用 SIPの一部機能は、普通とは異なる方法で拡張とやり取りしていることがわか っている。拡張の著者は、このようなSIP機能との拡張のやり取りについて 考慮し、普通とは異なる相互作用があれば、それについても文書化すべきで ある[SHOULD]。 問題の最も一般的な原因について以下に示す。 分岐: これまでのところ、分岐は、拡張との相互作用が最も面倒な点であ る。この理由は一般的に、(1) 単一の送信リクエストを未知数のUASが受 信し、(2) 単一のINVITEに対して複数の応答が存在する可能性があるた めである。 CANCELとACK: CANCELとACKは「特殊な」SIPリクエストである。これらリク エストには、一般的なリクエスト処理規則の多くでは例外とされるものが ある。この特殊なステータスの主な理由は、CANCELとACKが常に他のリク エストと関連付けられていることである。新規メソッドは、前述のように キャンセルの意味を考慮すべきである[SHOULD]。INVITEリクエストに新規 ヘッダーフィールドを定義する拡張は、ACKとCANCELにも含める必要があ るかどうかについて考慮すべきである[SHOULD]。この処理は、多くの場 合、ステートレスプロキシがCANCELまたはACKをINVITEと同様にルーティ ングできるように実行されている。 Rosenberg & Schulzrinne Informational [Page 18] RFC 4485 SIP Guidelines May 2006 ルーティング: リクエストにRouteヘッダーフィールドが含まれると、中間 プロキシ経由で送信される。ダイアログを確立するリクエストは Record-Routeできるため、最初のリクエストはあるプロキシ群を経由し、 以降のリクエストは異なるプロキシ群を経由する。このようなSIP機能 は、一般的な方法で拡張とやり取りする。 ステートレスプロキシ: SIPはプロキシがステートレスになることを許可し ている。ステートレスプロキシは、メッセージを再送信できず、特定の サービスを実行できない。何らかのプロキシ処理に依存する拡張は、 ステートレスプロキシがその処理に及ぼす影響について考慮すべきであ る[SHOULD]。 ダイアログの使用: SIPは、通常は独自のダイアログを作成するリクエスト (SUBSCRIBEなど)を、他のメソッド(INVITEなど)で作成されたダイアログ 内で使用することを許可している。このような場合、そのダイアログの 複数の使用例であると呼ばれている。拡張は、ダイアログ使用との相互 作用について考慮すべきである[SHOULD]。特に、新規エラー応答コード を定義する拡張は、その応答コードによって、ダイアログやすべての使 用が終了したか、または特定の使用についてのみかについて説明すべき である[SHOULD]。 6. セキュリティの考慮事項 本文書の性質として、新規のセキュリティの考慮事項は導入されない。ただ し、本文書に記載されている原則の多くは、将来のSIP拡張設計がSIPセキュ リティアーキテクチャに対応する可能性があるかどうかに影響を与える。 7. 謝辞 著者はRohan MahyとSpencer Dawkinsにいただいたコメントについて謝辞を 述べたい。Robert Sparksは、CANCEL問題について重要なテキストを寄稿 した。Allison Mankinの支援に感謝を述べたい。 8. 参考文献 8.1. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. Rosenberg & Schulzrinne Informational [Page 19] RFC 4485 SIP Guidelines May 2006 [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [7] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004. [8] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004. [9] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 8.2. Informative References [10] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. [11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [13] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [14] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, January 2006. [15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. Rosenberg & Schulzrinne Informational [Page 20] RFC 4485 SIP Guidelines May 2006 [17] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [18] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. [19] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003. [20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003. [21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. [22] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [26] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Work in Progress, July 2004. [27] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005. [28] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Rosenberg & Schulzrinne Informational [Page 21] RFC 4485 SIP Guidelines May 2006 著者の連絡先 Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@cisco.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 Rosenberg & Schulzrinne Informational [Page 22] RFC 4485 SIP Guidelines May 2006 完全な著作権表記 Copyright (C) The Internet Society (2006). 本文書は、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編集職務のための資金は、IETF Administrative Support Activity (IASA)によって提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ----------------------------------------------------------------------- Rosenberg & Schulzrinne Informational [Page 23]