Network Working Group G. Camarillo Request for Comments: 3968 Ericsson Updates: 3427 December 2004 BCP: 98 Category: Best Current Practice セッション開始プロトコル(SIP)の ヘッダーフィールドパラメータの Internet Assigned Number Authority (IANA)への登録 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティのために、現段階でのインターネッ トのベストプラクティス(Internet Best Current Practices)を提示し、改善 のための議論や提案を依頼するものである。本文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書は、セッション開始プロトコル(Session Initiation Protocol/SIP) のヘッダーフィールドパラメータとパラメータ値について、Internet Assigned Number Authority (IANA)に登録を作成する方法について説明す る。また、この登録の初期のエントリとして使用された既存のパラメータと パラメータ値についても列挙する。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. 登録の使用 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. ヘッダーフィールドパラメータの下位登録 . . . . . . . . . 3 4.2. SIPヘッダーフィールドパラメータの登録ポリシー . . . . . 6 5. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 7 6. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . . . 7 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 7 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . . . 8 Camarillo Best Current Practice [Page 1] RFC 3968 SIP Parameter Registry December 2004 1. はじめに RFC 3261 [3]は、新規ヘッダーフィールドパラメータと新規パラメータ値の 定義を許可している。ただし、RFC 3261は、それらのIANA登録を省略した。 本文書は、SIPのIANA登録を作成する。 RFC 3427 [4]は、SIPを拡張する処理について文書化している。本文書は、 新しいヘッダーフィールドパラメータとパラメータ値を定義および登録する 方法について規定することで、RFC 3427を更新する。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119 のBCP 14 [1]に記載されるとおりに解釈されるべきであり、CPL準拠の実装 のための実装レベルを示すものである。 3. 登録の使用 SIPヘッダーフィールドパラメータとパラメータ値は、IANAに登録するため に、RFCに文書化しなければならない[MUST]。この文書では、パラメータと パラメータ値の構文、用途、およびセマンティクスを詳細に説明しなければ ならない[MUST]。この要件の意図は、個別の実装間の相互運用性を確保し、 異なる機能の実装間で意図しない名前空間を回避することである。 この登録は、他のプロトコルの登録とは異なり、RFCで定義されているパ ラメータとパラメータ値のみを扱っていることに注意(つまり、ベンダー 拡張ツリーがない)。RFC 3427 [4]には、セキュリティを損なう可能性、 プロトコルの複雑さを大幅に増加させる可能性、またはその両方の可能 性がある新しいSIP拡張について、考慮事項が記載されている。このよう な考慮事項の結果として、新しいパラメータとパラメータ値をRFCに文書 化する必要がある。 SIPヘッダーフィールドパラメータまたはパラメータ値を定義するRFC は、 以下に従って、IANAに登録しなければならない[MUST]。 登録するSIPヘッダーフィールドパラメータとパラメータ値は、「予約語」 として扱うべきである。相互運用性を維持するために、登録したパラメータ とパラメータ値は、それを定義するRFCの記載に準拠する方法で使用しなけ ればならない[MUST]。 実装には、登録済みパラメータと競合する「私的」または「ローカル定義」 のSIPヘッダーフィールドパラメータまたはパラメータ値を利用してはなら ない[MUST NOT]。 Camarillo Best Current Practice [Page 2] RFC 3968 SIP Parameter Registry December 2004 未登録のSIPヘッダーフィールドパラメータとパラメータ値を実装に使用 してもよいが、こうしたパラメータの使用には危険があることに開発者 は注意する必要がある。新しいSIPヘッダーフィールドパラメータとパラ メータ値はいつでも登録することができる。また、新しい登録パラメー タとパラメータ値が、現在使用中の未登録パラメータと競合しないこと は保証されない。 一部のSIPヘッダーフィールドパラメータは、定義済みパラメータ値のみを 受け入れる。たとえば、使用中のトランスポートプロトコルを示す、あるパ ラメータは、有効値としてTCP、UDP、SCTPという定義済みトークンのみを受 け入れる。この種類のSIPヘッダーフィールドパラメータすべてについて全 パラメータを登録するには、多数の下位登録が必要になる。その代わりに、 本文書は参照によってパラメータ値を登録することを選択した。つまり、あ るヘッダーフィールドパラメータのパラメータ登録のエントリには、パラ メータの新しい値を定義するRFCへの参照を含める。パラメータ値を定義す るRFCへの参照は、登録では二重角かっこで表記される。 そのため、ヘッダーフィールドパラメータの登録には、各パラメータが定義 済みの値のみを受け入れるかどうかを示す列が含まれる。この列が「yes」 のパラメータを実装するには、参考文献として記載されているRFCの有効な パラメータ値すべてを確認する必要がある。 4. IANA条項 RFC 3261 [3]のセクション27では、メソッド、ヘッダーフィールド名、警告 コード、ステータスコード、オプションタグのIANA登録を作成している。 本仕様では、SIPパラメータ登録の下位にヘッダーフィールドパラメータの 登録を新たに作成する。 4.1. ヘッダーフィールドパラメータの下位登録 SIPヘッダーフィールドの多くは、新しいパラメータを定義することで拡張す ることができる。新しいSIPヘッダーフィールドパラメータは、IANAによっ て登録される。ヘッダーフィールドまたはパラメータの新しい値を登録する ときは、以下の情報を指定しなければならない[MUST]。 o このパラメータが出現するヘッダーフィールド。 o 登録するヘッダーフィールドパラメータの名前。 o 定義済みの値のみを受け入れるパラメータかどうか。 Camarillo Best Current Practice [Page 3] RFC 3968 SIP Parameter Registry December 2004 o パラメータを定義したRFCと、パラメータの新しい値を定義したRFCへの 参照。パラメータ値を定義したRFCへの参照は、登録では二重角かっこで 表記される。 複数のヘッダーフィールドに出現する可能性があるパラメータが、同じ名前 を持っていてもよい[MAY]。ただし、同じヘッダーフィールドに出現する可 能性があるパラメータは、異なる名前を持たなければならない[MUST]。 この下位登録の初期値を以下に示す。 ヘッダーフィールド パラメータ名 定義 参考文献 済み値 _____________________________________________________________________ Accept q No [RFC 3261] Accept-Encoding q No [RFC 3261] Accept-Language q No [RFC 3261] Authorization algorithm Yes [RFC 3261] [[RFC 3310]] Authorization auts No [RFC 3310] Authorization cnonce No [RFC 3261] Authorization nc No [RFC 3261] Authorization nonce No [RFC 3261] Authorization opaque No [RFC 3261] Authorization qop Yes [RFC 3261] Authorization realm No [RFC 3261] Authorization response No [RFC 3261] Authorization uri No [RFC 3261] Authorization username No [RFC 3261] Authentication-Info cnonce No [RFC 3261] Authentication-Info nc No [RFC 3261] Authentication-Info nextnonce No [RFC 3261] Authentication-Info qop Yes [RFC 3261] Authentication-Info rspauth No [RFC 3261] Call-Info purpose Yes [RFC 3261] Contact expires No [RFC 3261] Contact q No [RFC 3261] Content-Disposition handling Yes [RFC 3261] Event id No [RFC 3265] From tag No [RFC 3261] P-Access-Network-Info cgi-3gpp No [RFC 3455] P-Access-Network-Info utran-cell-id-3gpp No [RFC 3455] P-Charging-Function-Addresses ccf No [RFC 3455] P-Charging-Function-Addresses ecf No [RFC 3455] P-Charging-Vector icid-value No [RFC 3455] P-Charging-Vector icid-generated-at No [RFC 3455] P-Charging-Vector orig-ioi No [RFC 3455] P-Charging-Vector term-ioi No [RFC 3455] Camarillo Best Current Practice [Page 4] RFC 3968 SIP Parameter Registry December 2004 P-DCS-Billing-Info called No [RFC 3603] P-DCS-Billing-Info calling No [RFC 3603] P-DCS-Billing-Info charge No [RFC 3603] P-DCS-Billing-Info locroute No [RFC 3603] P-DCS-Billing-Info rksgroup No [RFC 3603] P-DCS-Billing-Info routing No [RFC 3603] P-DCS-LAES content No [RFC 3603] P-DCS-LAES key No [RFC 3603] P-DCS-Redirect count No [RFC 3603] P-DCS-Redirect redirector-uri No [RFC 3603] Proxy-Authenticate algorithm Yes [RFC 3261] [[RFC 3310]] Proxy-Authenticate domain No [RFC 3261] Proxy-Authenticate nonce No [RFC 3261] Proxy-Authenticate opaque No [RFC 3261] Proxy-Authenticate qop Yes [RFC 3261] Proxy-Authenticate realm No [RFC 3261] Proxy-Authenticate stale Yes [RFC 3261] Proxy-Authorization algorithm Yes [RFC 3261] [[RFC 3310]] Proxy-Authorization auts No [RFC 3310] Proxy-Authorization cnonce No [RFC 3261] Proxy-Authorization nc No [RFC 3261] Proxy-Authorization nonce No [RFC 3261] Proxy-Authorization opaque No [RFC 3261] Proxy-Authorization qop Yes [RFC 3261] Proxy-Authorization realm No [RFC 3261] Proxy-Authorization response No [RFC 3261] Proxy-Authorization uri No [RFC 3261] Proxy-Authorization username No [RFC 3261] Reason cause Yes [RFC 3326] Reason text No [RFC 3326] Retry-After duration No [RFC 3261] Security-Client alg Yes [RFC 3329] Security-Client ealg Yes [RFC 3329] Security-Client d-alg Yes [RFC 3329] Security-Client d-qop Yes [RFC 3329] Security-Client d-ver No [RFC 3329] Security-Client mod Yes [RFC 3329] Security-Client port1 No [RFC 3329] Security-Client port2 No [RFC 3329] Security-Client prot Yes [RFC 3329] Security-Client q No [RFC 3329] Security-Client spi No [RFC 3329] Security-Server alg Yes [RFC 3329] Security-Server ealg Yes [RFC 3329] Security-Server d-alg Yes [RFC 3329] Security-Server d-qop Yes [RFC 3329] Camarillo Best Current Practice [Page 5] RFC 3968 SIP Parameter Registry December 2004 Security-Server d-ver No [RFC 3329] Security-Server mod Yes [RFC 3329] Security-Server port1 No [RFC 3329] Security-Server port2 No [RFC 3329] Security-Server prot Yes [RFC 3329] Security-Server q No [RFC 3329] Security-Server spi No [RFC 3329] Security-Verify alg Yes [RFC 3329] Security-Verify ealg Yes [RFC 3329] Security-Verify d-alg Yes [RFC 3329] Security-Verify d-qop Yes [RFC 3329] Security-Verify d-ver No [RFC 3329] Security-Verify mod Yes [RFC 3329] Security-Verify port1 No [RFC 3329] Security-Verify port2 No [RFC 3329] Security-Verify prot Yes [RFC 3329] Security-Verify q No [RFC 3329] Security-Verify spi No [RFC 3329] Subscription-State expires No [RFC 3265] Subscription-State reason Yes [RFC 3265] Subscription-State retry-after No [RFC 3265] To tag No [RFC 3261] Via branch No [RFC 3261] Via comp Yes [RFC 3486] Via maddr No [RFC 3261] Via received No [RFC 3261] Via rport No [RFC 3581] Via ttl No [RFC 3261] WWW-Authenticate algorithm Yes [RFC 3261] [[RFC 3310]] WWW-Authenticate domain Yes [RFC 3261] WWW-Authenticate nonce No [RFC 3261] WWW-Authenticate opaque No [RFC 3261] WWW-Authenticate qop Yes [RFC 3261] WWW-Authenticate realm No [RFC 3261] WWW-Authenticate stale Yes [RFC 3261] 4.2. SIPヘッダーフィールドパラメータの登録ポリシー RFC 2434 [2]の用語に従って、SIPヘッダーフィールドパラメータとパラ メータ値の登録ポリシーには、「IETFの合意」が必要である。 この登録の目的から、IANAの登録をリクエストするパラメータまたはパラ メータ値は、RFCで定義しなければならない[MUST]。このRFCが標準化過程で ある必要はない。 Camarillo Best Current Practice [Page 6] RFC 3968 SIP Parameter Registry December 2004 5. セキュリティの考慮事項 本文書の登録自体には、セキュリティの考慮事項はない。ただし、RFC 3427 で言及されているように、IETFがそのSIP拡張を管理するために重要な理由 は、すべての拡張とパラメータが安全な使用を実現できるように確保するこ とである。本仕様で説明するパラメータ登録について、対応するRFCを発行 する場合、詳細なセキュリティの考慮事項を記載しなければならない [MUST]。 6. 謝辞 Jonathan Rosenberg、Henning Schulzrinne、Rohan Mahy、Dean Willis、 Aki Niemi、Bill Marshall、Miguel A. Garcia-Martin、Jean Francois Mule、Allison Mankinから、本文書について有益なコメントをいただいた。 7. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [3] 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. [4] 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. 著者の連絡先 Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Camarillo Best Current Practice [Page 7] RFC 3968 SIP Parameter Registry December 2004 完全な著作権表記 Copyright (C) The Internet Society (2004). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イ ンターネット協会およびIETFは、この情報がいかなる権利も侵害していない という保証、商用利用および特定目的への適合性への保証を含め、また、こ れらだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行 われない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関するIETFの手続きの情報は、BCP 78および BCP 79に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情 報は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ----------------------------------------------------------------------- Camarillo Best Current Practice [Page 8]