Network Working Group O. Levin
Request for Comments: 4508 Microsoft Corporation
Category: Standards Track A. Johnston
Avaya
May 2006
Conveying Feature Tags with the
Session Initiation Protocol (SIP) REFER Method
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach.
RFC 3840で定義されたSIP「発信者の環境設定」の拡張子は、その要求の処理のための創始者の能力や好みに関する情報を伝えるためのSIPリクエストを可能にするメカニズムを提供します。 SIPは、RFC 3515で定義された方法は、一方の当事者がSIP要求を開始するために別のものを誘導することを可能にする機構を提供するREFER。この文書は、そうすることによって、RFC 3840のメカニズムを使用する方法をREFER延び、REFERの発信者は、誘導されたリクエストが到達すると予想されていることをターゲットの特性として、受信者に通知することができます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Definitions .....................................................3
4. Examples ........................................................3
4.1. isfocus Feature Tag Usage ..................................3
4.2. Voice and Video Feature Tags Usage .........................3
4.3. Example with URI parameters and multiple feature tags ......3
5. Security Considerations .........................................4
6. Acknowledgements ................................................4
7. Normative References ............................................4
This document extends the SIP [2] REFER method defined in RFC 3515 [3] to be used with feature parameters defined in RFC 3840 [4].
この文書では、[4] [3] RFC 3840で定義された特徴量で使用するSIP [2] RFC 3515で定義された方法をREFER延びています。
Feature tags are used by a UA to convey to another UA information about capabilities and features. This information can be shared by a UA using a number of mechanisms, including REGISTER requests and responses and OPTIONS responses. This information can also be shared in the context of a dialog by inclusion with a remote target URI (Contact URI).
フィーチャータグは機能や特徴については、別のUAの情報を伝えるためにUAによって使用されています。この情報は、REGISTER要求および応答とOPTIONS応答を含む多数のメカニズムを使用してUAで共有することができます。この情報は、リモートターゲットURI（URIを連絡）で封入して、ダイアログのコンテキスト内で共有することができます。
Feature tag information can be very useful to another UA. It is especially useful prior to the establishment of a session. For example, if a UA knows (through an OPTIONS query, for example) that the remote UA supports both video and audio, the calling UA might call, offering video in the SDP. Another example is when a UA knows that a remote UA is acting as a focus and hosting a conference. In this case, the UA might first subscribe to the conference URI and find out details about the conference prior to sending an INVITE to join.
フィーチャータグ情報は、別のUAに非常に役立ちます。これは、前のセッションの確立に特に便利です。 UAは、遠隔UAは、ビデオとオーディオの両方をサポートしていること（例えばOPTIONSクエリ、経由）を知っている場合たとえば、呼び出しUAは、SDPでビデオを提供し、呼ぶかもしれません。 UAは、リモートUAが焦点として機能し、会議をホストしていることを知っているとき、別の例はあります。この場合、UAは、最初の会議URIに加入する前に招待の送信に会議の詳細を見つけるかもしれません。
This extension to the REFER method provides a mechanism by which the REFER-Issuer can provide this useful information about the REFER-Target capabilities and functionality to the REFER-Recipient by including feature tags in the Refer-To header field in a REFER request.
REFERメソッドへのこの拡張はREFER-発行者が参照-を参照要求のフィールドをヘッダに特徴タグを含めることによって、REFER受信者を参照して、ターゲットの機能や機能については、この有用な情報を提供することができるメカニズムを提供します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" [1] RFC 2119に記載されるように解釈されるべきです。
To simplify discussions of the REFER method and its extensions, three new terms are used throughout the document:
REFERメソッドの議論とその拡張機能を簡素化するために、3つの新しい用語が文書全体で使用されています。
o REFER-Issuer: the UA issuing the REFER request o REFER-Recipient: the UA receiving the REFER request o REFER-Target: the UA designated in the Refer-To URI
O-REFER発行者：UAは、REFER要求O REFER受信者の発行：UAは、要求O REFER-TargetのREFER受信：UAはURI参照の対で指定さ
The Refer-To BNF from RFC 3515:
参照してください-にBNF RFC 3515から：
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *(SEMI generic-param)
参照してください-TO =（ "を参照してください-へ" / "R"）HCOLON（名前-addrに/ ADDR-SPEC）*（SEMIジェネリック-PARAM）
is extended to:
に拡張されます。
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *(SEMI refer-param) refer-param = generic-param / feature-param
参照してください-TO =（ "を参照してください-へ" / "R"）HCOLON（名前-addrに/ ADDR-SPEC）*（SEMI参照してください-のparam）を参照してください-PARAM =ジェネリック-PARAM /機能-PARAMを
where feature-param is defined in Section 9 of RFC 3840 [4].
特徴PARAMは、RFC 3840のセクション9で定義される[4]。
Note that if any URI parameters are present, the entire URI must be enclosed in "<" and ">". If the "<" and ">" are not present, all parameters after the URI are header parameters, not URI parameters.
任意のURIパラメータが存在する場合、全体のURIは、「<」と「>」で囲まなければならないことに注意してください。もし、「<」と「>」、URIの後に全てのパラメータは、ヘッダパラメータはなく、URIパラメータは存在しないです。
The example below shows how the "isfocus" feature tag can be used by REFER-Issuer to tell the REFER-Recipient that the REFER-Target is a conference focus and, consequently, that sending an INVITE will bring the REFER-Recipient into the conference:
以下の例では、「isfocus」フィーチャータグがINVITEを送ることが会議にREFER-受信者をもたらすことを、REFER-Targetは結果的に、会議の焦点であるとREFER-受信者に伝えるためにREFER発行者によって使用することができます方法を示しています：
Refer-To: sip:conf44@example.com;isfocus
参照してください-TO：SIP：conf44@example.com; isfocus
The example below shows how a REFER-Issuer can tell the REFER-Recipient that the REFER-Target supports audio and video and, consequently, that a video and audio session can be established by sending an INVITE to the REFER-Target:
以下の例では、REFER発行者は、ビデオとオーディオのセッションがREFER-ターゲットにINVITEを送信することにより確立することができ、REFER-Targetは結果的に、オーディオとビデオをサポートし、REFER-受信者に伝えることができます方法を示しています。
Refer-To: "Alice's Videophone" <sip:alice@videophone.example.com> ;audio;video
「アリスのテレビ電話」：-を参照してください。<SIP：alice@videophone.example.com>を、オーディオ、ビデオ
The example below shows how the REFER-Issuer can tell the REFER-Recipient that the REFER-Target is a voicemail server. Note that the transport URI parameter is enclosed within the "<" and ">" so that it is not interpreted as a header parameter.
以下の例では、REFER発行者はREFER-TargetはボイスメールサーバであるREFER-受信者に伝えることができます方法を示しています。それはヘッダパラメータとして解釈されないように搬送URIパラメータは、「<」と「>」で囲まれていることに留意されたいです。
Refer-To: <sip:alice-vm@example.com;transport=tcp> ;actor="msg-taker";automata;audio
参照してください-TO：<SIP：alice-vm@example.com;運輸= TCP>;俳優= "MSG-係";オートマトン;オーディオ
Feature tags can provide sensitive information about a user or a UA. As such, RFC 3840 cautions against providing sensitive information to another party. Once this information is given out, any use may be made of it, including relaying to a third party as in this specification.
フィーチャータグは、ユーザーまたはUAに関する機密情報を提供することができます。別の関係者に機密情報を提供に対して、このような、RFC 3840個の注意事項として。この情報が配られると、任意の使用は、この明細書のように第三者に中継を含む、それからなることができます。
A REFER-Issuer MUST NOT create or guess feature tags. Instead, a feature tag included in a REFER SHOULD be discovered in an authenticated and secure method (such as an OPTIONS response or from a remote target URI in a dialog) directly from the REFER-Target.
REFER発行者は、フィーチャータグを作成したり、推測してはなりません。代わりに、特徴タグは、REFER REFER-ターゲットから直接（例えば、OPTIONS応答として、またはダイアログのリモートターゲットURIから）認証され、安全な方法で発見されてくださいに含まれます。
It is RECOMMENDED that the REFER-Issuer includes in the Refer-To header field all feature tags that were listed in the most recent Contact header field of the REFER-Target.
REFER発行者が参照してください-ToフィールドにREFER-ターゲットの最も最近のContactヘッダーフィールドにリストされたすべての機能タグをヘッダに含まれることが推奨されます。
A feature tag provided by a REFER-Issuer cannot be authenticated or certified directly from the REFER request. As such, the REFER-Recipient MUST treat the information as a hint. If the REFER-Recipient application logic or user's action depends on the presence of the expressed feature, the feature tag can be verified. For example, in order to do so, the REFER-Recipient can directly send an OPTIONS query to the REFER-Target over a secure (e.g., mutually authenticated and integrity-protected) connection. This protects the REFER-Recipient against the sending of incorrect or malicious feature tags.
REFER-発行者によって提供される機能タグは、認証済みまたはREFERリクエストから直接認定することはできません。そのため、REFER-受信者は、ヒントなどの情報を扱わなければなりません。 REFER-受信者のアプリケーションロジックやユーザの行動が発現機能の存在に依存している場合、機能のタグを検証することができます。例えば、そうするために、REFER受信者が直接安全な（例えば、相互認証及び完全性保護された）接続を介してREFER-ターゲットにOPTIONSクエリを送信することができます。これは、不正または悪意のあるフィーチャータグの送信に対するREFER-受信者を保護します。
The authors would like to thank Jonathan Rosenberg for providing helpful guidance to this work.
作者はこの仕事に役立つガイダンスを提供するためのジョナサン・ローゼンバーグに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[3] R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月、火花。
[4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[4]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivatを、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェント能力を示します"。
Authors' Addresses
著者のアドレス
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
oriTレヴィンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
Phone: 425-722-2225 EMail: oritl@microsoft.com
電話：425-722-2225 Eメール：oritl@microsoft.com
Alan Johnston Avaya St. Louis, MO 63124
アラン・ジョンストンアバイアセントルイス、MO 63124
EMail: ajohnston@ipstation.com
メールアドレス：ajohnston@ipstation.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。