[要約] RFC 6809は、SIPセッションの機能と機能のサポートを示すためのメカニズムを提供します。その目的は、SIPクライアントとサーバーが互いの機能と互換性を確認し、適切なセッションを確立することです。
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6809 I. Sedlacek
Category: Standards Track Ericsson
ISSN: 2070-1721 H. Kaplan
Acme Packet
November 2012
Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）で機能と機能のサポートを示すメカニズム
Abstract
概要
This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.
この仕様では、新しいSIPヘッダーフィールドであるFeature-Capsを定義しています。 Feature-Capsヘッダーフィールドは、ContactヘッダーフィールドのUniform Resource Identifier（URI）で表されないSIPエンティティの機能と機能のサポートを示すために使用される機能能力インジケーターを伝えます。
SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.
SIP ContactヘッダーフィールドのURIで表されるSIPエンティティは、Contactヘッダーフィールドでメディア機能タグを伝達して、機能と機能のサポートを示すことができます。
This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators.
この仕様では、機能能力インジケーターを定義し、機能能力インジケーターを登録するための新しいIANAレジストリー「Proxy-Feature Feature-Capability Indicator Trees」を作成します。
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/rfc6809.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6809で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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 ....................................................3
2. Conventions .....................................................4
3. Definitions .....................................................4
4. Feature-Caps Header Field .......................................4
4.1. Introduction ...............................................4
4.2. User Agent and Proxy Behavior ..............................4
4.2.1. General .............................................4
4.2.2. B2BUA Behavior ......................................5
4.2.3. Registrar Behavior ..................................6
4.2.4. Proxy Behavior ......................................6
4.3. SIP Message Type and Response Code Semantics ...............7
4.3.1. General .............................................7
4.3.2. SIP Dialog ..........................................7
4.3.3. SIP Registration (REGISTER) .........................7
4.3.4. SIP Standalone Transactions .........................8
5. Feature-Capability Indicators ...................................8
5.1. Introduction ...............................................8
5.2. Registration Trees .........................................9
5.2.1. General .............................................9
5.2.2. Global Tree .........................................9
5.2.3. SIP Tree ............................................9
5.3. Feature-Capability Indicator Specification Requirements ...10
5.3.1. General ............................................10
5.3.2. Overall Description ................................10
5.3.3. Feature-Capability Indicator Values ................10
5.3.4. Usage Restrictions .................................11
5.3.5. Interoperability Considerations ....................11
5.3.6. Security Considerations ............................11
5.3.7. Examples ...........................................12
5.3.8. Other Information ..................................12
6. Syntax .........................................................12
6.1. General ...................................................12
6.2. Syntax: Feature-Caps Header Field .........................12
6.2.1. ABNF ...............................................12
6.3. Syntax: Feature-Capability Indicator ......................12
6.3.1. General ............................................12
6.3.2. ABNF ...............................................13
7. IANA Considerations ............................................13
7.1. Registration of the Feature-Caps Header Field .............13
7.2. Registration of the Feature-Caps Header Field Parameter ...13
7.3. Proxy-Feature Feature-Capability Indicator Trees ..........14
7.3.1. Introduction .......................................14
7.3.2. Global Feature-Capability Indicator
Registration Tree ..................................14
7.3.3. SIP Feature-Capability Indicator
Registration Tree ..................................15
8. Feature-Capability Indicator Registration Template .............16
9. Security Considerations ........................................17
10. Acknowledgements ..............................................17
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................18
The Session Initiation Protocol (SIP) [RFC3261] extension for indicating User Agent (UA) capabilities, defined in RFC 3840 [RFC3840], provides a mechanism that allows a SIP message to convey information relating to the originator's features and capabilities, using the Contact header field.
RFC 3840 [RFC3840]で定義されている、ユーザーエージェント（UA）機能を示すためのセッション開始プロトコル（SIP）[RFC3261]拡張は、連絡先を使用して、SIPメッセージが発信者の機能および機能に関する情報を伝達できるようにするメカニズムを提供します。ヘッダーフィールド。
This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field. Such cases are:
この仕様では、新しいSIPヘッダーフィールドであるFeature-Capsを定義しています。 Feature-Capsヘッダーフィールドは、ContactヘッダーフィールドのUniform Resource Identifier（URI）で表されないSIPエンティティの機能と機能のサポートを示すために使用される機能能力インジケーターを伝えます。そのようなケースは次のとおりです。
o The SIP entity acts as a SIP proxy.
o SIPエンティティはSIPプロキシとして機能します。
o The SIP entity acts as a SIP registrar.
o SIPエンティティは、SIPレジストラとして機能します。
o The SIP entity acts as a Back-to-Back User Agent (B2BUA) [RFC3261], where the Contact header field URI represents another SIP entity.
o SIPエンティティは、Back-to-Back User Agent（B2BUA）[RFC3261]として機能し、ContactヘッダーフィールドURIは別のSIPエンティティを表します。
SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.
SIP ContactヘッダーフィールドのURIで表されるSIPエンティティは、Contactヘッダーフィールドでメディア機能タグを伝達して、機能と機能のサポートを示すことができます。
Unlike media feature tags, feature-capability indicators are intended to only be used with SIP.
メディア機能タグとは異なり、機能機能インジケータはSIPでのみ使用することを目的としています。
This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators.
この仕様では、機能能力インジケーターを定義し、機能能力インジケーターを登録するための新しいIANAレジストリー「Proxy-Feature Feature-Capability Indicator Trees」を作成します。
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 BCP 14, RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [RFC2119]で説明されているように解釈されます。
Downstream SIP entity: SIP entity in the direction towards which a SIP request is sent.
ダウンストリームSIPエンティティ：SIP要求が送信される方向のSIPエンティティ。
Upstream SIP entity: SIP entity in the direction from which a SIP request is received.
アップストリームSIPエンティティ：SIP要求を受信する方向のSIPエンティティ。
The Feature-Caps header field is used by SIP entities to convey support of features and capabilities, by setting feature-capability indicators. A feature-capability indicator conveyed in a Feature-Caps header field indicates that a SIP entity in the SIP message signaling path supports the associated feature and capability.
Feature-Capsヘッダーフィールドは、SIPエンティティが、機能能力インジケーターを設定することにより、機能と機能のサポートを伝えるために使用されます。 Feature-Capsヘッダーフィールドで伝えられる機能機能インジケータは、SIPメッセージシグナリングパスのSIPエンティティが関連する機能と機能をサポートしていることを示します。
If the URI in a Contact header field of a request or response represents a SIP entity, the entity MUST NOT indicate supported features and capabilities using a Feature-Caps header field within that request or response.
要求または応答のContactヘッダーフィールドのURIがSIPエンティティを表す場合、エンティティは、その要求または応答内のFeature-Capsヘッダーフィールドを使用して、サポートされている機能を示してはなりません（MUST NOT）。
When a SIP entity receives a SIP request, or response, that contains one or more Feature-Caps header fields, the feature-capability indicators in the header field inform the entity about the features and capabilities supported by entities in the SIP message signaling path. The procedure by which features and capabilities are invoked are outside the scope of this specification and MUST be described by individual feature-capability indicator specifications.
SIPエンティティが1つ以上のFeature-Capsヘッダーフィールドを含むSIP要求または応答を受信すると、ヘッダーフィールドの機能機能インジケーターは、SIPメッセージシグナリングパスのエンティティによってサポートされる機能と機能についてエンティティに通知します。機能と機能が呼び出される手順は、この仕様の範囲外であり、個々の機能能力インジケーター仕様によって記述されなければなりません。
A Feature-Caps header field value cannot convey the address of the SIP entity that inserted the Feature-Caps header field. If additional data about a supported feature needs to be conveyed, such as the address of the SIP entity that indicated support of the feature, then the feature definition needs to define a way to convey that information as a value of the associated feature-capability indicator.
Feature-Capsヘッダーフィールドの値は、Feature-Capsヘッダーフィールドを挿入したSIPエンティティのアドレスを伝達できません。機能のサポートを示したSIPエンティティのアドレスなど、サポートされている機能に関する追加のデータを伝達する必要がある場合、機能定義では、その情報を関連する機能能力インジケータの値として伝達する方法を定義する必要があります。 。
When a SIP entity adds a Feature-Caps header field to a SIP message, it MUST place the header field before any existing Feature-Caps header field in the message to be forwarded, so that the added header field becomes the top-most one. Then, when another SIP entity receives a SIP request or the response, the SIP feature-capability indicators in the top-most Feature-Caps header field will represent the supported features and capabilities "closest", from a SIP signaling point of view, to the entity.
SIPエンティティは、SIPメッセージにFeature-Capsヘッダーフィールドを追加するときに、転送されるメッセージ内の既存のFeature-Capsヘッダーフィールドの前にヘッダーフィールドを配置する必要があります。これにより、追加されたヘッダーフィールドが最上位になります。次に、別のSIPエンティティがSIP要求または応答を受信すると、最上位のFeature-CapsヘッダーフィールドのSIP機能機能インジケータは、SIPシグナリングの観点から、「最も近い」サポートされている機能と機能を表します。エンティティ。
Based on features and policies, a SIP entity MAY remove a Feature-Caps header field from a SIP message. Also, a SIP entity MAY remove a feature-capability indicator from a Feature-Caps header field within a SIP message. A SIP entity SHOULD NOT re-order the Feature-Caps header fields within a SIP message.
機能とポリシーに基づいて、SIPエンティティは、SIPメッセージからFeature-Capsヘッダーフィールドを削除する場合があります。また、SIPエンティティは、SIPメッセージ内のFeature-Capsヘッダーフィールドから機能能力インジケーターを削除してもよい（MAY）。 SIPエンティティは、SIPメッセージ内のFeature-Capsヘッダーフィールドを並べ替えるべきではありません（SHOULD NOT）。
For a given fc-value, as defined in Section 6.2.1, the order in which feature-capability indicators are listed has no significance. For example, "foo;bar" and "bar;foo" have the same meaning (i.e., that the SIP entity that inserted the feature-capability indicator supports the features and capabilities associated with the "foo" and "bar" feature-capability indicators).
セクション6.2.1で定義されている特定のfc値に対して、機能能力インジケーターがリストされている順序は重要ではありません。たとえば、「foo; bar」と「bar; foo」は同じ意味です（つまり、機能能力インジケーターを挿入したSIPエンティティは、「foo」と「bar」機能機能に関連付けられた機能をサポートします。指標）。
The procedures in this section apply to User Agents (UAs) [RFC3261] that are part of B2BUAs that are referenced in the message by a Record-Route header field rather than by the URI of the Contact header field.
このセクションの手順は、ContactヘッダーフィールドのURIではなくRecord-Routeヘッダーフィールドによってメッセージで参照されるB2BUAの一部であるユーザーエージェント（UA）[RFC3261]に適用されます。
When such a UA sends a SIP request, if the UA wants to indicate support of features and capabilities towards its downstream SIP entities, it inserts a Feature-Caps header field in the request, containing one or more feature-capability indicators associated with the supported features and capabilities, before it forwards the request.
そのようなUAがSIPリクエストを送信するとき、UAがその機能と機能のサポートをダウンストリームSIPエンティティに向けて表示したい場合、リクエストにFeature-Capsヘッダーフィールドを挿入します。リクエストを転送する前の機能と機能。
If the SIP request is triggered by another SIP request that the B2BUA has received, the UA MAY forward received Feature-Caps header fields by copying them to the outgoing SIP request, similar to a SIP proxy, before it inserts its own Feature-Caps header field in the SIP request.
B2BUAが受信した別のSIP要求によってSIP要求がトリガーされた場合、UAは独自のFeature-Capsヘッダーを挿入する前に、受信したFeature-Capsヘッダーフィールドを、SIPプロキシと同様に発信SIP要求にコピーして転送できます（MAY）。 SIPリクエストのフィールド。
When such a UA receives a SIP response, if the UA wants to indicate support of features and capabilities towards its upstream SIP entities, it inserts a Feature-Caps header field in the response, containing one or more feature-capability indicators associated with the supported features and capabilities, before it forwards the response.
そのようなUAがSIP応答を受信すると、UAが上流のSIPエンティティに対する機能と機能のサポートを示す場合、サポートされているに関連付けられている1つ以上の機能機能インジケーターを含むFeature-Capsヘッダーフィールドを応答に挿入します。応答を転送する前の機能と機能。
If the SIP response is triggered by another SIP response that the B2BUA has received, the UA MAY forward received Feature-Caps header fields by copying them to the outgoing SIP response, similar to a SIP proxy, before it inserts its own Feature-Caps header field in the SIP response.
B2BUAが受信した別のSIP応答によってSIP応答がトリガーされた場合、UAは、独自のFeature-Capsヘッダーを挿入する前に、受信したFeature-Capsヘッダーフィールドを、SIPプロキシと同様に発信SIP応答にコピーして転送できます（MAY）。 SIP応答のフィールド。
If a SIP registrar wants to indicate support of features and capabilities towards its upstream SIP entities, it inserts a Feature-Caps header field, containing one or more feature-capability indicators associated with the supported features and capabilities, in a REGISTER response.
SIPレジストラがアップストリームSIPエンティティに対する機能と機能のサポートを示す必要がある場合は、サポートされている機能と機能に関連付けられた1つ以上の機能機能インジケータを含むFeature-CapsヘッダーフィールドをREGISTER応答に挿入します。
When a SIP proxy receives a SIP request, if the proxy wants to indicate support of features and capabilities towards its downstream SIP entities, it inserts a Feature-Caps header field in the request, containing one or more SIP feature-capability indicators associated with the supported features and capabilities, before it forwards the request.
SIPプロキシがSIP要求を受信すると、プロキシがそのダウンストリームSIPエンティティに対する機能と機能のサポートを示す場合、要求にFeature-Capsヘッダーフィールドを挿入します。このフィールドには、リクエストを転送する前のサポートされている機能。
When a proxy receives a SIP response, if the proxy wants to indicate support of features and capabilities towards its upstream SIP entities, it inserts a Feature-Caps header field in the response, containing one or more SIP feature-capability indicators associated with the supported features and capabilities, before it forwards the response.
プロキシがSIP応答を受信すると、プロキシがそのアップストリームSIPエンティティに対する機能と機能のサポートを示す必要がある場合、サポートされる機能に関連付けられた1つ以上のSIP機能機能インジケーターを含むFeature-Capsヘッダーフィールドを応答に挿入します。応答を転送する前の機能と機能。
This section describes the general usage and semantics of the Feature-Caps header field for different SIP message types and response codes.
このセクションでは、さまざまなSIPメッセージタイプと応答コードのFeature-Capsヘッダーフィールドの一般的な使用法とセマンティクスについて説明します。
Section 6.2.1 defines the Feature-Caps header field ABNF.
セクション6.2.1は、Feature-CapsヘッダーフィールドABNFを定義します。
The Feature-Caps header field can be used within an initial SIP request for a dialog, within a target refresh SIP request, and within any 18x or 2xx response associated with such requests.
Feature-Capsヘッダーフィールドは、ダイアログの初期SIPリクエスト内、ターゲットリフレッシュSIPリクエスト内、およびそのようなリクエストに関連付けられた18xまたは2xx応答内で使用できます。
If a feature-capability indicator is inserted in a Feature-Caps header field of an initial request for a dialog, or within a response of such a request, it indicates to the receivers of the request (or response) that the feature associated with the feature-capability indicator is supported for the duration of the dialog, until a target refresh request is sent for the dialog, or until the dialog is terminated.
ダイアログの最初の要求のFeature-Capsヘッダーフィールドに、またはそのような要求の応答内に機能能力インジケーターが挿入されている場合、それは、要求（または応答）の受信者に、機能能力インジケーターは、ダイアログのターゲットリフレッシュリクエストが送信されるまで、またはダイアログが終了するまで、ダイアログの期間中サポートされます。
Unless a feature-capability indicator is inserted in a Feature-Caps header field of a target refresh request, or within a response of such a request, it indicates to the receivers of the request (or response) that the feature is no longer supported for the dialog.
機能能力インジケーターがターゲットリフレッシュ要求のFeature-Capsヘッダーフィールドに挿入されていないか、そのような要求の応答内に挿入されていない限り、その機能がサポートされなくなったことを要求（または応答）の受信者に示しますダイアログ。
For a given dialog, a SIP entity MUST insert the same feature-capability indicators in all 18x and 2xx responses associated with a given transaction.
特定のダイアログでは、SIPエンティティは、特定のトランザクションに関連付けられたすべての18xおよび2xx応答に同じ機能能力インジケータを挿入する必要があります。
As it cannot be guaranteed that 2xx responses associated with SIP SUBSCRIBE requests will reach the User Agent Client (UAC) [RFC3261], due to forking of the request, entities need to indicate supported features and capabilities in the SIP NOTIFY request that will be sent for each of the created subscription dialogs.
SIP SUBSCRIBEリクエストに関連付けられた2xx応答がユーザーエージェントクライアント（UAC）[RFC3261]に到達することは保証できないため、エンティティは、送信されるSIP NOTIFYリクエストでサポートされる機能と機能を示す必要があります。作成されたサブスクリプションダイアログごとに。
The Feature-Caps header field can be used within a SIP REGISTER request and within the 200 (OK) response associated with such a request.
Feature-Capsヘッダーフィールドは、SIP REGISTER要求内およびそのような要求に関連付けられた200（OK）応答内で使用できます。
If a feature-capability indicator is conveyed in a Feature-Caps header field of a REGISTER request, or within an associated response, it indicates to the receivers of the message that the feature associated with the feature-capability indicator is supported for the registration, until the registration of the contact that was explicitly conveyed in the REGISTER request expires, or until the registered contact is explicitly refreshed and the refresh REGISTER request does not contain the feature-capability indicator associated with the feature.
機能能力インジケーターがREGISTER要求のFeature-Capsヘッダーフィールドで、または関連付けられた応答内で伝達される場合、その機能能力インジケーターに関連付けられた機能が登録でサポートされていることをメッセージの受信者に示します。 REGISTER要求で明示的に伝えられた連絡先の登録の有効期限が切れるまで、または登録された連絡先が明示的に更新され、更新REGISTER要求に、機能に関連付けられた機能機能インジケータが含まれないまで。
While a REGISTER response can contain contacts that have been registered as part of other registration transactions, support of any indicated feature only applies to requests sent to the contact(s) that were explicitly conveyed in the associated REGISTER request.
REGISTER応答には他の登録トランザクションの一部として登録された連絡先を含めることができますが、示された機能のサポートは、関連するREGISTER要求で明示的に伝えられた連絡先に送信された要求にのみ適用されます。
This specification does not define any semantics for usage of the Feature-Caps header field in pure registration binding fetching messages (see Section 10.2.3 of RFC 3261), where the REGISTER request does not contain a Contact header field. Unless such semantics are defined in a future extension, fetching messages will not have any impact on previously indicated support of features and capabilities, and SIP entities MUST NOT insert a Feature-Caps header field in such messages.
この仕様では、REGISTERリクエストにContactヘッダーフィールドが含まれていない純粋な登録バインディングフェッチメッセージ（RFC 3261のセクション10.2.3を参照）でFeature-Capsヘッダーフィールドを使用するためのセマンティクスは定義されていません。そのようなセマンティクスが将来の拡張で定義されない限り、メッセージのフェッチは、以前に示された機能と機能のサポートに影響を与えません。また、SIPエンティティは、そのようなメッセージにFeature-Capsヘッダーフィールドを挿入してはなりません。
If SIP outbound [RFC5626] is used, the rules above apply. However, supported features and capabilities only apply for the registration flow on which support has been explicitly indicated.
SIPアウトバウンド[RFC5626]を使用する場合は、上記のルールが適用されます。ただし、サポートされる機能は、サポートが明示的に示されている登録フローにのみ適用されます。
The Feature-Caps header field can be used within a standalone SIP request and within any 2xx response associated with such a request.
Feature-Capsヘッダーフィールドは、スタンドアロンSIPリクエスト内およびそのようなリクエストに関連付けられた2xxレスポンス内で使用できます。
If a feature-capability indicator is inserted in a Feature-Caps header field of a standalone request, or within a response of such a request, it indicates to the receivers of the request (or response) that the feature associated with the feature-capability indicator is supported for the duration of the standalone transaction.
機能機能インジケーターがスタンドアロン要求のFeature-Capsヘッダーフィールドに挿入されている場合、またはそのような要求の応答内に挿入されている場合は、要求（または応答）の受信者に、機能機能に関連付けられている機能があることを示します。インジケーターは、スタンドアロントランザクションの期間中サポートされます。
Feature-capability indicators are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate such support.
機能機能インジケータは、ContactヘッダーフィールドのURIで表されていないSIPエンティティが機能と機能のサポートを示すために使用します。メディア機能タグを使用してそのようなサポートを示すことはできません。
A value, or a list of values, that provides additional information about the supported feature or capability can be associated with a feature-capability indicator.
サポートされている機能または機能に関する追加情報を提供する値または値のリストは、機能機能インジケーターに関連付けることができます。
The following subsections define registration trees, distinguished by the use of faceted names (e.g., names of the form "tree.feature-name"). The registration trees are defined in the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry.
次のサブセクションでは、ファセット名（たとえば、 "tree.feature-name"という形式の名前）を使用して区別される登録ツリーを定義します。登録ツリーは、IANA "Proxy-Feature Feature-Capability Indicator Trees"レジストリで定義されています。
The trees defined herein are similar to the global tree and SIP tree defined for media feature tags, in RFCs 2506 [RFC2506] and 3840 [RFC3840]. Other registration trees are outside the scope of this specification.
ここで定義されているツリーは、RFC 2506 [RFC2506]および3840 [RFC3840]で、メディア機能タグに対して定義されているグローバルツリーおよびSIPツリーに似ています。他の登録ツリーは、この仕様の範囲外です。
In contrast to RFCs 2506 and 3840, this specification only defines a global tree and a SIP tree, as they are the only trees defined in those RFCs that have been used for defining SIP-specific media feature tags.
RFC 2506および3840とは対照的に、この仕様は、グローバルツリーとSIPツリーのみを定義します。これらは、SIP固有のメディア機能タグの定義に使用されたRFCで定義された唯一のツリーであるためです。
When a feature-capability indicator is registered in any registration tree, no leading "+" is used in the registration.
機能機能インジケーターが登録ツリーに登録されている場合、登録では先頭の「+」は使用されません。
The global feature-capability indicator tree is similar to the media feature tag global tree defined in RFC 2506 [RFC2506].
グローバル機能機能インジケーターツリーは、RFC 2506 [RFC2506]で定義されているメディア機能タググローバルツリーに似ています。
A feature-capability indicator in the global tree will be distinguished by the leading facet "g.". An organization can propose either a designation indicative of the feature (e.g., "g.blinktags") or a faceted designation including the organization name (e.g., "g.organization.blinktags").
グローバルツリーの機能能力インジケータは、主要なファセット "g。"によって区別されます。組織は、機能を示す指定（「g.blinktags」など）または組織名を含むファセット指定（たとえば、「g.organization.blinktags」）を提案できます。
The SIP feature-capability indicator tree is similar to the media feature tag SIP tree defined in RFC 3840.
SIP機能機能インジケータツリーは、RFC 3840で定義されているメディア機能タグSIPツリーに似ています。
A feature-capability indicator in the SIP tree will be distinguished by the leading facet "sip.".
SIPツリーの機能機能インジケータは、主要なファセット「sip。」で区別されます。
A feature-capability indicator specification MUST address the issues defined in the following subsections or document why an issue is not applicable for the specific feature-capability indicator. A reference to the specification MUST be provided when the feature-capability indicator is registered with IANA (see Section 8).
機能能力インジケーターの仕様は、以下のサブセクションで定義された問題に対処するか、問題が特定の機能能力インジケーターに該当しない理由を文書化する必要があります。機能能力インジケーターがIANAに登録されている場合は、仕様への参照を提供する必要があります（セクション8を参照）。
It is bad practice for feature-capability indicator specifications to repeat procedures (e.g., general procedures on the usage of the Feature-Caps header field and feature-capability indicators) defined in this specification, unless needed for clarification or emphasis purposes. A feature-capability indicator specification MUST NOT modify the Feature-Caps header field rules and semantics defined in Section 4.
明確化または強調の目的で必要な場合を除き、この仕様で定義されている手順（たとえば、Feature-Capsヘッダーフィールドと機能機能インジケーターの使用に関する一般的な手順）を繰り返すことは、機能機能インジケーター仕様の悪い習慣です。機能能力インジケーターの仕様は、セクション4で定義されているFeature-Capsヘッダーフィールドのルールとセマンティクスを変更してはなりません（MUST NOT）。
A feature-capability indicator specification MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, a specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if features and capabilities associated with the feature-capability indicator require it.
機能能力インジケーター仕様は、この仕様で「SHOULD」または「MUST」で指定された動作を弱めてはなりません。ただし、機能能力インジケーターに関連付けられている機能が必要な場合、仕様は「SHOULD」、「MAY」、または「RECOMMENDED」要件を「MUST」強度に強化する場合があります。
The feature-capability indicator specification MUST contain an overall description of the feature-capability indicator: how it is used to indicate support of a feature, a description of the feature associated with the feature-capability indicator, a description of any additional information (conveyed using one or more feature-capability indicator values) that can be conveyed together with the feature-capability indicator, and a description of how the associated feature MAY be exercised/invoked.
機能能力インジケーターの仕様には、機能能力インジケーターの全体的な説明が含まれている必要があります。それは、機能のサポートを示すためにどのように使用されるか、機能能力インジケーターに関連付けられている機能の説明、追加情報の説明（機能能力インジケーターと一緒に伝達できる1つ以上の機能能力インジケーター値を使用）、および関連する機能がどのように行使/呼び出されるかの説明。
A feature-capability indicator can have an associated value, or a list of values. The feature-capability indicator specification MUST define the syntax and semantics of any value defined for the feature-capability indicator, including possible restrictions related to the usage of a specific value. The feature-capability indicator specification MUST define the value(s) in accordance with the ABNF defined in Section 6.3.2. The feature-capability indicator specification MUST define whether the feature-capability indicator has a default value.
機能能力インジケーターは、関連付けられた値または値のリストを持つことができます。機能能力インジケーターの仕様では、特定の値の使用に関連する可能性のある制限を含め、機能能力インジケーターに対して定義された値の構文とセマンティクスを定義する必要があります。機能能力インジケータの仕様は、セクション6.3.2で定義されているABNFに従って値を定義する必要があります。機能能力インジケーターの仕様では、機能能力インジケーターにデフォルト値があるかどうかを定義する必要があります。
If no values are defined for the feature-capability indicator, it MUST be indicated in the feature-capability indicator specification.
機能能力インジケーターに値が定義されていない場合は、機能能力インジケーターの仕様で指定する必要があります。
A feature-capability indicator value is only applicable for the feature-capability indicator for which it has been defined. For other feature-capability indicators, the value has to be defined explicitly, even if the semantics are identical.
機能能力指標値は、それが定義されている機能能力指標にのみ適用できます。他の機能能力インジケーターの場合、セマンティクスが同一であっても、値を明示的に定義する必要があります。
It is strongly RECOMMENDED to not re-use a value that already has been defined for another feature-capability indicator, unless the semantics of the values are the same.
値のセマンティクスが同じでない限り、別の機能機能インジケーターにすでに定義されている値を再利用しないことを強くお勧めします。
If there are restrictions on how SIP entities can insert a feature-capability indicator, the feature-capability indicator specification MUST document such restrictions.
SIPエンティティが機能能力インジケーターを挿入する方法に制限がある場合、機能能力インジケーターの仕様はそのような制限を文書化する必要があります。
There might be restrictions related to whether or not entities
エンティティかどうかに関連する制限があるかもしれません
o are allowed to insert a feature-capability indicator in registration-related messages, standalone transaction messages, or dialog-related messages,
o 登録関連のメッセージ、スタンドアロンのトランザクションメッセージ、またはダイアログ関連のメッセージに機能能力インジケータを挿入できます。
o are allowed to insert a feature-capability indicator in requests or responses,
o 要求または応答に機能能力インジケータを挿入することが許可されている
o also need to support other features and capabilities in order to insert a feature-capability indicator, and
o 機能能力インジケータを挿入するために、他の機能もサポートする必要があります。
o are allowed to indicate support of a feature in conjunction with another feature.
o 別の機能と組み合わせた機能のサポートを示すことができます。
The feature-capability indicator specification MUST document any specific interoperability considerations that apply to the feature-capability indicator.
機能能力インジケーターの仕様は、機能能力インジケーターに適用される特定の相互運用性の考慮事項を文書化する必要があります。
Interoperability considerations can, e.g., include procedures related to cases where an expected feature-capability indicator is not present or where it contains an unexpected value.
相互運用性の考慮事項には、たとえば、予想される機能能力インジケーターが存在しない場合や、予期しない値が含まれている場合に関連する手順を含めることができます。
The feature-capability indicator specification MUST document any specific security considerations that apply to the feature-capability indicator.
機能能力インジケーター仕様は、機能能力インジケーターに適用される特定のセキュリティ考慮事項を文書化しなければなりません。
It is recommended that the feature-capability indicator specification provide demonstrative message flow diagrams, paired with complete messages and message descriptions.
機能能力インジケーターの仕様では、完全なメッセージおよびメッセージの説明と組み合わせて、実証的なメッセージフロー図を提供することをお勧めします。
Note that example message flows are by definition informative and do not replace normative text.
メッセージフローの例は、定義による情報提供であり、規範的なテキストを置き換えるものではないことに注意してください。
If there is additional information about the feature-capability indicator, it is recommended to describe such information. It can include, for example, names of related feature-capability indicators.
機能能力インジケーターに関する追加情報がある場合は、そのような情報を説明することをお勧めします。たとえば、関連する機能能力インジケータの名前を含めることができます。
This section defines the ABNF for the Feature-Caps header field and for the feature-capability indicators. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234].
このセクションでは、Feature-Capsヘッダーフィールドと機能能力インジケーターのABNFを定義します。この仕様で定義されているABNFは、RFC 5234 [RFC5234]に準拠しています。
The ABNF for the Feature-Caps header fields is:
Feature-CapsヘッダーフィールドのABNFは次のとおりです。
Feature-Caps = "Feature-Caps" HCOLON fc-value
*(COMMA fc-value)
fc-value = "*" *(SEMI feature-cap)
NOTE: The "*" value is present in order to follow the guidelines for syntax in RFC 4485 [RFC4485] and to maintain a consistent format with RFCs 3840 [RFC3840] and 3841 [RFC3841].
注：「*」の値は、RFC 4485 [RFC4485]の構文のガイドラインに従い、RFC 3840 [RFC3840]および3841 [RFC3841]との一貫した形式を維持するために存在します。
In a feature-capability indicator name (ABNF: fcap-name), dots can be used to implement a feature-capability indicator tree hierarchy (e.g., tree.feature.subfeature). The description of usage of such a tree hierarchy must be described when registered.
機能機能インジケーター名（ABNF：fcap-name）では、ドットを使用して機能機能インジケーターツリー階層（tree.feature.subfeatureなど）を実装できます。そのようなツリー階層の使用法の説明は、登録時に説明する必要があります。
The ABNF for the feature-capability indicator is:
機能能力インジケーターのABNFは次のとおりです。
feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list
/ fcap-string-value ) RDQUOT]
fcap-name = ftag-name
fcap-value-list = tag-value-list
fcap-string-value = string-value
;; ftag-name, tag-value-list, string-value defined in RFC 3840
NOTE: In comparison with media feature tags, the "+" sign in front of the feature-capability indicator name is mandatory.
注：メディア機能タグと比較して、機能機能インジケーター名の前の「+」記号は必須です。
This specification registers a new SIP header field, Feature-Caps, according to the process defined in RFC 3261 [RFC3261].
この仕様は、RFC 3261 [RFC3261]で定義されているプロセスに従って、新しいSIPヘッダーフィールドFeature-Capsを登録します。
The following is the registration for Feature-Caps in the "Header Fields" registry:
以下は、「Header Fields」レジストリのFeature-Capsの登録です。
RFC Number: RFC 6809
RFC番号：RFC 6809
Header Field Name: Feature-Caps
ヘッダーフィールド名：Feature-Caps
This specification adds the Feature-Caps header field to the IANA "Header Field Parameters and Parameter Values" registry, according to the process described in RFC 3968 [RFC3968].
この仕様は、RFC 3968 [RFC3968]で説明されているプロセスに従って、Feature-CapsヘッダーフィールドをIANAの「ヘッダーフィールドパラメーターとパラメーター値」レジストリに追加します。
Predefined
Header Field Parameter Name Values Reference
--------------------------------------------------------------------
Feature-Caps +<fcap-name> * No [RFC6809]
* <fcap-name> denotes parameter names conforming to the syntax <fcap-name> defined in RFC 6809. Valid feature-capability indicators are registered in the Proxy-Feature Feature-Capability Indicator Trees registry.
* <fcap-name>は、RFC 6809で定義された構文<fcap-name>に準拠するパラメーター名を示します。有効な機能機能インジケーターは、Proxy-Feature Feature-Capability Indicator Treesレジストリに登録されています。
This specification creates a new sub-registry to the IANA "Session Initiation Protocol (SIP) Parameters" registry, according to the process defined in RFC 5226. The name of the sub-registry is "Proxy-Feature Feature-Capability Indicator Trees".
この仕様は、RFC 5226で定義されているプロセスに従って、IANAの「セッション開始プロトコル（SIP）パラメータ」レジストリに新しいサブレジストリを作成します。サブレジストリの名前は、「プロキシ機能機能インジケータツリー」です。
Feature-capability indicators are categorized by the "leading facet" of their name. The leading facet is a prefix of the name consisting of all characters up to and including the first ".". Feature-capability indicator names that contain no "." characters are considered to have an empty ("") leading facet.
機能能力インジケーターは、その名前の「主要なファセット」によって分類されます。先頭のファセットは、最初の「。」までのすべての文字で構成される名前の接頭辞です。 「。」を含まない機能機能インジケーター名。文字は、空の（ ""）先頭ファセットがあると見なされます。
The "Proxy-Feature Feature-Capability Indicator Trees" registry contains sub-registries for subsets (called 'trees') of feature-capability indicators sharing the same leading facet. Each feature-capability indicator is registered within the tree that matches its leading facet. If no tree matches its leading facet, then the feature-capability indicator cannot be registered.
「Proxy-Feature Feature-Capability Indicator Trees」レジストリには、同じ主要なファセットを共有する機能能力インジケーターのサブセット（「ツリー」と呼ばれます）のサブレジストリーが含まれています。各機能能力インジケーターは、その主要なファセットと一致するツリー内に登録されます。主要なファセットに一致するツリーがない場合、機能能力インジケーターを登録できません。
New feature-capability indicator sub-registries (trees) can be registered. The registration must meet the "Standards Action" policies defined in RFC 5226 [RFC5226]. A new name, unique leading facet, and registration policies (as defined in RFC 5226) for feature-capability indicators within this tree need to be provided.
新しい機能能力インジケーターサブレジストリ（ツリー）を登録できます。登録は、RFC 5226 [RFC5226]で定義されている「標準アクション」ポリシーを満たしている必要があります。このツリー内の機能機能インジケーターの新しい名前、一意の主要なファセット、および登録ポリシー（RFC 5226で定義されている）を提供する必要があります。
This document defines the first two feature-capability indicator trees ("g." and "sip."). It does not define a tree for the empty leading facet.
このドキュメントでは、最初の2つの機能能力インジケーターツリー（「g。」と「sip。」）を定義します。空のリーディングファセットのツリーは定義しません。
This specification creates a new feature-capability indicator tree in the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry. The name of the tree is "Global Feature-Capability Indicator Registration Tree", and its leading facet is "g.". It is used for the registration of feature-capability indicators.
この仕様は、IANA "Proxy-Feature Feature-Capability Indicator Trees"レジストリに新しい機能機能インジケーターツリーを作成します。ツリーの名前は「Global Feature-Capability Indicator Registration Tree」であり、その主要なファセットは「g。」です。これは、機能能力インジケーターの登録に使用されます。
When a feature-capability indicator is registered in the global tree, it needs to meet the "Specification Required" policies defined in RFC 5226. A designated area expert will review the proposed feature-capability indicator and consult with members of related mailing lists. The information required in the registration is defined in Section 5.3 of this document.
機能能力インジケーターがグローバルツリーに登録されている場合、RFC 5226で定義されている "Specification Required"ポリシーを満たす必要があります。指定されたエリアの専門家が提案された機能能力インジケーターを確認し、関連するメーリングリストのメンバーに相談します。登録に必要な情報は、このドキュメントのセクション5.3で定義されています。
Note that all feature-capability indicators registered in the global tree will have names with a leading facet "g.". No leading "+" is used in the registrations in any of the feature-capability indicator registration trees.
グローバルツリーに登録されているすべての機能能力インジケーターには、先頭に「g。」というファセットがある名前が付けられます。機能能力インジケーターの登録ツリーの登録では、先頭に「+」は使用されません。
The format of the global tree is as described below:
グローバルツリーの形式は次のとおりです。
Name Description Reference
------------------------------
Name - contains the Feature-Capability Indicator Name, provided in the registration feature-capability indication registration template.
名前-機能機能インジケーターの登録テンプレートで提供される機能機能インジケーター名が含まれます。
Description - provided in the registration feature-capability indication registration template.
説明-登録機能機能表示登録テンプレートで提供されます。
Reference - contains the Feature-Capability Indicator specification reference provided in the registration feature-capability indication registration template.
参照-登録機能能力表示登録テンプレートで提供される機能能力インジケーター仕様のリファレンスが含まれています。
No initial values are registered in the global tree.
グローバルツリーには初期値は登録されていません。
This specification creates a new feature-capability indicator tree in the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry. The name of the tree is "SIP Feature-Capability Indicator Registration Tree", and its leading facet is "sip.". It is used for the registration of feature-capability indicators.
この仕様は、IANA "Proxy-Feature Feature-Capability Indicator Trees"レジストリに新しい機能機能インジケーターツリーを作成します。ツリーの名前は「SIP Feature-Capability Indicator Registration Tree」であり、その主要なファセットは「sip。」です。これは、機能能力インジケーターの登録に使用されます。
When a feature-capability indicator is registered in the SIP tree, it needs to meet the "IETF Review" policies defined in RFC 5226. The information required in the registration is defined in Section 5.3 of this document.
機能能力インジケーターがSIPツリーに登録されている場合、RFC 5226で定義されている「IETFレビュー」ポリシーを満たす必要があります。登録に必要な情報は、このドキュメントのセクション5.3で定義されています。
Note that all feature-capability indicators registered in the SIP tree will have names with a leading facet "sip.". No leading "+" is used in the registrations in any of the feature-capability indicator registration trees.
SIPツリーに登録されているすべての機能機能インジケーターには、先頭にファセット「sip。」が付いた名前が付けられることに注意してください。機能能力インジケーターの登録ツリーの登録では、先頭に「+」は使用されません。
The format of the SIP tree is as described below:
SIPツリーのフォーマットは次のとおりです。
Name Description Reference
------------------------------
Name - contains the Feature-Capability Indicator Name, provided in the registration feature-capability indication registration template.
名前-機能機能インジケーターの登録テンプレートで提供される機能機能インジケーター名が含まれます。
Description - provided in the registration feature-capability indication registration template.
説明-登録機能機能表示登録テンプレートで提供されます。
Reference - contains the Feature-Capability Indicator specification reference provided in the registration feature-capability indication registration template.
参照-登録機能能力表示登録テンプレートで提供される機能能力インジケーター仕様のリファレンスが含まれています。
No initial values are registered in the SIP tree.
SIPツリーに初期値は登録されていません。
Registration requests for the global tree are submitted by email to iana@iana.org.
グローバルツリーの登録リクエストは、電子メールでiana@iana.orgに送信されます。
Registration requests for the SIP tree requires submitting an Internet-Draft to the IESG.
SIPツリーの登録要求では、Internet-DraftをIESGに送信する必要があります。
| Instructions are preceded by '|'. All fields are mandatory.
|説明の前には「|」が付いています。すべてのフィールドは必須です。
Feature-capability indicator name:
機能能力インジケーター名：
Description:
説明：
| The description should be no longer than 4 lines. More
| detailed information can be provided in the feature
| capability indicator specification.
Feature-capability indicator specification reference:
機能能力インジケーター仕様リファレンス：
| The referenced specification must contain the information | listed in Section 5.3 of RFC 6809.
|参照される仕様には情報が含まれている必要があります。 RFC 6809のセクション5.3に記載されています。
Contact:
連絡先：
| Name(s) & email address(es) of person(s) to | contact for further information.
|への人の名前とメールアドレス|詳細についてはお問い合わせください。
The security issues for feature-capability indicators are similar to the ones defined in RFC 3840 for media feature tags. Media feature tags can reveal information about end users and end-user equipment, which can be used for industrial espionage. The knowledge about end-user equipment capabilities can also be used to influence application behavior. As feature-capability indicators are not intended to convey capability information of end-user devices, such end-user security aspects of RFC 3840 do not apply to feature-capability indicators.
機能機能インジケータのセキュリティ問題は、RFC 3840でメディア機能タグに対して定義されているものと同様です。メディア機能タグは、産業スパイに使用できるエンドユーザーおよびエンドユーザー機器に関する情報を明らかにできます。エンドユーザー機器の機能に関する知識は、アプリケーションの動作に影響を与えるためにも使用できます。機能機能インジケータはエンドユーザーデバイスの機能情報を伝えることを目的としていないため、RFC 3840のこのようなエンドユーザーセキュリティの側面は機能機能インジケータには適用されません。
In addition, the security issue discussed in RFC 3840 regarding an attacker using the SIP caller preferences extension [RFC3841] in order to affect routing decisions does not apply, as the mechanism is not defined to be used with feature-capability indicators.
さらに、メカニズムが機能能力インジケーターで使用されるように定義されていないため、ルーティングの決定に影響を与えるためにSIP呼び出し元設定拡張[RFC3841]を使用する攻撃者に関してRFC 3840で説明されているセキュリティ問題は適用されません。
Feature-capability indicators can, however, provide capability and characteristics information about the SIP entity, some of which might be sensitive. Malicious elements viewing the indicators may be able to discern application deployment details or identify elements with exploitable feature implementation weaknesses. The Feature-Caps header field does not convey address information about SIP entities. However, individual feature-capability indicators might provide address information as feature-capability indicator values. Therefore, if the feature-capability indicators provide information that requires data integrity or origin authentication, mechanisms for providing those MUST be provided. If confidentiality is required, then the specification MUST call for the use of Transport Layer Security (TLS) [RFC5246] at all hops. Since there are no satisfactory middle-to-end or middle-to-middle SIP confidentiality mechanisms, TLS is as good as it gets, and specifications SHOULD NOT define feature-capability indicators that need confidentiality that is better than the hop-by-hop confidentiality provided by TLS.
ただし、機能能力インジケーターは、SIPエンティティに関する機能および特性情報を提供できます。インジケーターを表示する悪意のある要素は、アプリケーションの展開の詳細を見分けたり、悪用可能な機能実装の要素を特定したりできる場合があります。 Feature-Capsヘッダーフィールドは、SIPエンティティに関するアドレス情報を伝えません。ただし、個々の機能能力インジケーターは、機能情報インジケーター値としてアドレス情報を提供する場合があります。したがって、機能能力インジケーターがデータの整合性または送信元の認証を必要とする情報を提供する場合、それらを提供するメカニズムを提供する必要があります。機密性が必要な場合、仕様ではすべてのホップでトランスポート層セキュリティ（TLS）[RFC5246]の使用を要求する必要があります。満足できるミドルツーエンドまたはミドルツーミドルのSIP機密性メカニズムがないため、TLSは可能な限り優れており、ホップバイホップよりも優れた機密性を必要とする機能能力インジケーターを仕様で定義しないでください。 TLSによって提供される機密性。
The authors wish to thank everyone in the SIP community that provided input and feedback on the work of this specification.
著者は、この仕様の作業に関するインプットとフィードバックを提供してくれたSIPコミュニティの全員に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC2506] Holtman、K.、Mutz、A。、およびT. Hardie、「Media Feature Tag Registration Procedure」、BCP 31、RFC 2506、1999年3月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「Indicating User Agent Capabilities in the Session Initiation Protocol（SIP）」、RFC 3840、2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「Session Initiation Protocol（SIP）の発信者設定」、RFC 3841、2004年8月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968] Camarillo、G。、「セッション開始プロトコル（SIP）のインターネット割り当て番号機関（IANA）ヘッダーフィールドパラメータレジストリ」、BCP 98、RFC 3968、2004年12月。
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, May 2006.
[RFC4485] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）の拡張機能の作成者向けガイドライン」、RFC 4485、2006年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C.、Mahy、R。、およびF. Audet、「Managing Client-Initiated Connections in the Session Initiation Protocol（SIP）」、RFC 5626、2009年10月。
Authors' Addresses
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: christer.holmberg@ericsson.com
Ivo Sedlacek Ericsson Scheelevaegen 19C Lund 22363 Sweden
Ivo Sedlacek Ericsson Scheelevaegen 19C Lund 22363スウェーデン
EMail: ivo.sedlacek@ericsson.com
Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA
ハドリエルカプランAcmeパケット71サードアベニュー。バーリントン、MA 01803 USA
EMail: hkaplan@acmepacket.com