RFC 7647 - Clarifications for the Use of REFER with RFC 6665 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7647
タイトル : RFC 7647 - RFC 6665でのREFERの使用に関する説明
翻訳編集 : 自動生成

[要約] RFC 7647は、RFC 6665とのREFERの使用に関する明確化を提供するものであり、要約すると以下のようになります。1. RFC 7647は、RFC 6665で定義されたREFERメソッドの使用に関する誤解や不明点を解消するために作成されました。 2. このRFCの目的は、REFERメソッドの使用に関する明確なガイドラインを提供し、インターオペラビリティを向上させることです。 3. RFC 7647は、REFERメソッドの使用に関する実装者や開発者の理解を深めるための情報源として役立ちます。

Internet Engineering Task Force (IETF)                         R. Sparks
Request for Comments: 7647                                        Oracle
Updates: 3515                                                 A.B. Roach
Category: Standards Track                                        Mozilla
ISSN: 2070-1721                                           September 2015

Clarifications for the Use of REFER with RFC 6665

RFC 6665でのREFERの使用に関する説明

Abstract

概要

The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes.

SIP REFERメソッドは、SIP固有のイベント通知フレームワークに依存しています。このフレームワークは、RFC 6665によって改訂されました。このドキュメントでは、RFC 6665の要件変更の影響を強調し、RFC 3515で説明されているREFERメソッドの定義を更新して、これらの変更の影響を明確にし、明確にします。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7647.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7647で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   2
   3.  Use of GRUU Is Mandatory  . . . . . . . . . . . . . . . . . .   3
   4.  Dialog Reuse Is Prohibited  . . . . . . . . . . . . . . . . .   3
   5.  The 202 Response Code Is Deprecated . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction

1. はじめに

The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by [RFC6665]. This document highlights the implications of the requirement changes in RFC 6665, and updates [RFC3515] to clarify and disambiguate the impact of those changes.

SIP REFERメソッドは、SIP固有のイベント通知フレームワークに依存しています。そのフレームワークは[RFC6665]によって改訂されました。このドキュメントは、RFC 6665の要件変更の影響を強調し、[RFC3515]を更新して、これらの変更の影響を明確にし、明確化します。

Accepting a REFER request (without invoking extensions) results in an implicit SIP-Events subscription. If that REFER was part of an existing dialog, the implicit subscription creates a new, problematic dialog usage within that dialog [RFC5057]. The "norefersub" extension defined in [RFC4488] asks to suppress this implicit subscription, but cannot prevent its creation.

（拡張機能を呼び出さずに）REFER要求を受け入れると、暗黙のSIP-Eventsサブスクリプションが発生します。そのREFERが既存のダイアログの一部であった場合、暗黙のサブスクリプションにより、そのダイアログ内に問題のある新しいダイアログの使用法が作成されます[RFC5057]。 [RFC4488]で定義されている「norefersub」拡張は、この暗黙のサブスクリプションを抑制するよう要求しますが、その作成を防ぐことはできません。

There are implementations in some known specialized environments (such as 3GPP) that use out-of-signaling agreements to ensure that in-dialog REFER requests using the RFC 4488 extension do not create a new subscription inside that dialog. In the 3GPP environment, the behavior is based on capabilities advertised using media feature tags. That mechanism does not, however, prevent additional dialog usages when interoperating with implementations that do not support the mechanism. The extensions in [RFC7614] provide a standardized mechanism that allows avoiding any additional dialog usage.

RFC 4488拡張を使用したダイアログ内のREFER要求がそのダイアログ内に新しいサブスクリプションを作成しないようにするために、アウトオブシグナル契約を使用する一部の既知の特殊環境（3GPPなど）に実装があります。 3GPP環境では、動作はメディア機能タグを使用してアドバタイズされる機能に基づいています。ただし、このメカニズムは、メカニズムをサポートしていない実装と相互運用するときに、追加のダイアログの使用を妨げません。 [RFC7614]の拡張機能は、追加のダイアログの使用を回避できる標準化されたメカニズムを提供します。

2. Conventions Used in This Document

2. このドキュメントで使用される規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Use of GRUU Is Mandatory

3. GRUUの使用は必須です

Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory for notifiers to implement and use as the local target in the subscription created by the REFER request.

[RFC6665]のセクション4.5.1では、通知者がREFERリクエストによって作成されたサブスクリプションのローカルターゲットとして実装および使用するためにGRUU [RFC5627]が必須となっています。

A user agent (UA) accepting a REFER that creates a subscription MUST populate its Contact header field with a GRUU.

サブスクリプションを作成するREFERを受け入れるユーザーエージェント（UA）は、そのコンタクトヘッダーフィールドにGRUUを設定する必要があります。

A UA that might possibly become a notifier (e.g., by accepting a REFER request that creates a subscription) needs to include a GRUU in the Contact header field of dialog-forming and target-refresh methods (such as INVITE) [RFC7621]. This ensures that out-of-dialog REFER requests corresponding to any resulting INVITE dialogs arrive at this UA. Extensions can relax this requirement by defining a REFER request that cannot create an implicit subscription, thus not causing the accepting UA to become an RFC 6665 notifier in the context of this dialog. [RFC7614] is an example of such an extension.

（たとえば、サブスクリプションを作成するREFERリクエストを受け入れることによって）通知機能になる可能性のあるUAは、ダイアログ形成およびターゲット更新メソッド（INVITEなど）のContactヘッダーフィールドにGRUUを含める必要があります[RFC7621]。これにより、結果のINVITEダイアログに対応するダイアログ外のREFER要求がこのUAに確実に到着します。拡張機能は、暗黙のサブスクリプションを作成できないREFER要求を定義することにより、この要件を緩和できます。これにより、受け入れ中のUAがこのダイアログのコンテキストでRFC 6665通知になりません。 [RFC7614]はそのような拡張の例です。

4. Dialog Reuse Is Prohibited

4. ダイアログの再利用は禁止されています

If a peer in an existing dialog has provided a GRUU as its Contact, sending a REFER that might result in an additional dialog usage within that dialog is prohibited. This is a direct consequence of [RFC6665] requiring the use of GRUU and the requirements in Section 4.5.2 of that document.

既存のダイアログのピアが連絡先としてGRUUを提供している場合、そのダイアログ内で追加のダイアログ使用が発生する可能性のあるREFERを送信することは禁止されています。これは、GRUUの使用を要求する[RFC6665]とそのドキュメントのセクション4.5.2の要件の直接的な帰結です。

A user agent constructing a REFER request that could result in an implicit subscription in a dialog MUST build it as an out-of-dialog message as defined in [RFC3261], unless the remote endpoint is an older implementation of RFC 3515 that has not been updated to conform to RFC 6665 (as determined by the absence of a GRUU in the remote target). Thus, the REFER request will have no tag parameter in its To: header field.

リモートエンドポイントがRFC 3515の古い実装でない限り、[RFC3261]で定義されているように、ダイアログで暗黙のサブスクリプションを引き起こす可能性のあるREFERリクエストを作成するユーザーエージェントは、それをダイアログ外メッセージとして構築する必要があります。 RFC 6665に準拠するように更新されました（リモートターゲットにGRUUがないことで決定されます）。したがって、REFERリクエストのTo：ヘッダーフィールドにはタグパラメータがありません。

Using the "norefersub" option tag [RFC4488] does not change this requirement, even if used in a "Require" header field. Even if the recipient supports the "norefersub" mechanism, and accepts the request with the option tag in the "Require" header field, it is allowed to return a "Refer-Sub" header field with a value of "true" in the response, and create an implicit subscription.

「norefersub」オプションタグ[RFC4488]を使用しても、「Require」ヘッダーフィールドで使用されていても、この要件は変更されません。受信者が「norefersub」メカニズムをサポートし、「必須」ヘッダーフィールドにオプションタグを含むリクエストを受け入れる場合でも、応答で「true」の値を持つ「Refer-Sub」ヘッダーフィールドを返すことが許可されます、暗黙的なサブスクリプションを作成します。

A user agent wishing to identify an existing dialog (such as for call transfer as defined in [RFC5589]) MUST use the "Target-Dialog" extension defined in [RFC4538] to do so, and user agents accepting REFER MUST be able to process that extension in requests they receive.

既存のダイアログ（[RFC5589]で定義されているコール転送など）を識別したいユーザーエージェントは、[RFC4538]で定義されている「Target-Dialog」拡張を使用して識別しなければならず、REFERを受け入れるユーザーエージェントは処理できる必要があります。彼らが受け取る要求のその拡張。

If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [RFC7614]), the REFER request MAY be sent within an existing dialog (whether or not the remote target is a GRUU). Such a REFER will be constructed with its Contact header field populated with the dialog's local URI as specified in Section 12 of [RFC3261].

ユーザーエージェントが、REFERリクエストの送信の結果として暗黙のサブスクリプションが作成されないことを確認できる場合（そのようなサブスクリプションを許可しない拡張を要求することなどにより[RFC7614]）、REFERリクエストは既存のダイアログ内で送信できます（リモートターゲットがGRUUかどうか）。このようなREFERは、[RFC3261]のセクション12で指定されているダイアログのローカルURIが入力された連絡先ヘッダーフィールドで構築されます。

As described in Section 4.5.2 of [RFC6665], there are cases where a user agent may fall back to sharing existing dialogs for backwards-compatibility purposes. This applies to a REFER only when the peer has not provided a GRUU as its Contact in the existing dialog (i.e., when the peer is an implementation of RFC 3515 that has not been updated to conform with RFC 6665).

[RFC6665]のセクション4.5.2で説明されているように、ユーザーエージェントは、下位互換性のために既存のダイアログの共有にフォールバックする場合があります。これは、ピアが既存のダイアログで連絡先としてGRUUを提供していない場合（つまり、ピアがRFC 6665に準拠するように更新されていないRFC 3515の実装である場合）にのみREFERに適用されます。

5. The 202 Response Code Is Deprecated

5. 202応答コードは廃止予定

Section 8.3.1 of [RFC6665] requires that elements not send a 202 response code to a subscribe request, but use the 200 response code instead. Any 202 response codes received to a subscribe request are treated as 200s. These changes also apply to REFER. Specifically, an element accepting a REFER request MUST NOT reply with a 202 response code and MUST treat any 202 responses received as identical to a 200 response. Wherever [RFC3515] requires sending a 202 response code, a 200 response code MUST be sent instead.

[RFC6665]のセクション8.3.1では、要素がサブスクライブリクエストに202応答コードを送信せず、代わりに200応答コードを使用することが要求されています。サブスクライブ要求に対して受信された202応答コードは、200として扱われます。これらの変更はREFERにも適用されます。具体的には、REFER要求を受け入れる要素は、202応答コードで応答してはならず（MUST）、受信した202応答を200応答と同一として処理しなければなりません（MUST）。 [RFC3515]が202応答コードを送信する必要がある場合は常に、代わりに200応答コードを送信する必要があります。

6. Security Considerations

6. セキュリティに関する考慮事項

This document introduces no new security considerations directly. The updated considerations in [RFC6665] apply to the implicit subscription created by an accepted REFER request.

このドキュメントでは、セキュリティに関する新しい考慮事項を直接紹介していません。 [RFC6665]の更新された考慮事項は、受け入れられたREFER要求によって作成された暗黙のサブスクリプションに適用されます。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.

[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。

[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.

[RFC3515] Sparks、R。、「Session Initiation Protocol（SIP）Refer Method」、RFC 3515、DOI 10.17487 / RFC3515、2003年4月、<http://www.rfc-editor.org/info/rfc3515>。

[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, DOI 10.17487/RFC4538, June 2006, <http://www.rfc-editor.org/info/rfc4538>.

[RFC4538] Rosenberg、J。、「Session Initiation Protocol（SIP）でのダイアログ識別によるリクエスト承認」、RFC 4538、DOI 10.17487 / RFC4538、2006年6月、<http://www.rfc-editor.org/info/ rfc4538>。

[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <http://www.rfc-editor.org/info/rfc5627>.

[RFC5627] Rosenberg、J。、「Session Initiation Protocol（SIP）でグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得して使用する」、RFC 5627、DOI 10.17487 / RFC5627、2009年10月、<http：//www.rfc- editor.org/info/rfc5627>。

[RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, DOI 10.17487/RFC6665, July 2012, <http://www.rfc-editor.org/info/rfc6665>.

[RFC6665] Roach、A.B。、「SIP固有のイベント通知」、RFC 6665、DOI 10.17487 / RFC6665、2012年7月、<http://www.rfc-editor.org/info/rfc6665>。

[RFC7621] Roach, A.B., "A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework", RFC 7621, DOI 10.17487/RFC7621, August 2015, <http://www.rfc-editor.org/info/rfc7621>.

[RFC7621]ローチ、AB、「SIPイベント通知フレームワークにおけるグローバルにルーティング可能なユーザーエージェントURI（GRUU）の使用に関する説明」、RFC 7621、DOI 10.17487 / RFC7621、2015年8月、<http：//www.rfc- editor.org/info/rfc7621>。

7.2. Informative References

7.2. 参考引用

[RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, DOI 10.17487/RFC4488, May 2006, <http://www.rfc-editor.org/info/rfc4488>.

[RFC4488] Levin、O。、「Suppression of Session Initiation Protocol（SIP）REFER Method Implicit Subscription」、RFC 4488、DOI 10.17487 / RFC4488、2006年5月、<http://www.rfc-editor.org/info/rfc4488 >。

[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057, November 2007, <http://www.rfc-editor.org/info/rfc5057>.

[RFC5057] Sparks、R。、「セッション開始プロトコルでの複数ダイアログの使用」、RFC 5057、DOI 10.17487 / RFC5057、2007年11月、<http://www.rfc-editor.org/info/rfc5057>。

[RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, <http://www.rfc-editor.org/info/rfc5589>.

[RFC5589] Sparks、R.、Johnston、A.、Ed。、およびD. Petrie、「Session Initiation Protocol（SIP）Call Control-Transfer」、BCP 149、RFC 5589、DOI 10.17487 / RFC5589、2009年6月、<http ：//www.rfc-editor.org/info/rfc5589>。

[RFC7614] Sparks, R., "Explicit Subscriptions for the REFER Method", RFC 7614, DOI 10.17487/RFC7614, August 2015, <http://www.rfc-editor.org/info/rfc7614>.

[RFC7614] Sparks、R。、「REFERメソッドの明示的なサブスクリプション」、RFC 7614、DOI 10.17487 / RFC7614、2015年8月、<http://www.rfc-editor.org/info/rfc7614>。

Acknowledgements

謝辞

Christer Holmberg provided the formulation for the final paragraph of the introduction. Christer Holmberg and Ivo Sedlacek provided detailed comments during working group discussion of the document.

Christer Holmbergが序論の最後の段落の定式化を提供しました。 Christer HolmbergとIvo Sedlacekは、文書のワーキンググループディスカッション中に詳細なコメントを提供しました。

Authors' Addresses

著者のアドレス

Robert Sparks Oracle 7460 Warren Parkway Suite 300 Frisco, Texas 75034 United States

Robert Sparks Oracle 7460 Warren Parkway Suite 300フリスコ、テキサス75034アメリカ合衆国

   Email: rjsparks@nostrum.com

Adam Roach Mozilla Dallas, TX United States

Adam Roach Mozillaダラス、テキサス州アメリカ合衆国

   Phone: +1 650 903 0800 x863
   Email: adam@nostrum.com