RFC4508 日本語訳
4508 Conveying Feature Tags with the Session Initiation Protocol (SIP)REFER Method. O. Levin, A. Johnston. May 2006. (Format: TXT=11338 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group O. Levin
Request for Comments: 4508 Microsoft Corporation
Category: Standards Track A. Johnston
Avaya
May 2006
コメントを求めるワーキンググループO.レヴィンの要求をネットワークでつないでください: 4508年のマイクロソフト社カテゴリ: 標準化過程A.ジョンストンAvaya2006年5月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
RFC3840で定義されたSIP「訪問者好み」拡大はその要求の取り扱いのための創始者の能力と好みに関連しながら情報を伝達するというSIP要求を許すメカニズムを提供します。 RFC3515で定義されたSIP REFERメソッドは1回のパーティーが、別のものがSIP要求を開始するのを引き起こすことができるメカニズムを提供します。 このドキュメントはRFC3840のメカニズムを使用する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
1. 序論…2 2. 用語…2 3. 定義…3 4. 例…3 4.1isfocus Feature Tag Usage…3 4.2. 声とビデオの特徴は用法にタグ付けをします…3 4.3. URIパラメタがある例と倍数はタグを特集します…3 5. セキュリティ問題…4 6. 承認…4 7. 標準の参照…4
Standards Track [Page 1]
RFC 4508 Feature Tags with SIP REFER May 2006
一口がある標準化過程[1ページ]RFC4508特徴タグは2006年5月に参照されます。
1. Introduction
1. 序論
This document extends the SIP [2] REFER method defined in RFC 3515 [3] to be used with feature parameters defined in RFC 3840 [4].
このドキュメントはRFC3840[4]で定義される特徴パラメタと共に使用されるためにRFC3515[3]で定義されたSIP[2]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によって使用されます。 UAは多くのメカニズムを使用することでこの情報を共有できます、REGISTER要求、応答、およびOPTIONS応答を含んでいて。 また、共有されていて、この情報はリモート目標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に加入して、接合するためにINVITEを送る前に、会議に関する詳細を見つけるかもしれません。
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-受取人への包含するのによる能力と機能性がタグを特集するREFER目標に関するこの役に立つ情報を提供できるメカニズムを提供する、Refer、-、REFER要求におけるヘッダーフィールド。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように解釈されることであるべきですか?
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はo REFER-受取人を要求します: REFERを受けるUAはo REFER-目標を要求します: UAが中で指定した、Refer、-、URI
Standards Track [Page 2]
RFC 4508 Feature Tags with SIP REFER May 2006
一口がある標準化過程[2ページ]RFC4508特徴タグは2006年5月に参照されます。
3. Definitions
3. 定義
The Refer-To BNF from RFC 3515:
RFC3515からBNFを参照してください:
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
*(SEMI generic-param)
=(/「r」について「言及する」)HCOLON(名前addr / addr仕様)*を参照してください。(SEMIジェネリック-param)
is extended to:
広がっています:
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
*(SEMI refer-param)
refer-param = generic-param / feature-param
特徴paramを参照している=(/「r」について「言及する」)HCOLON(名前addr / addr仕様)*(SEMIは-paramに参照する)=ジェネリック-param/paramを参照してください。
where feature-param is defined in Section 9 of RFC 3840 [4].
特徴-paramがRFC3840[4]のセクション9で定義されるところ。
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パラメタではなく、ヘッダーパラメタです。
4. Examples
4. 例
4.1. isfocus Feature Tag Usage
4.1. isfocus Feature Tag Usage
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:
以下の例はREFER-発行人がREFER-目標がINVITEがREFER-受取人を連れて来る会議焦点とその結果、その発信であるとREFER-受取人に言うのにどう"isfocus"特徴タグを使用できるかを会議に示しています:
Refer-To: sip:conf44@example.com;isfocus
To:を参照します。 一口: conf44@example.com;isfocus
4.2. Voice and Video Feature Tags Usage
4.2. 声とビデオ特徴タグ用法
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-目標が、オーディオ、ビデオ、およびその結果それがビデオであるとサポートして、REFER-目標にINVITEを送ることによってオーディオセッションは確立できるとどうREFER受取人に言うことができるかを以下の例は示しています:
Refer-To: "Alice's Videophone" <sip:alice@videophone.example.com>
;audio;video
To:を参照します。 <一口: 「アリスのテレビ電話」 alice@videophone.example.com 、gt;、; オーディオ;ビデオ
4.3. Example with URI parameters and multiple feature tags
4.3. URIパラメタと複数の特徴タグがある例
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-発行人がどうREFER受取人に言うことができるかに示します。それがヘッダーパラメタとして解釈されないように、輸送URIパラメタが"<"と">"の中に同封されることに注意してください。
Standards Track [Page 3]
RFC 4508 Feature Tags with SIP REFER May 2006
一口がある標準化過程[3ページ]RFC4508特徴タグは2006年5月に参照されます。
Refer-To: <sip:alice-vm@example.com;transport=tcp>
;actor="msg-taker";automata;audio
To:を参照します。 <一口: alice-vm@example.com;transport がtcpと等しい、gt;、;俳優が「msg-受け取り人」; オートマトン; オーディオと等しい
5. Security Considerations
5. セキュリティ問題
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に関する機密情報を提供できます。 そういうものとして、別のものに機密情報を提供することに対するRFC3840警告はパーティーへ行きます。 いったんこの情報を発表すると、それでどんな使用もするかもしれません、この仕様のように第三者にリレーするのを含んでいて。
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 SHOULDに特徴タグを含んでいて、代わりに、認証されて安全なメソッド(OPTIONS応答、または、対話におけるリモート目標URIからの)で直接REFER-目標から発見されてください。
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-発行人が中に含んでいるRECOMMENDEDである、Refer、-、すべての特徴がタグ付けをする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-受取人がそうするために直接aの上のREFER-目標にOPTIONS質問を安全な状態で送ることができる、(例えば、互いに認証されていて保全で保護される、)、接続。 これは不正確であるか悪意がある特徴タグの発信に対してREFER-受取人を保護します。
6. Acknowledgements
6. 承認
The authors would like to thank Jonathan Rosenberg for providing helpful guidance to this work.
作者は、役立っている指導をこの仕事に提供して頂いて、ジョナサン・ローゼンバーグに感謝したがっています。
7. Normative References
7. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[3] スパークス、R.、「セッション開始プロトコル(一口)はメソッドを参照する」RFC3515、2003年4月。
Standards Track [Page 4]
RFC 4508 Feature Tags with SIP REFER May 2006
一口がある標準化過程[4ページ]RFC4508特徴タグは2006年5月に参照されます。
[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、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
Authors' Addresses
作者のアドレス
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Oritレヴィンマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
Phone: 425-722-2225 EMail: oritl@microsoft.com
以下に電話をしてください。 425-722-2225 メールしてください: oritl@microsoft.com
Alan Johnston Avaya St. Louis, MO 63124
アラン・ジョンストン・Avayaセントルイス、MO 63124
EMail: ajohnston@ipstation.com
メール: ajohnston@ipstation.com
Standards Track [Page 5]
RFC 4508 Feature Tags with SIP REFER May 2006
一口がある標準化過程[5ページ]RFC4508特徴タグは2006年5月に参照されます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Standards Track [Page 6]
標準化過程[6ページ]
一覧
スポンサーリンク
