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
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标头字段传送功能能力指示器，用于指示对SIP实体的功能和能力的支持，这些SIP实体不由Contact标头字段的统一资源标识符（URI）表示。
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 header字段的URI表示的SIP实体可以在Contact header字段中传递媒体功能标签，以指示对功能和功能的支持。
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注册表“代理功能指标树”，用于注册功能指标。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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消息使用Contact header字段传递与发起人的特征和能力相关的信息。
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标头字段传送功能能力指示器，用于指示对SIP实体的功能和能力的支持，这些SIP实体不由Contact标头字段的统一资源标识符（URI）表示。这些案件包括：
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实体充当背靠背用户代理（B2BUA）[RFC3261]，其中联系人头字段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 header字段的URI表示的SIP实体可以在Contact header字段中传递媒体功能标签，以指示对功能和功能的支持。
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注册表“代理功能指标树”，用于注册功能指标。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
SIP实体使用Feature Caps header字段通过设置功能能力指标来传达对功能和能力的支持。在featurecaps报头字段中传送的特征能力指示符指示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.
如果请求或响应的联系人标头字段中的URI表示SIP实体，则该实体不得使用该请求或响应中的Feature Caps标头字段指示支持的功能。
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
当SIP实体接收到包含一个或多个Feature Caps标头字段的SIP请求或响应时，标头字段中的Feature capability Indicator将通知实体SIP消息信令中实体支持的特性和功能
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.
路径调用特性和功能的过程不在本规范的范围内，必须由各个特性能力指标规范描述。
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 feature capability指示符将表示从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消息中删除特征Caps头字段。此外，SIP实体可以从SIP消息内的featurecaps报头字段中移除特征能力指示符。SIP实体不应对SIP消息中的Feature Caps头字段重新排序。
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.
本节中的程序适用于属于B2BUA一部分的用户代理（UAs）[RFC3261]，这些用户代理在消息中由记录路由头字段而不是联系人头字段的URI引用。
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实体的特性和能力的支持，则在其转发请求之前，它在请求中插入特性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.
如果SIP请求由B2BUA已经接收到的另一SIP请求触发，则UA可以在SIP请求中插入其自己的Feature Caps报头字段之前，通过将接收到的Feature Caps报头字段复制到传出的SIP请求来转发这些字段，类似于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实体的特征和能力的支持，则在其转发响应之前，它在响应中插入特征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.
如果SIP响应由B2BUA已经接收到的另一SIP响应触发，则UA可以在SIP响应中插入其自己的Feature Caps报头字段之前，通过将接收到的Feature Caps报头字段复制到传出的SIP响应（类似于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实体指示对功能和能力的支持，则它会在寄存器响应中插入一个功能Caps头字段，其中包含一个或多个与支持的功能和能力相关联的功能能力指示符。
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实体的功能和能力的支持，则在转发请求之前，它会在请求中插入一个功能Caps头字段，其中包含一个或多个与支持的功能和能力相关联的SIP功能能力指示符。
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实体指示对功能和能力的支持，则在转发响应之前，它会在响应中插入一个功能Caps头字段，其中包含一个或多个与支持的功能和能力相关联的SIP功能能力指示器。
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节定义了特征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 header字段可用于对话框的初始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订阅请求相关联的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.
featurecaps报头字段可在SIP注册请求内以及与该请求相关联的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
如果在寄存器请求的feature Caps报头字段中或在相关响应中传送特性能力指示器，则它向消息的接收者指示该特性
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.
在注册请求中明确传达的联系人注册到期之前，支持与功能能力指示器关联的功能，或者，直到已注册的联系人被显式刷新，并且刷新注册请求不包含与该功能相关联的功能能力指示器。
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.
尽管注册响应可以包含已注册为其他注册事务一部分的联系人，但对任何指定功能的支持仅适用于发送给联系人的请求，这些请求在相关注册请求中明确传达。
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.
本规范未定义在纯注册绑定获取消息（参见RFC 3261第10.2.3节）中使用Feature Caps标头字段的任何语义，其中注册请求不包含联系人标头字段。除非在将来的扩展中定义了这样的语义，否则获取消息不会对先前指定的功能和能力支持产生任何影响，并且SIP实体不得在这样的消息中插入功能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 header字段可用于独立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.
功能功能指示符由不由联系人标头字段的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“代理功能指标树”注册表中定义。
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.
本文定义的树类似于RFCs 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.
与RFCs 2506和3840相比，本规范仅定义了全局树和SIP树，因为它们是那些RFCs中定义的唯一树，用于定义特定于SIP的媒体功能标签。
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.
除非出于澄清或强调的目的需要，否则特征能力指标规范重复本规范中定义的程序（例如，关于使用特征Caps标题字段和特征能力指标的一般程序）是不好的做法。功能能力指标规范不得修改第4节中定义的功能Caps标题字段规则和语义。
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.
特性能力指标规范不得削弱本规范中指定为“应该”或“必须”的任何行为。然而，如果与特征能力指标相关的特征和能力需要，则规范可将“应该”、“可能”或“建议”要求强化为“必须”强度。
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.
特性能力指标规范必须包含特性能力指标的总体描述：如何使用它来表示特性支持、与特性能力指标关联的特性描述、任何附加信息的描述（使用一个或多个特征能力指标值传达）可与特征能力指标一起传达的信息，以及相关特征如何执行/调用的说明。
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标头字段和Feature capability indicators的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)
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名称）中，dots可用于实现特征能力指标树层次结构（例如树、特征、子特征）。注册时必须描述此类树层次结构的使用说明。
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
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:
以下是在“标题字段”注册表中注册功能帽的步骤：
RFC Number: RFC 6809
RFC编号：RFC 6809
Header Field Name: 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]中描述的过程，本规范将功能Caps标题字段添加到IANA“标题字段参数和参数值”注册表中。
Predefined
Header Field Parameter Name Values Reference
--------------------------------------------------------------------
Predefined
Header Field Parameter Name Values Reference
--------------------------------------------------------------------
Feature-Caps +<fcap-name> * No [RFC6809]
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>的参数名称。有效的功能功能指标在代理功能功能指标树注册表中注册。
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.
“代理功能特性能力指标树”注册表包含共享同一主要方面的功能特性能力指标子集（称为“树”）的子注册表。每个特性能力指标都注册在与其主要方面相匹配的树中。如果没有树与其前导方面匹配，则无法注册特性能力指示器。
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.
本文档定义了前两个功能能力指标树（“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“代理功能功能功能指标树”注册表中创建一个新的功能指标树。该树的名称为“全局特征能力指标注册树”，其主要方面为“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中定义的“所需规范”策略。指定的区域专家将审查建议的功能能力指标，并与相关邮件列表的成员协商。本文件第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 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“代理功能功能功能指标树”注册表中创建一个新的功能指标树。树的名称是“SIP特性能力指示器注册树”，其主要方面是“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 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树的注册请求需要向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.
| 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.
此外，RFC 3840中讨论的关于攻击者使用SIP呼叫方首选项扩展[RFC3841]来影响路由决策的安全问题不适用，因为该机制未定义为与功能能力指示器一起使用。
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：会话启动协议”，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，“媒体功能标签注册程序”，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，“指出会话启动协议（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，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年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）的Internet分配号码管理机构（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，“会话启动协议（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，“在RFCs中编写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，“传输层安全（TLS）协议版本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，“在会话启动协议（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
EMail: christer.holmberg@ericsson.com
Ivo Sedlacek Ericsson Scheelevaegen 19C Lund 22363 Sweden
Ivo Sedlacek Ericsson Scheelevategen 19C Lund 22363瑞典
EMail: ivo.sedlacek@ericsson.com
EMail: ivo.sedlacek@ericsson.com
Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA
美国马萨诸塞州伯灵顿第三大道71号Hadriel Kaplan Acme包01803
EMail: hkaplan@acmepacket.com
EMail: hkaplan@acmepacket.com