Network Working Group J. Rosenberg
Request for Comments: 3840 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
P. Kyzivat
Cisco Systems
August 2004
Network Working Group J. Rosenberg
Request for Comments: 3840 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
P. Kyzivat
Cisco Systems
August 2004
Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)
指示会话启动协议（SIP）中的用户代理功能
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field.
本规范定义了会话发起协议（SIP）用户代理可以将其功能和特性传递给其他用户代理和其域的注册器的机制。此信息作为联系人标题字段的参数传送。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Usage of the Content Negotiation Framework . . . . . . . . . . 6
5. Computing Capabilities . . . . . . . . . . . . . . . . . . . . 7
6. Expressing Capabilities in a Registration . . . . . . . . . . 10
7. Indicating Feature Sets in Remote Target URIs . . . . . . . . 12
8. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . . . 13
9. Contact Header Field . . . . . . . . . . . . . . . . . . . . . 13
10. Media Feature Tag Definitions . . . . . . . . . . . . . . . . 14
10.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2. Application . . . . . . . . . . . . . . . . . . . . . . 16
10.3. Data. . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.4. Control . . . . . . . . . . . . . . . . . . . . . . . . 17
10.5. Video . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.6. Text. . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.7. Automata. . . . . . . . . . . . . . . . . . . . . . . . 18
10.8. Class . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.9. Duplex. . . . . . . . . . . . . . . . . . . . . . . . . 20
10.10. Mobility. . . . . . . . . . . . . . . . . . . . . . . . 20
10.11. Description . . . . . . . . . . . . . . . . . . . . . . 21
10.12. Event Packages. . . . . . . . . . . . . . . . . . . . . 22
10.13. Priority. . . . . . . . . . . . . . . . . . . . . . . . 22
10.14. Methods . . . . . . . . . . . . . . . . . . . . . . . . 23
10.15. Extensions. . . . . . . . . . . . . . . . . . . . . . . 24
10.16. Schemes . . . . . . . . . . . . . . . . . . . . . . . . 24
10.17. Actor . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.18. Is Focus. . . . . . . . . . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11.1. Considerations for Media Feature Tags . . . . . . . . . 26
11.2. Considerations for Registrations. . . . . . . . . . . . 27
11.3. Considerations for OPTIONS Responses. . . . . . . . . . 28
11.4. Considerations for Dialog Initiating Messages . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12.1. SIP Media Feature Tag Registration Tree . . . . . . . . 28
12.2. Media Feature Tags. . . . . . . . . . . . . . . . . . . 29
12.3. SIP Option Tag. . . . . . . . . . . . . . . . . . . . . 30
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References. . . . . . . . . . . . . . . . . . 31
14.2. Informative References. . . . . . . . . . . . . . . . . 31
Appendix. Overview of RFC 2533. . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Usage of the Content Negotiation Framework . . . . . . . . . . 6
5. Computing Capabilities . . . . . . . . . . . . . . . . . . . . 7
6. Expressing Capabilities in a Registration . . . . . . . . . . 10
7. Indicating Feature Sets in Remote Target URIs . . . . . . . . 12
8. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . . . 13
9. Contact Header Field . . . . . . . . . . . . . . . . . . . . . 13
10. Media Feature Tag Definitions . . . . . . . . . . . . . . . . 14
10.1. Audio . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.2. Application . . . . . . . . . . . . . . . . . . . . . . 16
10.3. Data. . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.4. Control . . . . . . . . . . . . . . . . . . . . . . . . 17
10.5. Video . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.6. Text. . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.7. Automata. . . . . . . . . . . . . . . . . . . . . . . . 18
10.8. Class . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.9. Duplex. . . . . . . . . . . . . . . . . . . . . . . . . 20
10.10. Mobility. . . . . . . . . . . . . . . . . . . . . . . . 20
10.11. Description . . . . . . . . . . . . . . . . . . . . . . 21
10.12. Event Packages. . . . . . . . . . . . . . . . . . . . . 22
10.13. Priority. . . . . . . . . . . . . . . . . . . . . . . . 22
10.14. Methods . . . . . . . . . . . . . . . . . . . . . . . . 23
10.15. Extensions. . . . . . . . . . . . . . . . . . . . . . . 24
10.16. Schemes . . . . . . . . . . . . . . . . . . . . . . . . 24
10.17. Actor . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.18. Is Focus. . . . . . . . . . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11.1. Considerations for Media Feature Tags . . . . . . . . . 26
11.2. Considerations for Registrations. . . . . . . . . . . . 27
11.3. Considerations for OPTIONS Responses. . . . . . . . . . 28
11.4. Considerations for Dialog Initiating Messages . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12.1. SIP Media Feature Tag Registration Tree . . . . . . . . 28
12.2. Media Feature Tags. . . . . . . . . . . . . . . . . . . 29
12.3. SIP Option Tag. . . . . . . . . . . . . . . . . . . . . 30
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References. . . . . . . . . . . . . . . . . . 31
14.2. Informative References. . . . . . . . . . . . . . . . . 31
Appendix. Overview of RFC 2533. . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36
Session Initiation Protocol (SIP) [1] user agents vary widely in their capabilities and in the types of devices they represent. Frequently, it is important for another SIP element to learn the capabilities and characteristics of a SIP UA. Some of the applications of this information include:
会话启动协议（SIP）[1]用户代理在其功能和所代表的设备类型上存在很大差异。通常，另一个SIP元素了解SIP UA的功能和特征非常重要。这些信息的一些应用包括：
o One user agent, a PC-based application, is communicating with another that is embedded in a limited-function device. The PC would like to be able to "grey out" those components of the user interface that represent features or capabilities not supported by its peer. To do that, there needs to be a way to exchange capability information within a dialog.
o 一个用户代理（基于PC的应用程序）正在与嵌入在有限功能设备中的另一个用户代理进行通信。PC希望能够“灰显”用户界面中表示其对等方不支持的功能或功能的组件。为此，需要有一种在对话框中交换功能信息的方法。
o A user has two devices at their disposal. One is a videophone, and the other, a voice-only wireless phone. A caller wants to interact with the user using video. As such, they would like their call preferentially routed to the device which supports video. To do this, the INVITE request can contain parameters that express a preference for routing to a device with the specified capabilities [11].
o 用户可以使用两台设备。一个是可视电话，另一个是纯语音无线电话。调用方希望使用视频与用户进行交互。因此，他们希望他们的呼叫优先路由到支持视频的设备。为此，INVITE请求可以包含一些参数，这些参数表示路由到具有指定功能的设备的首选项[11]。
o A network application would like to asynchronously send information to a user agent in a MESSAGE [16] request. However, before sending it, they would like to know if the UA has the capabilities necessary to receive the message. To do that, they would ideally query a user database managed by the domain which holds such information. Population of such a database would require that a UA convey its capabilities as part of its registration. Thus, there is a need for conveying capabilities in REGISTER requests.
o 网络应用程序希望在消息[16]请求中向用户代理异步发送信息。然而，在发送信息之前，他们想知道UA是否具备接收信息所需的能力。要做到这一点，他们最好查询由保存此类信息的域管理的用户数据库。这种数据库的数量将要求UA将其能力作为其注册的一部分进行传达。因此，需要在寄存器请求中传输功能。
SIP has some support for expression of capabilities. The Allow, Accept, Accept-Language, and Supported header fields convey some information about the capabilities of a user agent. However, these header fields convey only a small part of the information that is needed. They do not provide a general framework for expression of capabilities. Furthermore, they only specify capabilities indirectly; the header fields really indicate the capabilities of the UA as they apply to this request. SIP also has no ability to convey characteristics, that is, information that describes a UA.
SIP对功能的表达有一定的支持。Allow、Accept、Accept Language和Supported标头字段传递有关用户代理功能的一些信息。但是，这些标题字段只传递所需信息的一小部分。它们不提供表达能力的通用框架。此外，它们只是间接地指定能力；当UA应用于此请求时，标头字段实际上指示UA的能力。SIP也不能传递特征，即描述UA的信息。
As a result, this specification provides a more general framework for an indication of capabilities and characteristics in SIP. Capability and characteristic information about a UA is carried as parameters of
因此，本规范提供了一个更通用的框架，用于指示SIP中的功能和特征。UA的能力和特征信息作为
the Contact header field. These parameters can be used within REGISTER requests and responses, OPTIONS responses, and requests and responses that create dialogs (such as INVITE).
联系人标题字段。这些参数可用于注册请求和响应、选项响应以及创建对话框的请求和响应（如INVITE）。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释，并指出合规实施的要求级别。
Feature: As defined in RFC 2703 [17], a piece of information about the media handling properties of a message passing system component or of a data resource. For example, the SIP methods supported by a UA represent a feature.
特征：如RFC 2703[17]中所定义，关于消息传递系统组件或数据资源的媒体处理属性的信息。例如，UA支持的SIP方法代表一种特性。
Feature Tag: As defined in RFC 2703 [17], a feature tag is a name that identifies a feature. An example is "sip.methods".
特征标记：如RFC 2703[17]中所定义，特征标记是标识特征的名称。例如“sip.methods”。
Media Feature: As defined in RFC 2703, [17], a media feature is information that indicates facilities assumed to be available for the message content to be properly rendered or otherwise presented. Media features are not intended to include information that affects message transmission.
媒体功能：如RFC 2703[17]中所定义，媒体功能是一种信息，表示假定可用于正确呈现或以其他方式呈现消息内容的设施。媒体功能不包括影响消息传输的信息。
In the context of this specification, a media feature is information that indicates facilities for handling SIP requests, rather than specifically for content. In that sense, it is used synonymously with feature.
在本规范的上下文中，媒体特性是指示用于处理SIP请求的设施的信息，而不是专门用于内容的信息。从这个意义上讲，它与功能同义。
Feature Collection: As defined in RFC 2533 [4], a feature collection is a collection of different media features and associated values. This might be viewed as describing a specific rendering of a specific instance of a document or resource by a specific recipient.
功能集合：如RFC 2533[4]中所定义，功能集合是不同媒体功能和相关值的集合。这可能被视为描述特定收件人对文档或资源的特定实例的特定呈现。
Feature Set: As defined in RFC 2703 [17], a feature set is information about a sender, recipient, or other participant in a message transfer which describes the set of features that it can handle. Where a 'feature' describes a single identified attribute of a resource, a 'feature set' describes a full set of possible attributes.
功能集：如RFC 2703[17]中所定义，功能集是关于消息传输中发送者、接收者或其他参与者的信息，描述了它可以处理的功能集。当“功能”描述资源的单个已识别属性时，“功能集”描述一整套可能的属性。
Feature Parameters: A set of SIP header field parameters that can appear in the Contact header field. The feature parameters represent an encoding of a feature set. Each set of feature parameters maps to a feature set predicate.
功能参数：一组SIP头字段参数，可出现在联系人头字段中。特征参数表示特征集的编码。每组特征参数映射到一个特征集谓词。
Capability: As defined in RFC 2703 [17], a capability is an attribute of a sender or receiver (often the receiver) which indicates an ability to generate or process a particular type of message content. A capability is distinct from a characteristic in that a capability may or may not be utilized in any particular call, whereas a characteristic is a non-negotiable property of a UA. SIP itself will often negotiate whether or not capabilities are used in a call.
能力：如RFC 2703[17]中所定义，能力是发送方或接收方（通常是接收方）的属性，表示生成或处理特定类型消息内容的能力。能力不同于特征，因为能力可以或不可以在任何特定呼叫中使用，而特征是UA的不可转让财产。SIP本身通常会协商是否在呼叫中使用功能。
Characteristic: A characteristic is like a capability, but describes an aspect of a UA which is not negotiable. As an example, whether or not a UA is a mobile phone is a characteristic, not a capability. The semantics of this specification do not differentiate between capability and characteristic, but the distinction is useful for illustrative purposes. Indeed, in the text below, when we say "capability", it refers to both capabilities and characteristics, unless the text explicitly says otherwise.
特征：特征类似于能力，但描述了UA的一个不可协商的方面。例如，UA是否是移动电话是一种特征，而不是一种能力。本规范的语义不区分功能和特性，但这种区别对于说明目的很有用。事实上，在下面的文本中，当我们说“能力”时，它指的是能力和特征，除非文本明确指出其他。
Filter: A single expression in a feature set predicate.
过滤器：功能集谓词中的单个表达式。
Simple Filter: An expression in a feature set predicate which is a comparison (equality or inequality) of a feature tag against a feature value.
简单过滤器：特征集谓词中的表达式，是特征标记与特征值的比较（相等或不相等）。
Disjunction: A boolean OR operation across some number of terms.
析取：一种布尔或运算，跨越若干项。
Conjunction: A boolean AND operation across some number of terms.
连词：一种布尔运算，跨越若干项。
Predicate: A boolean expression.
谓词：布尔表达式。
Feature Set Predicate: From RFC 2533 [4], a feature set predicate is a function of an arbitrary feature collection value which returns a Boolean result. A TRUE result is taken to mean that the corresponding feature collection belongs to some set of media feature handling capabilities defined by this predicate.
特征集谓词：根据RFC 2533[4]，特征集谓词是任意特征集合值的函数，该值返回布尔结果。如果结果为真，则表示相应的功能集合属于此谓词定义的某组媒体功能处理功能。
Contact Predicate: The feature set predicate associated with a URI registered in the Contact header field of a REGISTER request. The contact predicate is derived from the feature parameters in the Contact header field.
联系人谓词：与注册请求的联系人标头字段中注册的URI关联的功能集谓词。触点谓词是从触点标题字段中的特征参数派生的。
This specification makes heavy use of the terminology and concepts in the content negotiation work carried out within the IETF, and documented in several RFCs. The ones relevant to this specification are RFC 2506 [3], which provides a template for registering media feature tags, RFC 2533 [4], which presents a syntax and matching algorithm for media feature sets, RFC 2738 [5], which provides a minor update to RFC 2533, and RFC 2703 [17], which provides a general framework for content negotiation.
本规范在IETF内进行的内容协商工作中大量使用了术语和概念，并记录在多个RFC中。与本规范相关的是RFC 2506[3]，它提供了注册媒体功能标签的模板；RFC 2533[4]，它提供了媒体功能集的语法和匹配算法；RFC 2738[5]，它提供了对RFC 2533的小更新；RFC 2703[17]，它提供了内容协商的一般框架。
In case the reader does not have the time to read those specifications, Appendix A provides a brief overview of the concepts and terminology in those documents that is critical for understanding this specification.
如果读者没有时间阅读这些规范，附录A将简要概述这些文件中对理解本规范至关重要的概念和术语。
Since the content negotiation work was primarily meant to apply to documents or other resources with a set of possible renderings, it is not immediately apparent how it is used to model SIP user agents. A feature set is composed of a set of feature collections, each of which represents a specific rendering supported by the entity described by the feature set. In the context of a SIP user agent, a feature collection represents an instantaneous modality. That is, if you look at the run time processing of a SIP UA and take a snapshot in time, the feature collection describes what it is doing at that very instant.
由于内容协商工作的主要目的是应用于具有一组可能呈现的文档或其他资源，因此目前还不清楚如何使用它来建模SIP用户代理。要素集由一组要素集合组成，每个要素集合表示由要素集描述的实体支持的特定渲染。在SIP用户代理的上下文中，特征集合表示瞬时模态。也就是说，如果您查看SIP UA的运行时处理并及时拍摄快照，那么功能集合将描述它在这一瞬间所做的事情。
This model is important, since it provides guidance on how to determine whether something is a value for a particular feature tag, or a feature tag by itself. If two properties can be exhibited by a UA simultaneously so that both are present in an instantaneous modality, they need to be represented by separate media feature tags. For example, a UA may be able to support some number of media types - audio, video, and control. Should each of these be different values for a single "media-types" feature tag, or should each of them be a separate boolean feature tag? The model provides the answer. Since, at any instance in time, a UA could be handling both audio and video, they need to be separate media feature tags. However, the SIP methods supported by a UA can each be represented as different values for the same media feature tag (the "sip.methods" tag), because fundamentally, a UA processes a single request at a time. It may be multi-threading, so that it appears that this is not so, but at a purely functional level, it is true.
此模型很重要，因为它提供了如何确定某个内容是特定特征标记的值，还是特征标记本身的值的指导。如果UA可以同时显示两个属性，以便两个属性都出现在瞬时模态中，则它们需要由单独的媒体特征标签表示。例如，UA可以支持一些媒体类型-音频、视频和控制。对于单个“媒体类型”功能标签，它们中的每一个应该是不同的值，还是应该是单独的布尔功能标签？模型提供了答案。因为，在任何时候，UA都可以同时处理音频和视频，所以它们需要是单独的媒体功能标签。然而，UA支持的SIP方法可以分别表示为相同媒体功能标签（“SIP.methods”标签）的不同值，因为基本上，UA一次只处理一个请求。它可能是多线程的，所以看起来情况并非如此，但从纯功能层面来看，这是正确的。
Clearly, there are weaknesses in this model, but it serves as a useful guideline for applying the concepts of RFC 2533 to the problem at hand.
显然，该模型存在缺陷，但它可以作为将RFC2533的概念应用于当前问题的有用指南。
To construct a set of Contact header field parameters that indicate capabilities, a UA constructs a feature predicate for that contact. This process is described in terms of RFC 2533 [4] (and its minor update, RFC 2738 [5]) syntax and constructs, followed by a conversion to the syntax used in this specification. However, this represents a logical flow of processing. There is no requirement that an implementation actually use RFC 2533 syntax as an intermediate step.
为了构造一组表示能力的联系人标头字段参数，UA为该联系人构造一个功能谓词。该过程根据RFC 2533[4]（及其次要更新RFC 2738[5]）语法和构造进行描述，然后转换为本规范中使用的语法。然而，这代表了一个逻辑处理流程。不要求实现实际使用RFC2533语法作为中间步骤。
A UA MAY use any feature tags that are registered through IANA in the SIP tree (Established in Section 12.1), IETF, or global trees [3]; this document registers several into the SIP tree. The feature tags discussed in this specification are referred to as base tags. While other tags can be used, in order to identify them as feature parameters (as opposed to parameters for another SIP extension), they are encoded with a leading "+" sign in the Contact header field. It is also permissible to use the URI tree [3] for expressing vendor-specific feature tags. Feature tags in any other trees created through IANA MAY also be used.
UA可以使用通过IANA在SIP树（第12.1节中建立）、IETF或全局树中注册的任何功能标签[3]；本文档在SIP树中注册了几个。本规范中讨论的特征标记称为基本标记。虽然可以使用其他标记，但为了将它们标识为功能参数（与另一个SIP扩展的参数相反），它们在Contact header字段中使用前导“+”符号进行编码。还允许使用URI树[3]来表示特定于供应商的功能标签。也可以使用通过IANA创建的任何其他树中的特征标记。
When using the "sip.methods" feature tag, a UA MUST NOT include values that correspond to methods not standardized in IETF standards track RFCs. When using the "sip.events" feature tag, a UA MUST NOT include values that correspond to event packages not standardized in IETF standards track RFCs. When using the "sip.schemes" feature tag, a UA MUST NOT include values that correspond to schemes not standardized in IETF standards track RFCs. When using the "sip.extensions" feature tag, a UA MUST NOT include values that correspond to option tags not standardized in IETF standards track RFCs.
当使用“sip.methods”功能标签时，UA不得包含与IETF标准中未标准化的方法相对应的值。当使用“sip.events”功能标签时，UA不得包含与IETF标准跟踪RFC中未标准化的事件包相对应的值。当使用“sip.schemes”功能标签时，UA不得包含与IETF标准跟踪RFC中未标准化的方案相对应的值。当使用“sip.extensions”功能标签时，UA不得包含与IETF标准中未标准化的选项标签相对应的值。
Note that the "sip.schemes" feature tag does not indicate the scheme of the registered URI. Rather, it indicates schemes that a UA is capable of sending requests to, should such a URI be received in a web page or Contact header field of a redirect response.
请注意，“sip.schemes”特性标记并不表示注册URI的方案。相反，它表示如果在重定向响应的网页或联系人标头字段中接收到这样的URI，UA能够向其发送请求的方案。
It is RECOMMENDED that a UA provide complete information in its contact predicate. That is, it SHOULD provide information on as many feature tags as possible. The mechanisms in this specification work best when user agents register complete feature sets. Furthermore, when a UA registers values for a particular feature tag, it MUST list all values that it supports. For example, when including the "sip.methods" feature tag, a UA MUST list all methods it supports.
建议UA在其联系人谓词中提供完整信息。也就是说，它应该提供关于尽可能多的特征标记的信息。当用户代理注册完整的功能集时，本规范中的机制工作得最好。此外，当UA注册特定功能标签的值时，它必须列出它支持的所有值。例如，当包含“sip.methods”特性标记时，UA必须列出它支持的所有方法。
The contact predicate constructed by a UA MUST be an AND of terms (called a conjunction). Each term is either an OR (called a disjunction) of simple filters or negations of simple filters, or a
UA构造的接触谓词必须是术语AND（称为连词）。每个术语要么是简单过滤器的OR（称为析取），要么是简单过滤器的否定，或者是
single simple filter or negation of a single filter. In the case of a disjunction, each filter in the disjunction MUST indicate feature values for the same feature tag (i.e., the disjunction represents a set of values for a particular feature tag), while each element of the conjunction MUST be for a different feature tag. Each simple filter can be an equality, or in the case of numeric feature tags, an inequality or range. If a string (as defined in RFC 2533 [4]) is used as the value of a simple filter, that value MUST NOT include the "<" or ">" characters, the simple filter MUST NOT be negated, and it MUST be the only simple filter for that particular feature tag. This contact predicate is then converted to a list of feature parameters, following the procedure outlined below.
单个简单过滤器或单个过滤器的求反。在析取的情况下，析取中的每个过滤器必须指示相同特征标记的特征值（即，析取表示特定特征标记的一组值），而连接的每个元素必须用于不同的特征标记。每个简单过滤器可以是一个等式，如果是数字特征标记，则可以是一个不等式或范围。如果字符串（如RFC 2533[4]中所定义）用作简单过滤器的值，则该值不得包含“<”或“>”字符，简单过滤器不得取反，并且它必须是该特定功能标签的唯一简单过滤器。然后，按照下面概述的过程，将此接触谓词转换为特征参数列表。
The contact predicate is a conjunction of terms. Each term indicates constraints on a single feature tag, and each term is represented by a separate feature parameter that will be present in the Contact header field. The syntax of this parameter depends on the feature tag. Each forward slash in the feature tag is converted to a single quote, and each colon are converted to an exclamation point. For the base tags - that is, those feature tags documented in this specification (sip.audio, sip.automata, sip.class, sip.duplex, sip.data, sip.control, sip.mobility, sip.description, sip.events, sip.priority, sip.methods, sip.extensions, sip.schemes, sip.application, sip.video, language, type, sip.isfocus, sip.actor and sip.text), the leading "sip.", if present, is stripped. For feature tags not in this list, the leading "sip." MUST NOT be stripped if present, and indeed, a plus sign ("+") MUST be added as the first character of the Contact header field parameter. The result is the feature parameter name. As a result of these rules, the base tags appear "naked" in the Contact header field - they have neither a "+" nor a "sip." prefix. All other tags will always have a leading "+" when present in the Contact header field, and will additionally have a "sip." if the tag is in the SIP tree.
接触谓词是术语的连词。每个术语表示单个特征标记上的约束，每个术语由一个单独的特征参数表示，该参数将出现在Contact header字段中。此参数的语法取决于功能标记。要素标记中的每个正斜杠都转换为单引号，每个冒号都转换为感叹号。对于基本标记-即本规范中记录的功能标记（sip.audio、sip.automata、sip.class、sip.duplex、sip.data、sip.control、sip.mobility、sip.description、sip.events、sip.priority、sip.methods、sip.extensions、sip.schemes、sip.application、sip.video、语言、类型、sip.isfocus、sip.actor和sip.text），主要“sip.”（如果存在）将被剥离。对于不在此列表中的功能标记，如果存在，则不得剥离前导的“sip.”，并且必须添加加号（“+”）作为联系人标头字段参数的第一个字符。结果是功能参数名。根据这些规则，基本标记显示为“裸”在联系人标头字段中-它们既没有“+”前缀，也没有“sip.”前缀。所有其他标记在Contact header字段中始终有一个前导“+”，如果标记在sip树中，则还会有一个“sip.”。
The value of the feature parameter depends on the term of the conjunction. If the term is a boolean expression with a value of true, i.e., (sip.audio=TRUE), the contact parameter has no value. If the term of the conjunction is a disjunction, the value of the contact parameter is a quoted string. The quoted string is a comma separated list of strings, each one derived from one of the terms in the disjunction. If the term of the conjunction is a negation, the value of the contact parameter is a quoted string. The quoted string begins with an exclamation point (!), and the remainder is constructed from the expression being negated.
特征参数的值取决于连接项。如果术语是值为true的布尔表达式，即（sip.audio=true），则contact参数没有值。如果连接项是析取，则contact参数的值是带引号的字符串。带引号的字符串是一个逗号分隔的字符串列表，每个字符串源自析取中的一个术语。如果连接项是一个否定项，则contact参数的值是一个带引号的字符串。带引号的字符串以感叹号（！）开头，其余部分由被求反的表达式构成。
The remaining operation is to compute a string from a primitive filter. If the filter is a simple filter that is performing a numeric comparison, the string starts with an octothorpe (#), followed by the
剩下的操作是从基本筛选器计算字符串。如果筛选器是执行数字比较的简单筛选器，则字符串以八进制（#）开头，后跟
comparator in the filter (=, >=, or <=), followed by the value from the filter. If the value from the filter is expressed in rational form (X / Y), then X and Y are divided, yielding a decimal number, and this decimal number is output to the string.
过滤器中的比较器（=、>=、或<=），后跟过滤器中的值。如果过滤器中的值以有理形式（X/Y）表示，则将X和Y相除，生成一个十进制数，并将该十进制数输出到字符串。
RFC 2533 uses a fractional notation to describe rational numbers. This specification uses a decimal form. The above text merely converts between the two representations. Practically speaking, this conversion is not needed since the numbers are the same in either case. However, it is described in case implementations wish to directly plug the predicates generated by the rules in this section into an RFC 2533 implementation.
RFC2533使用分数表示法来描述有理数。本规范使用十进制形式。上述文本仅在两种表示形式之间转换。实际上，由于两种情况下的数字相同，因此不需要进行这种转换。但是，在实现希望将本节中的规则生成的谓词直接插入RFC2533实现的情况下，将对其进行描述。
If the filter is a range (foo=X..Y), the string is equal to X:Y, where X and Y have been converted from fractional numbers (A / B) to their decimal equivalent.
如果过滤器是一个范围（foo=X..Y），则字符串等于X:Y，其中X和Y已从小数（a/B）转换为其十进制等效值。
If the filter is an equality over a token or boolean, then that token or boolean value ("TRUE" or "FALSE") is output to the string.
如果过滤器是令牌或布尔值上的等式，则该令牌或布尔值（“TRUE”或“FALSE”）将输出到字符串。
If the filter is an equality over a quoted string, the output is a less than (<), followed by the quoted string, followed by a greater than (>).
如果过滤器是带引号的字符串上的等式，则输出为小于（<），后跟带引号的字符串，后跟大于（>）。
As an example, this feature predicate:
例如，此功能谓词：
(& (sip.mobility=fixed)
(| (! (sip.events=presence)) (sip.events=message-summary))
(| (language=en) (language=de))
(sip.description="PC")
(sip.newparam=TRUE)
(rangeparam=-4..5125/1000))
(& (sip.mobility=fixed)
(| (! (sip.events=presence)) (sip.events=message-summary))
(| (language=en) (language=de))
(sip.description="PC")
(sip.newparam=TRUE)
(rangeparam=-4..5125/1000))
would be converted into the following feature parameters:
将转换为以下要素参数：
mobility="fixed";events="!presence,message-summary";language="en,de"
;description="<PC>";+sip.newparam;+rangeparam="#-4:+5.125"
mobility="fixed";events="!presence,message-summary";language="en,de"
;description="<PC>";+sip.newparam;+rangeparam="#-4:+5.125"
These feature tags would then appear as part of the Contact header field:
这些功能标签将作为联系人标题字段的一部分出现：
Contact: <sip:user@pc.example.com>
;mobility="fixed";events="!presence,message-summary"
;language="en,de";description="<PC>"
;+sip.newparam;+rangeparam="#-4:+5.125"
Contact: <sip:user@pc.example.com>
;mobility="fixed";events="!presence,message-summary"
;language="en,de";description="<PC>"
;+sip.newparam;+rangeparam="#-4:+5.125"
Notice how the leading "sip." was stripped from the sip.mobility, sip.events and sip.description feature tags before encoding them in
请注意，在将其编码到中之前，如何从sip.mobility、sip.events和sip.description功能标签中去掉前面的“sip.”
the Contact header field. This is because these feature tags are amongst the base tags listed above. It is for this reason that these feature tags were not encoded with a leading "+" either. However, the sip.newparam feature tag was encoded with both the "+" and its leading "sip.", and the rangeparam was also encoded with a leading "+". This is because neither of these feature tags are defined in this specification. As such, the leading "sip." is not stripped off, and a "+" is added.
联系人标题字段。这是因为这些要素标记在上面列出的基本标记中。正是由于这个原因，这些特征标记也没有使用前导“+”进行编码。但是，sip.newparam功能标记用“+”及其前导“sip.”编码，rangeparam也用前导“+”编码。这是因为本规范中未定义这两个特征标记。因此，前面的“sip.”不会被剥离，而是添加了一个“+”。
When a UA registers, it can choose to indicate a feature set associated with a registered contact. Whether or not a UA does so depends on what the registered URI represents. If the registered URI represents a UA instance (the common case in registrations), a UA compliant to this specification SHOULD indicate a feature set using the mechanisms described here. If, however, the registered URI represents an address-of-record, or some other resource that is not representable by a single feature set, it SHOULD NOT include a feature set. As an example, if a user wishes to forward calls from sip:user1@example.com to sip:user2@example.org, it could generate a registration that looks like, in part:
当UA注册时，它可以选择指示与已注册联系人关联的功能集。UA是否这样做取决于注册的URI表示什么。如果注册的URI表示UA实例（注册中的常见情况），则符合本规范的UA应使用此处描述的机制指示功能集。但是，如果注册的URI表示一个记录地址，或者某个其他资源不能由单个功能集表示，那么它不应该包括一个功能集。例如，如果用户希望转发来自sip的呼叫：user1@example.com啜饮：user2@example.org，它可以生成一个注册，该注册在某种程度上类似于：
REGISTER sip:example.com SIP/2.0
To: sip:user1@example.com
Contact: sip:user2@example.org
REGISTER sip:example.com SIP/2.0
To: sip:user1@example.com
Contact: sip:user2@example.org
In this case, the registered contact is not identifying a UA, but rather, another address-of-record. In such a case, the registered contact would not indicate a feature set.
在这种情况下，注册联系人没有识别UA，而是识别另一个记录地址。在这种情况下，注册的联系人将不会指示功能集。
However, in some cases, a UA may wish to express feature parameters for an address-of-record. One example is an AOR which represents a multiplicity of devices in a home network, and routes to a proxy server in the user's home. Since all devices in the home are for personal use, the AOR itself can be described with the ;class="personal" feature parameter. A registration that forwards calls to this home AOR could make use of that feature parameter. Generally speaking, a feature parameter can only be associated with an address-of-record if all devices bound to that address-of-record share the exact same set of values for that feature parameter.
然而，在某些情况下，UA可能希望表示记录地址的特征参数。一个示例是AOR，它表示家庭网络中的多个设备，并路由到用户家庭中的代理服务器。由于家庭中的所有设备都是供个人使用的，因此AOR本身可以用；class=“personal”特征参数。将呼叫转发到此主AOR的注册可以利用该特性参数。一般来说，如果绑定到某个记录地址的所有设备共享该特征参数的完全相同的值集，则特征参数只能与该记录地址相关联。
Similarly, in some cases, a UA can exhibit one characteristic or another, but the characteristic is not known in advance. For example, a UA could represent a device that is a phone with an embedded answering machine. The ideal way to treat such devices is to model them as if they were actually a proxy fronting two devices - a phone (which is never an answering machine), and an answering
类似地，在某些情况下，UA可以表现出一种或另一种特性，但该特性事先未知。例如，UA可以表示一个设备，它是一个带有嵌入式应答机的电话。处理这类设备的理想方法是将它们建模为两个设备的代理——一个电话（从来不是电话答录机）和一个答录机
machine (which is never a phone). The registration from this device would be constructed as if it were an AOR, as per the procedures above. Generally, this means that, unless the characteristic is identical between the logical devices, that characteristic will not be present in any registration generated by the actual device.
机器（从来不是电话）。根据上述程序，此设备的注册将被构造为一个AOR。通常，这意味着，除非逻辑设备之间的特性相同，否则该特性将不会出现在由实际设备生成的任何注册中。
The remainder of this section assumes that a UA would like to associate a feature set with a contact that it is registering. This feature set is constructed and converted to a series of Contact header field parameters, as described in Section 5, and those feature parameters are added to the Contact header field value containing the URI to which the parameters apply. The Allow, Accept, Accept-Language and Allow-Events [9] header fields are allowed in REGISTER requests, and also indicate capabilities. However, their semantic in REGISTER is different, indicating capabilities, used by the registrar, for generation of the response. As such, they are not a substitute or an alternate for the Contact feature parameters, which indicate the capabilities of the UA generally speaking.
本节其余部分假设UA希望将功能集与其正在注册的联系人相关联。如第5节所述，此功能集被构造并转换为一系列联系人标头字段参数，这些功能参数被添加到包含参数所应用的URI的联系人标头字段值中。允许在寄存器请求中使用Allow、Accept、Accept Language和Allow Events[9]头字段，并指示功能。然而，它们在REGISTER中的语义是不同的，表示注册器用于生成响应的能力。因此，它们不是触点特征参数的替代品或替代品，通常而言，触点特征参数表示UA的能力。
The REGISTER request MAY contain a Require header field with the value "pref" if the client wants to be sure that the registrar understands the extensions defined in this specification. This means that the registrar will store the feature parameters, and make them available to elements accessing the location service within the domain. In the absence of the Require header field, a registrar that does not understand this extension will simply ignore the Contact header field parameters.
如果客户端希望确保注册器理解本规范中定义的扩展，则注册请求可能包含一个值为“pref”的Require头字段。这意味着注册器将存储特征参数，并使它们可用于域内访问位置服务的元素。在缺少Require header字段的情况下，不理解此扩展的注册器将直接忽略Contact header字段参数。
If a UA registers against multiple separate addresses-of-record, and the contacts registered for each have different capabilities, a UA MUST use different URIs in each registration. This allows the UA to uniquely determine the feature set that is associated with the request URI of an incoming request.
如果UA针对多个单独的记录地址进行注册，并且为每个地址注册的联系人具有不同的功能，则UA必须在每次注册中使用不同的URI。这允许UA唯一地确定与传入请求的请求URI关联的功能集。
As an example, a voicemail server that is a UA that supports audio and video media types and is not mobile would construct a feature predicate like this:
例如，作为支持音频和视频媒体类型且不可移动的UA的语音邮件服务器将构建如下特征谓词：
(& (sip.audio=TRUE)
(sip.video=TRUE)
(sip.actor=msg-taker)
(sip.automata=TRUE)
(sip.mobility=fixed)
(| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS)
(sip.methods=ACK) (sip.methods=CANCEL)))
(& (sip.audio=TRUE)
(sip.video=TRUE)
(sip.actor=msg-taker)
(sip.automata=TRUE)
(sip.mobility=fixed)
(| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS)
(sip.methods=ACK) (sip.methods=CANCEL)))
These would be converted into feature parameters and included in the REGISTER request:
这些参数将转换为特征参数，并包含在注册请求中：
REGISTER sip:example.com SIP/2.0
From: sip:user@example.com;tag=asd98
To: sip:user@example.com
Call-ID: hh89as0d-asd88jkk@host.example.com
CSeq: 9987 REGISTER
Max-Forwards: 70
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
Contact: <sip:user@host.example.com>;audio;video
;actor="msg-taker";automata;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
Content-Length: 0
REGISTER sip:example.com SIP/2.0
From: sip:user@example.com;tag=asd98
To: sip:user@example.com
Call-ID: hh89as0d-asd88jkk@host.example.com
CSeq: 9987 REGISTER
Max-Forwards: 70
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
Contact: <sip:user@host.example.com>;audio;video
;actor="msg-taker";automata;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
Content-Length: 0
Note that a voicemail server is usually an automata and a message taker.
请注意，语音邮件服务器通常是自动机和消息接收者。
When a UAC refreshes its registration, it MUST include its feature parameters in that refresh if it wishes for them to remain active. Furthermore, when a registrar returns a 200 OK response to a REGISTER request, each Contact header field value MUST include all of the feature parameters associated with that URI.
当UAC刷新其注册时，如果希望其功能参数保持活动状态，则必须将其功能参数包括在该刷新中。此外，当注册器返回对注册请求的200OK响应时，每个联系人头字段值必须包括与该URI关联的所有特征参数。
Target refresh requests and responses are used to establish and modify the remote target URI in a dialog. The remote target URI is conveyed in the Contact header field. A UAC or UAS MAY add feature parameters to the Contact header field value in target refresh requests and responses for the purpose of indicating the capabilities of the UA. To do that, it constructs a set of feature parameters according to Section 5. These are then added as Contact header field parameters in the request or response.
目标刷新请求和响应用于在对话框中建立和修改远程目标URI。远程目标URI在Contact header字段中传输。UAC或UAS可以向目标刷新请求和响应中的联系人标头字段值添加特征参数，以指示UA的能力。为此，它根据第5节构造了一组特征参数。然后将这些添加为请求或响应中的联系人标头字段参数。
The feature parameters can be included in both initial requests and mid-dialog requests, and MAY change mid-dialog to signal a change in UA capabilities.
特征参数可以包含在初始请求和mid对话请求中，并且可以更改mid对话以表示UA能力的更改。
There is overlap in the callee capabilities mechanism with the Allow, Accept, Accept-Language, and Allow-Events [9] header fields, which can also be used in target refresh requests. Specifically, the Allow header field and "sip.methods" feature tag indicate the same information. The Accept header field and the "type" feature tag indicate the same information. The Accept-Language header field and the "language" feature tag indicate the same information. The Allow-Events header field and the "sip.events" feature tag indicate the same information. It is possible that other header fields and
被调用方功能机制与Allow、Accept、Accept Language和Allow Events[9]头字段存在重叠，这些字段也可用于目标刷新请求。具体来说，Allow header字段和“sip.methods”特性标记表示相同的信息。Accept header字段和“type”功能标记表示相同的信息。Accept Language header字段和“Language”功能标记表示相同的信息。Allow Events标头字段和“sip.Events”功能标签表示相同的信息。其他标题字段和
feature tags defined in the future may also overlap. When there exists a feature tag that describes a capability that can also be represented with a SIP header field, a UA MUST use the header field to describe the capability. A UA receiving a message that contains both the header field and the feature tag MUST use the header field, and not the feature tag.
将来定义的要素标记也可能重叠。当存在描述也可以用SIP头字段表示的功能的功能标签时，UA必须使用头字段来描述该功能。接收包含标题字段和功能标签的消息的UA必须使用标题字段，而不是功能标签。
When a UAS compliant to this specification receives an OPTIONS request, it MAY add feature parameters to the Contact header field in the OPTIONS response for the purpose of indicating the capabilities of the UA. To do that, it constructs a set of feature parameters according to Section 5. These are then added as Contact header field parameters in OPTIONS response. Indeed, if feature parameters were included in the registration generated by that UA, those same parameters SHOULD be used in the OPTIONS response.
当符合本规范的UAS收到选项请求时，它可能会在选项响应中的联系人标头字段中添加功能参数，以指示UA的能力。为此，它根据第5节构造了一组特征参数。然后在选项响应中将这些添加为联系人标题字段参数。事实上，如果特征参数包含在该UA生成的注册中，则这些参数应在选项响应中使用。
The guidelines in Section 7 regarding the overlap of the various callee capabilities feature tags with SIP header fields applies to the generation of OPTIONS responses as well. In particular, they apply when a Contact header field is describing the UA which generated the OPTIONS response. When a Contact header field in the OPTIONS response is identifying a different UA, there is no overlap.
第7节中关于各种被叫方功能特征标记与SIP头字段重叠的指南也适用于选项响应的生成。特别是，当联系人标题字段描述生成选项响应的UA时，它们适用。当选项响应中的联系人标题字段标识不同的UA时，不存在重叠。
This specification extends the Contact header field. In particular, it allows for the Contact header field parameters to include feature-param. Feature-param is a feature parameter that describes a feature of the UA associated with the URI in the Contact header field. Feature parameters are identifiable because they either belong to the well known set of base feature tags, or they begin with a plus sign.
本规范扩展了联系人标题字段。特别是，它允许联系人标题字段参数包括功能参数。Feature param是一个功能参数，用于描述与联系人标头字段中的URI关联的UA功能。特征参数是可识别的，因为它们要么属于众所周知的基本特征标记集，要么以加号开头。
feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list
/ string-value ) RDQUOT]
enc-feature-tag = base-tags / other-tags
base-tags = "audio" / "automata" /
"class" / "duplex" / "data" /
"control" / "mobility" / "description" /
"events" / "priority" / "methods" /
"schemes" / "application" / "video" /
"language" / "type" / "isfocus" /
"actor" / "text" / "extensions"
other-tags = "+" ftag-name
ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" /
"." / "-" / "%" )
feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list
/ string-value ) RDQUOT]
enc-feature-tag = base-tags / other-tags
base-tags = "audio" / "automata" /
"class" / "duplex" / "data" /
"control" / "mobility" / "description" /
"events" / "priority" / "methods" /
"schemes" / "application" / "video" /
"language" / "type" / "isfocus" /
"actor" / "text" / "extensions"
other-tags = "+" ftag-name
ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" /
"." / "-" / "%" )
tag-value-list = tag-value *("," tag-value)
tag-value = ["!"] (token-nobang / boolean / numeric)
token-nobang = 1*(alphanum / "-" / "." / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
boolean = "TRUE" / "FALSE"
numeric = "#" numeric-relation number
numeric-relation = ">=" / "<=" / "=" / (number ":")
number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]
string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">"
qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D
/ %x3F-5B / %x5D-7E / UTF8-NONASCII
tag-value-list = tag-value *("," tag-value)
tag-value = ["!"] (token-nobang / boolean / numeric)
token-nobang = 1*(alphanum / "-" / "." / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
boolean = "TRUE" / "FALSE"
numeric = "#" numeric-relation number
numeric-relation = ">=" / "<=" / "=" / (number ":")
number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]
string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">"
qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D
/ %x3F-5B / %x5D-7E / UTF8-NONASCII
Note that the tag-value-list uses an actual comma instead of the COMMA construction because it appears within a quoted string, where line folding cannot take place.
请注意，标记值列表使用实际的逗号而不是逗号结构，因为它出现在带引号的字符串中，不能进行折线。
The production for qdtext can be found in RFC 3261 [1].
qdtext的产品可在RFC 3261[1]中找到。
There are additional constraints on the usage of feature-param that cannot be represented in a BNF. There MUST only be one instance of any feature tag in feature-param. Any numbers present in a feature parameter MUST be representable using an ANSI C double.
对于无法在BNF中表示的功能参数的使用，还有其他限制。feature param中任何feature标记只能有一个实例。特征参数中的任何数字都必须使用ANSI C双精度表示。
The following production updates the one in RFC 3261 [1] for contact-params:
以下产品更新了RFC 3261[1]中的联系人参数：
contact-params = c-p-q / c-p-expires / feature-param
/ contact-extension
contact-params = c-p-q / c-p-expires / feature-param
/ contact-extension
This specification defines an initial set of media feature tags for use with this specification. This section serves as the IANA registration for these feature tags, which are made into the SIP media feature tag tree. New media feature tags are registered in the IETF or global trees based on the process defined for feature tag registrations [3], or in the SIP tree based on the process defined in Section 12.1.
本规范定义了与本规范一起使用的一组初始媒体功能标签。本节作为这些功能标签的IANA注册，这些功能标签被制作到SIP媒体功能标签树中。根据为特征标签注册定义的过程[3]，或根据第12.1节中定义的过程，在IETF或全局树中注册新媒体特征标签，或在SIP树中注册新媒体特征标签。
Any registered feature tags MAY be used with this specification. However, several existing ones appear to be particularly applicable. These include the language feature tag [6], which can be used to specify the language of the human or automata represented by the UA, and the type feature tag [7], which can be used to specify the MIME types that a SIP UA can receive in a SIP message. The audio, video, application, data, and control feature tags in the SIP tree (each of which indicate a media type, as defined in RFC 2327 [8]) are different. They do not indicate top level MIME types which can be
任何已注册的特征标签均可与本规范一起使用。然而，现有的一些建议似乎特别适用。其中包括可用于指定UA所代表的人类或自动机的语言的语言特征标记[6]，以及可用于指定SIP UA可在SIP消息中接收的MIME类型的类型特征标记[7]。SIP树中的音频、视频、应用程序、数据和控制功能标签（每个标签指示媒体类型，如RFC 2327[8]中所定义）是不同的。它们并不表示可以使用的顶级MIME类型
received in SIP requests. Rather, they indicate media types that can be used in media streams, and as a result, match up with the types defined in RFC 2327 [8].
在SIP请求中接收。相反，它们表示可以在媒体流中使用的媒体类型，因此与RFC 2327[8]中定义的类型匹配。
If a new SDP media type were to be defined, such as "message", a new feature tag registration SHOULD be created for it in the SIP tree. The name of the feature tag MUST equal "sip." concatenated with the name of the media type, unless there is an unlikely naming collision between the new media type and an existing feature tag registration. As a result, implementations can safely construct caller preferences and callee capabilities for the new media type before it is registered, as long as there is no naming conflict.
如果要定义新的SDP媒体类型，如“消息”，则应在SIP树中为其创建新的功能标签注册。功能标签的名称必须等于“sip.”并与媒体类型的名称连接，除非新媒体类型和现有功能标签注册之间不太可能存在命名冲突。因此，只要不存在命名冲突，实现就可以在注册新媒体类型之前安全地为其构造调用者首选项和被调用者功能。
If a new media feature tag is registered with the intent of using that tag with this specification, the registration is done for the unencoded form of the tag (see Section 5). In other words, if a new feature tag "foo" is registered in the IETF tree, the IANA registration would be for the tag "foo" and not "+foo". Similarly, if a new feature tag "sip.gruu" is registered in the SIP tree, the IANA registration would be for the tag "sip.gruu" and not "+sip.gruu" or "gruu". As such, all registrations into the SIP tree will have the "sip." prefix.
如果注册了一个新的媒体功能标签，目的是将该标签与本规范一起使用，则对该标签的未编码形式进行注册（见第5节）。换句话说，如果在IETF树中注册了一个新的功能标签“foo”，那么IANA注册将针对标签“foo”而不是“+foo”。类似地，如果在sip树中注册了一个新的功能标签“sip.gru”，IANA注册将针对标签“sip.gru”，而不是“+sip.gru”或“gru”。因此，SIP树中的所有注册都将具有“SIP.”前缀。
The feature tags in this section are all registered in the SIP media feature tag tree created by Section 12.1.
本节中的功能标签均注册在第12.1节创建的SIP媒体功能标签树中。
Media feature tag name: sip.audio
媒体功能标签名称：sip.audio
ASN.1 Identifier: 1.3.6.1.8.4.1
ASN.1标识符：1.3.6.1.8.4.1
Summary of the media feature indicated by this tag: This feature tag indicates that the device supports audio as a streaming media type.
此标签指示的媒体功能摘要：此功能标签指示设备支持音频作为流媒体类型。
Values appropriate for use with this feature tag: Boolean.
适用于此功能标记的值：布尔值。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Routing a call to a phone that can support audio.
典型用途示例：将呼叫路由到支持音频的电话。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.application
媒体功能标签名称：sip.application
ASN.1 Identifier: 1.3.6.1.8.4.2
ASN.1标识符：1.3.6.1.8.4.2
Summary of the media feature indicated by this tag: This feature tag indicates that the device supports application as a streaming media type. This feature tag exists primarily for completeness. Since so many MIME types are underneath application, indicating the ability to support applications provides little useful information.
此标签指示的媒体功能摘要：此功能标签指示设备支持应用程序作为流媒体类型。此功能标签的存在主要是为了完整性。由于应用程序下面有如此多的MIME类型，指示支持应用程序的能力提供的有用信息很少。
Values appropriate for use with this feature tag: Boolean.
适用于此功能标记的值：布尔值。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
该特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述诸如电话或PDA之类的设备的能力。
Examples of typical use: Routing a call to a phone that can support a media control application.
典型用途示例：将呼叫路由到支持媒体控制应用程序的电话。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.data
媒体功能标签名称：sip.data
ASN.1 Identifier: 1.3.6.1.8.4.3
ASN.1标识符：1.3.6.1.8.4.3
Summary of the media feature indicated by this tag: This feature tag indicates that the device supports data as a streaming media type.
此标签指示的媒体功能摘要：此功能标签指示设备支持数据作为流媒体类型。
Values appropriate for use with this feature tag: Boolean.
适用于此功能标记的值：布尔值。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Routing a call to a phone that can support a data streaming application.
典型用途示例：将呼叫路由到支持数据流应用程序的电话。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.control
媒体功能标签名称：sip.control
ASN.1 Identifier: 1.3.6.1.8.4.4
ASN.1标识符：1.3.6.1.8.4.4
Summary of the media feature indicated by this tag: This feature tag indicates that the device supports control as a streaming media type.
此标签指示的媒体功能摘要：此功能标签指示设备支持控制作为流媒体类型。
Values appropriate for use with this feature tag: Boolean.
适用于此功能标记的值：布尔值。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Routing a call to a phone that can support a floor control application.
典型用途示例：将呼叫路由到支持楼层控制应用程序的电话。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.video
媒体功能标签名称：sip.video
ASN.1 Identifier: 1.3.6.1.8.4.5
ASN.1标识符：1.3.6.1.8.4.5
Summary of the media feature indicated by this tag: This feature tag indicates that the device supports video as a streaming media type.
此标签指示的媒体功能摘要：此功能标签指示设备支持视频作为流媒体类型。
Values appropriate for use with this feature tag: Boolean.
适用于此功能标记的值：布尔值。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Routing a call to a phone that can support video.
典型用途示例：将呼叫路由到支持视频的电话。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.text
媒体功能标签名称：sip.text
ASN.1 Identifier: 1.3.6.1.8.4.6
ASN.1标识符：1.3.6.1.8.4.6
Summary of the media feature indicated by this tag: This feature tag indicates that the device supports text as a streaming media type.
此标签指示的媒体功能摘要：此功能标签指示设备支持文本作为流媒体类型。
Values appropriate for use with this feature tag: Boolean.
适用于此功能标记的值：布尔值。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Routing a call to a phone that can support text.
典型用途示例：将呼叫路由到支持文本的电话。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.automata
媒体功能标签名称：sip.automata
ASN.1 Identifier: 1.3.6.1.8.4.7
ASN.1标识符：1.3.6.1.8.4.7
Summary of the media feature indicated by this tag: The sip.automata feature tag is a boolean value that indicates whether the UA represents an automata (such as a voicemail server, conference server, IVR, or recording device) or a human.
此标记指示的媒体功能摘要：sip.automata功能标记是一个布尔值，指示UA是表示自动机（如语音邮件服务器、会议服务器、IVR或录音设备）还是表示人。
Values appropriate for use with this feature tag: Boolean. TRUE indicates that the UA represents an automata.
适用于此功能标记的值：布尔值。TRUE表示UA表示自动机。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Refusing to communicate with an automata when it is known that automated services are unacceptable.
典型用途示例：当已知自动化服务不可接受时，拒绝与自动机通信。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.class
媒体功能标签名称：sip.class
ASN.1 Identifier: 1.3.6.1.8.4.8
ASN.1标识符：1.3.6.1.8.4.8
Summary of the media feature indicated by this tag: This feature tag indicates the setting, business or personal, in which a communications device is used.
此标签指示的媒体功能摘要：此功能标签指示使用通信设备的设置（业务或个人）。
Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:
适用于此功能标记的值：具有相等关系的标记。典型值包括：
business: The device is used for business communications.
业务：该设备用于业务通信。
personal: The device is used for personal communications.
个人：该设备用于个人通信。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
该特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述诸如电话或PDA之类的设备的能力。
Examples of typical use: Choosing between a business phone and a home phone.
典型用途示例：在商用电话和家用电话之间进行选择。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.duplex
媒体功能标签名称：sip.duplex
ASN.1 Identifier: 1.3.6.1.8.4.9
ASN.1标识符：1.3.6.1.8.4.9
Summary of the media feature indicated by this tag: The sip.duplex media feature tag indicates whether a communications device can simultaneously send and receive media ("full"), alternate between sending and receiving ("half"), can only receive ("receive-only") or only send ("send-only").
此标签指示的媒体功能概述：sip.duplex媒体功能标签指示通信设备是否可以同时发送和接收媒体（“全”），发送和接收之间的交替（“半”），只能接收（“仅接收”）或仅发送（“仅发送”）。
Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:
适用于此功能标记的值：具有相等关系的标记。典型值包括：
full: The device can simultaneously send and receive media.
完全：设备可以同时发送和接收媒体。
half: The device can alternate between sending and receiving media.
一半：设备可以在发送和接收媒体之间切换。
receive-only: The device can only receive media.
仅接收：设备只能接收媒体。
send-only: The device can only send media.
仅发送：设备只能发送媒体。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Choosing to communicate with a broadcast server, as opposed to a regular phone, when making a call to hear an announcement.
典型用途示例：在拨打电话收听公告时，选择与广播服务器通信，而不是与普通电话通信。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.mobility
媒体功能标签名称：sip.mobility
ASN.1 Identifier: 1.3.6.1.8.4.10
ASN.1标识符：1.3.6.1.8.4.10
Summary of the media feature indicated by this tag: The sip.mobility feature tag indicates whether the device is fixed (meaning that it is associated with a fixed point of contact with the network), or
此标签指示的媒体功能摘要：sip.mobility功能标签指示设备是固定的（意味着它与网络的固定接触点相关联），还是
mobile (meaning that it is not associated with a fixed point of contact). Note that cordless phones are fixed, not mobile, based on this definition.
移动的（意味着它与固定的接触点无关）。请注意，根据此定义，无绳电话是固定的，而不是移动的。
Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:
适用于此功能标记的值：具有相等关系的标记。典型值包括：
fixed: The device is stationary.
固定：设备处于静止状态。
mobile: The device can move around with the user.
移动：设备可以与用户一起移动。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Choosing to communicate with a wireless phone instead of a desktop phone.
典型使用示例：选择使用无线电话而不是台式电话进行通信。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.description
媒体功能标签名称：sip.description
ASN.1 Identifier: 1.3.6.1.8.4.11
ASN.1标识符：1.3.6.1.8.4.11
Summary of the media feature indicated by this tag: The sip.description feature tag provides a textual description of the device.
此标记指示的媒体功能摘要：sip.description功能标记提供设备的文本描述。
Values appropriate for use with this feature tag: String with an equality relationship.
适用于此功能标记的值：具有相等关系的字符串。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Indicating that a device is of a certain make and model.
典型用途示例：表示设备具有特定品牌和型号。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.events
媒体功能标签名称：sip.events
ASN.1 Identifier: 1.3.6.1.8.4.12
ASN.1标识符：1.3.6.1.8.4.12
Summary of the media feature indicated by this tag: Each value of the sip.events (note the plurality) feature tag indicates a SIP event package [9] supported by a SIP UA. The values for this tag equal the event package names that are registered by each event package.
由该标签指示的媒体特征概述：sip.events（注意，多个）特征标签的每个值指示sip UA支持的sip事件包[9]。此标记的值等于每个事件包注册的事件包名称。
Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the IANA SIP Event types namespace registry.
适用于此功能标记的值：具有相等关系的标记。值取自IANA SIP事件类型命名空间注册表。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Choosing to communicate with a server that supports the message waiting event package, such as a voicemail server [12].
典型使用示例：选择与支持消息等待事件包的服务器通信，如语音邮件服务器[12]。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.priority
媒体功能标签名称：sip.priority
ASN.1 Identifier: 1.3.6.1.8.4.13
ASN.1标识符：1.3.6.1.8.4.13
Summary of the media feature indicated by this tag: The sip.priority feature tag indicates the call priorities the device is willing to handle. A value of X means that the device is willing to take requests with priority X and higher. This does not imply that a phone has to reject calls of lower priority. As always, the decision on handling of such calls is a matter of local policy.
此标记指示的媒体功能摘要：sip.priority功能标记指示设备愿意处理的呼叫优先级。值X表示设备愿意接受优先级为X或更高的请求。这并不意味着手机必须拒绝较低优先级的通话。一如既往，处理此类电话的决定取决于当地政策。
Values appropriate for use with this feature tag: An integer. Each integral value corresponds to one of the possible values of the Priority header field as specified in SIP [1]. The mapping is defined as:
适用于此功能标记的值：整数。每个整数值对应于SIP[1]中指定的优先级标头字段的一个可能值。映射定义为：
non-urgent: Integral value of 10. The device supports non-urgent calls.
非紧急：整数值为10。该设备支持非紧急呼叫。
normal: Integral value of 20. The device supports normal calls.
正常：整数值为20。该设备支持正常通话。
urgent: Integral value of 30. The device supports urgent calls.
紧急：整数值为30。该设备支持紧急呼叫。
emergency: Integral value of 40. The device supports calls in the case of an emergency situation.
紧急情况：整数值为40。该设备支持紧急情况下的呼叫。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Choosing to communicate with the emergency cell phone of a user.
典型用途示例：选择与用户的应急手机通信。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.methods
媒体功能标签名称：sip.methods
ASN.1 Identifier: 1.3.6.1.8.4.14
ASN.1标识符：1.3.6.1.8.4.14
Summary of the media feature indicated by this tag: Each value of the sip.methods (note the plurality) feature tag indicates a SIP method supported by this UA. In this case, "supported" means that the UA can receive requests with this method. In that sense, it has the same connotation as the Allow header field.
由该标签指示的媒体特征概述：sip.methods（注意多个）特征标签的每个值指示该UA支持的sip方法。在这种情况下，“受支持”意味着UA可以使用此方法接收请求。从这个意义上讲，它与Allow header字段具有相同的含义。
Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the Methods table defined in the IANA SIP parameters registry.
适用于此功能标记的值：具有相等关系的标记。值取自IANA SIP参数注册表中定义的方法表。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Choosing to communicate with a presence application on a PC, instead of a PC phone application.
典型使用示例：选择与PC上的状态应用程序通信，而不是与PC电话应用程序通信。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.extensions
媒体功能标签名称：sip.extensions
ASN.1 Identifier: 1.3.6.1.8.4.15
ASN.1标识符：1.3.6.1.8.4.15
Summary of the media feature indicated by this tag: Each value of the sip.extensions feature tag (note the plurality) is a SIP extension (each of which is defined by an option-tag registered with IANA) that is understood by the UA. Understood, in this context, means that the option tag would be included in a Supported header field in a request.
由该标签指示的媒体特征概述：sip.extensions特征标签（注意，多个）的每个值是UA理解的sip扩展（每个由注册到IANA的选项标签定义）。在此上下文中，理解意味着选项标记将包含在请求中受支持的头字段中。
Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the option tags table in the IANA SIP parameters registry.
适用于此功能标记的值：具有相等关系的标记。值取自IANA SIP参数注册表中的选项标记表。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Choosing to communicate with a phone that supports quality of service preconditions instead of one that does not.
典型用途示例：选择支持服务质量前提条件的手机，而不是不支持服务质量前提条件的手机。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.schemes
媒体功能标签名称：sip.schemes
ASN.1 Identifier: 1.3.6.1.8.4.16
ASN.1标识符：1.3.6.1.8.4.16
Summary of the media feature indicated by this tag: Each value of the sip.schemes (note the plurality) media feature tag indicates a URI scheme [10] that is supported by a UA. Supported implies, for
由该标记指示的媒体特征概述：sip.schemes（注意，多个）媒体特征标记的每个值指示UA支持的URI方案[10]。支持意味着
example, that the UA would know how to handle a URI of that scheme in the Contact header field of a redirect response.
例如，UA将知道如何在重定向响应的Contact header字段中处理该方案的URI。
Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the IANA URI scheme registry.
适用于此功能标记的值：具有相等关系的标记。值取自IANA URI方案注册表。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Choosing to get redirected to a phone number when a called party is busy, rather than a web page.
典型用法示例：当被叫方忙时，选择重定向到电话号码，而不是网页。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.actor
媒体功能标签名称：sip.actor
ASN.1 Identifier: 1.3.6.1.8.4.17
ASN.1标识符：1.3.6.1.8.4.17
Summary of the media feature indicated by this tag: This feature tag indicates the type of entity that is available at this URI.
此标记指示的媒体功能摘要：此功能标记指示此URI上可用的实体类型。
Values appropriate for use with this feature tag: Token with an equality relationship. The following values are defined:
适用于此功能标记的值：具有相等关系的标记。定义了以下值：
principal: The device provides communication with the principal that is associated with the device. Often this will be a specific human being, but it can be an automata (for example, when calling a voice portal).
主体：设备提供与与设备关联的主体的通信。通常，这是一个特定的人，但也可以是一个自动机（例如，在呼叫语音门户时）。
attendant: The device provides communication with an automaton or person that will act as an intermediary in contacting the principal associated with the device, or a substitute.
服务员：该设备提供与自动机或人员的通信，该自动机或人员将作为联系与该设备相关的主体或替代者的中介。
msg-taker: The device provides communication with an automaton or person that will take messages and deliver them to the principal.
消息接受者：该设备提供与自动装置或人员的通信，自动装置或人员将接收消息并将其发送给负责人。
information: The device provides communication with an automaton or person that will provide information about the principal.
信息：设备提供与自动机或人员的通信，自动机或人员将提供有关委托人的信息。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Requesting that a call not be routed to voicemail.
典型用途示例：请求呼叫不被路由到语音邮件。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.isfocus
媒体功能标签名称：sip.isfocus
ASN.1 Identifier: 1.3.6.1.8.4.18
ASN.1标识符：1.3.6.1.8.4.18
Summary of the media feature indicated by this tag: This feature tag indicates that the UA is a conference server, also known as a focus, and will mix together the media for all calls to the same URI [13].
此标签指示的媒体功能摘要：此功能标签指示UA是一个会议服务器，也称为焦点，并将混合媒体用于对同一URI的所有调用[13]。
Values appropriate for use with this feature tag: Boolean.
适用于此功能标记的值：布尔值。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.
特征标签主要用于以下应用、协议、服务或协商机制：该特征标签在通信应用中最有用，用于描述设备（例如电话或PDA）的功能。
Examples of typical use: Indicating to a UA that the server to which it has connected is a conference server.
典型用途示例：向UA指示其连接的服务器是会议服务器。
Related standards or documents: RFC 3840
相关标准或文件：RFC 3840
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
This section discusses security considerations for the media feature tags, including, but not limited to, this specification.
本节讨论媒体功能标签的安全注意事项，包括但不限于本规范。
The media feature tags defined in Section 10 reveal sensitive information about a user or the user agent they are describing. Some of the feature tags convey capability information about the agent - for example, the media types it can support, the SIP methods it can support, and the SIP extensions it can support. This capability information might be used for industrial espionage, for example, and so its protection may be important. Other attributes, such as the mobility, priority, and isfocus attributes, reveal characteristics of the user agent. These attributes are more sensitive than the capability information. They describe the way in which a user agent is utilized by a user, and thus reveal information about user preferences and the ways in which they want calls handled. Some feature tags, such as languages, reveal information about the user themself. As a result, applications which utilize these media feature tags SHOULD provide a means for ensuring their confidentiality.
第10节中定义的媒体功能标签揭示了用户或其所描述的用户代理的敏感信息。一些功能标签传递有关代理的功能信息—例如，它可以支持的媒体类型、它可以支持的SIP方法以及它可以支持的SIP扩展。例如，这种能力信息可能用于工业间谍活动，因此其保护可能很重要。其他属性，如移动性、优先级和isfocus属性，揭示了用户代理的特征。这些属性比能力信息更敏感。它们描述了用户使用用户代理的方式，从而揭示了有关用户偏好的信息以及他们希望处理呼叫的方式。某些功能标记（如语言）会显示有关用户自身的信息。因此，使用这些媒体功能标签的应用程序应提供确保其机密性的方法。
The media feature tags can be used in ways which affect application behaviors. For example, the SIP caller preferences extension [11] allows for call routing decisions to be based on the values of these parameters. Therefore, if an attacker can modify the values of these feature tags, they may be able to affect the behavior of applications. As a result of this, applications which utilize these media feature tags SHOULD provide a means for ensuring their integrity. Similarly, media feature tags should only be trusted as valid when they come from the user or user agent described by those feature tags. As a result, mechanisms for conveying feature tags SHOULD provide a mechanism for guaranteeing authenticity.
媒体功能标签的使用方式会影响应用程序的行为。例如，SIP呼叫者偏好扩展[11]允许呼叫路由决策基于这些参数的值。因此，如果攻击者可以修改这些功能标签的值，它们可能会影响应用程序的行为。因此，使用这些媒体功能标签的应用程序应提供确保其完整性的方法。类似地，只有当媒体功能标签来自这些功能标签所描述的用户或用户代理时，才应将其视为有效。因此，传递特征标签的机制应该提供一种保证真实性的机制。
As per the general requirements in Section 11.1, when media feature tags are carried in a registration, authenticity, confidentiality, and integrity need to be provided. To accomplish this, registrations containing capability information SHOULD be made by addressing the registration to a SIPS URI (in other words, the Request URI of the request would be sips:example.com when creating a registration in the example.com domain). Furthermore, the registrar SHOULD challenge the UA using digest over TLS, to verify its authenticity. The combination of TLS and digest provide integrity, confidentiality, and authenticity, as required.
根据第11.1节中的一般要求，当在注册中携带媒体功能标签时，需要提供真实性、保密性和完整性。为此，应通过将注册寻址到SIPS URI（换句话说，在example.com域中创建注册时，请求的请求URI将为SIPS:example.com）来进行包含能力信息的注册。此外，注册官应使用TLS上的摘要对UA提出质疑，以验证其真实性。TLS和摘要的结合根据需要提供完整性、机密性和真实性。
It is not necessary for the Contact in the registration to itself contain a sips URI, since the feature tags are not carried in incoming requests sent to the UA.
注册中的联系人本身不必包含sips URI，因为发送给UA的传入请求中不携带功能标签。
When including information on capabilities in a response to an OPTIONS request, a UA SHOULD verify with the user (either through a user interface or though prior configuration) whether or not capability information should be divulged to the requester. If the identity of the requester cannot be cryptographically verified (using digest or the SIP identity enhancements [15]), the user SHOULD also be alerted to this fact, and be allowed to choose whether such information should be divulged.
当在对选项请求的响应中包含有关能力的信息时，UA应与用户核实（通过用户界面或通过事先配置）是否应将能力信息泄露给请求者。如果请求者的身份无法通过密码验证（使用摘要或SIP身份增强[15]），则还应提醒用户这一事实，并允许用户选择是否应泄露此类信息。
If the user does wish to reveal capability information to the requester, and wishes to guarantee its confidentiality, but the request did not arrive using SIPS, the UAS SHOULD redirect the request to a sips URI. This will cause the UAC to send the OPTIONS request using SIPS instead, and therefore provide confidentiality of any responses sent over the secure connections.
如果用户确实希望向请求者透露能力信息，并希望保证其机密性，但请求未使用SIPS到达，则UAS应将请求重定向到SIPS URI。这将导致UAC改为使用SIPS发送选项请求，从而为通过安全连接发送的任何响应提供机密性。
Furthermore, S/MIME MAY be used in the OPTIONS response. In that case, the capability information would be contained only in the secured S/MIME body, and not in the header fields of the OPTIONS response.
此外，可以在选项响应中使用S/MIME。在这种情况下，功能信息将仅包含在安全的S/MIME正文中，而不包含在选项响应的头字段中。
When a UAS generates a response that will initiate a dialog, and they wish to include capability information in the Contact header field, the same considerations as described in Section 11.3 apply.
当UAS生成将启动对话的响应，并且他们希望在联系人标题字段中包含能力信息时，第11.3节中描述的注意事项同样适用。
When a UAC generates a request that will initiate a dialog, it SHOULD obtain permission from the user (either through a user interface or apriori configuration) before including capability information in the Contact header field of the request. Confidentiality and integrity of the information SHOULD be provided using SIPS. S/MIME MAY be used.
当UAC生成将启动对话的请求时，它应该在请求的Contact header字段中包含功能信息之前获得用户的许可（通过用户界面或apriori配置）。应使用SIPS提供信息的机密性和完整性。可以使用S/MIME。
There are a number of IANA considerations associated with this specification.
与本规范相关的IANA注意事项有很多。
This specification serves to create a new media feature tag registration tree, per the guidelines of Section 3.1.4 of RFC 2506 [3]. The name of this tree is the "SIP Media Feature Tag Registration Tree", and its prefix is "sip.". It is used for the registration of media feature tags that are applicable to the Session
本规范用于根据RFC 2506[3]第3.1.4节的指南创建新的媒体功能标签注册树。此树的名称为“SIP媒体功能标签注册树”，其前缀为“SIP”。它用于注册适用于会话的媒体功能标签
Initiation Protocol, and whose meaning is only defined within that usage.
初始协议，其含义仅在该用法中定义。
The addition of entries into this registry occurs through IETF consensus, as defined in RFC 2434 [18]. This requires the publication of an RFC that contains the registration. The information required in the registration is identical to the IETF tree. As such, specifications adding entries to the registry should use the template provided in Section 3.4 of RFC 2506. Note that all media feature tags registered in the SIP tree will have names with a prefix of "sip.". No leading "+" is used in the registrations in any of the media feature tag trees.
按照RFC 2434[18]中的定义，通过IETF共识将条目添加到此注册表中。这需要发布包含注册的RFC。注册所需的信息与IETF树相同。因此，向注册表添加条目的规范应使用RFC 2506第3.4节中提供的模板。请注意，在SIP树中注册的所有媒体功能标签的名称都带有前缀“SIP”。在任何媒体功能标记树中的注册中都不使用前导“+”。
This specification registers a number of new Media feature tags according to the procedures of RFC 2506 [3]. These registrations are all made in the newly created SIP tree for media feature tags. These registrations are:
本规范根据RFC 2506[3]的程序注册了许多新的媒体功能标签。这些注册都是在新创建的媒体功能标签SIP树中进行的。这些注册是：
sip.audio: The information for registering the sip.audio media feature tag is contained in Section 10.1.
sip.audio：注册sip.audio媒体功能标签的信息包含在第10.1节中。
sip.application: The information for registering the sip.application media feature tag is contained in Section 10.2.
sip.application：注册sip.application媒体功能标签的信息包含在第10.2节中。
sip.data: The information for registering the sip.data media feature tag is contained in Section 10.3.
sip.data：注册sip.data媒体功能标签的信息包含在第10.3节中。
sip.control: The information for registering the sip.control media feature tag is contained in Section 10.4.
sip.control：注册sip.control介质功能标签的信息包含在第10.4节中。
sip.video: The information for registering the sip.video media feature tag is contained in Section 10.5.
sip.video：注册sip.video媒体功能标签的信息包含在第10.5节中。
sip.text: The information for registering the sip.text media feature tag is contained in Section 10.6.
sip.text：注册sip.text媒体功能标签的信息包含在第10.6节中。
sip.automata: The information for registering the sip.automata media feature tag is contained in Section 10.7.
sip.automata：注册sip.automata媒体功能标签的信息包含在第10.7节中。
sip.class: The information for registering the sip.class media feature tag is contained in Section 10.8.
sip.class：注册sip.class媒体功能标签的信息包含在第10.8节中。
sip.duplex: The information for registering the sip.duplex media feature tag is contained in Section 10.9.
sip.duplex：注册sip.duplex介质功能标签的信息包含在第10.9节中。
sip.mobility: The information for registering the sip.mobility media feature tag is contained in Section 10.10.
sip.mobility：注册sip.mobility媒体功能标签的信息包含在第10.10节中。
sip.description: The information for registering the sip.description media feature tag is contained in Section 10.11.
sip.description：注册sip.description媒体功能标签的信息包含在第10.11节中。
sip.events: The information for registering the sip.events media feature tag is contained in Section 10.12.
sip.events：注册sip.events媒体功能标签的信息包含在第10.12节中。
sip.priority: The information for registering the sip.priority media feature tag is contained in Section 10.13.
sip.priority：注册sip.priority媒体功能标签的信息包含在第10.13节中。
sip.methods: The information for registering the sip.methods media feature tag is contained in Section 10.14.
sip.methods：注册sip.methods媒体功能标签的信息包含在第10.14节中。
sip.extensions: The information for registering the sip.extensions media feature tag is contained in Section 10.15.
sip.extensions：注册sip.extensions媒体功能标签的信息包含在第10.15节中。
sip.schemes: The information for registering the sip.schemes media feature tag is contained in Section 10.16.
sip.schemes：注册sip.schemes媒体功能标签的信息包含在第10.16节中。
sip.actor: The information for registering the sip.actor media feature tag is contained in Section 10.17.
sip.actor：注册sip.actor媒体功能标签的信息包含在第10.17节中。
sip.isfocus: The information for registering the sip.isfocus media feature tag is contained in Section 10.18.
sip.isfocus：注册sip.isfocus媒体功能标签的信息包含在第10.18节中。
This specification registers a single SIP option tag, pref. The required information for this registration, as specified in RFC 3261 [1], is:
本规范注册了一个SIP选项标签pref。RFC 3261[1]中规定的注册所需信息为：
Name: pref
姓名：pref
Description: This option tag is used in a Require header field of a registration to ensure that the registrar supports the caller preferences extensions.
描述：此选项标记用于注册的Require头字段，以确保注册器支持呼叫者首选项扩展。
The initial set of media feature tags used by this specification were influenced by Scott Petrack's CMA design. Jonathan Lennox, Bob Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, and John Hearty provided helpful comments. Graham Klyne provided assistance on the usage of RFC 2533. Thanks to Allison Mankin for her comments and support, and to Ted Hardie for his guidance on usage of the media feature tags.
本规范使用的媒体功能标签的初始集受Scott Petrack的CMA设计的影响。Jonathan Lennox、Bob Penfield、Ben Campbell、Mary Barnes、Rohan Mahy和John Hearty提供了有益的评论。Graham Klyne就RFC 2533的使用提供了帮助。感谢Allison Mankin的评论和支持，感谢Ted Hardie对媒体功能标签使用的指导。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[3] Holtman，K.，Mutz，A.，和T.Hardie，“媒体功能标签注册程序”，BCP 31，RFC 2506，1999年3月。
[4] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[4] Klyne，G.“描述媒体功能集的语法”，RFC2533，1999年3月。
[5] Klyne, G., "Corrections to "A Syntax for Describing Media Feature Sets"", RFC 2738, December 1999.
[5] Klyne，G.“对描述媒体功能集的语法的更正”，RFC2738，1999年12月。
[6] Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, November 2000.
[6] Hoffman，P.，“字符集和语言媒体特征标签的注册”，RFC 2987，2000年11月。
[7] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000.
[7] Klyne，G.“媒体功能表达式中的MIME内容类型”，RFC 29132000年9月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[9] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[9] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[10] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[11] Rosenberg，J.，Schulzrinne，H.和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[12] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[12] Mahy，R.，“会话启动协议（SIP）的消息摘要和消息等待指示事件包”，RFC 3842，2004年8月。
[13] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, May 2003.
[13] Rosenberg，J.，“使用会话启动协议的会议框架”，正在进行的工作，2003年5月。
[14] Howes, T. and M. Smith, "LDAP: String Representation of Search Filters", Work in Progress, March 2003.
[14] Howes，T.和M.Smith，“LDAP：搜索过滤器的字符串表示”，正在进行的工作，2003年3月。
[15] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[15] Peterson，J.，“会话启动协议（SIP）中身份验证管理的增强”，正在进行的工作，2003年3月。
[16] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[16] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[17] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[17] Klyne，G.，“独立于协议的内容协商框架”，RFC 2703，1999年9月。
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[18] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
This section provides a brief overview of RFC 2533 and related specifications that form the content negotiation framework. This section does not represent normative behavior. In the event of any conflict between the tutorial material here and the normative text in RFC 2533, RFC 2533 takes precedence.
本节简要概述RFC2533和构成内容协商框架的相关规范。本节不代表规范行为。如果此处的教程材料与RFC 2533中的规范性文本存在任何冲突，以RFC 2533为准。
A critical concept in the framework is that of a feature set. A feature set is information about an entity (in our case, a UA), which describes a set of features it can handle. A feature set can be thought of as a region in N-dimensional space. Each dimension in this space is a different media feature, identified by a media feature tag. For example, one dimension (or axis) might represent languages, another might represent methods, and another, MIME types. A feature collection represents a single point in this space. It represents a particular rendering or instance of an entity (in our case, a UA). For example, a "rendering" of a UA would define an instantaneous mode of operation that it can support. One such rendering would be processing the INVITE method, which carried the application/sdp MIME type, sent to a UA for a user that is speaking English.
框架中的一个关键概念是功能集。特征集是关于实体（在我们的例子中是UA）的信息，它描述了它可以处理的一组特征。特征集可以看作是N维空间中的一个区域。此空间中的每个维度都是不同的媒体功能，由媒体功能标签标识。例如，一个维度（或轴）可能表示语言，另一个维度可能表示方法，另一个维度可能表示MIME类型。要素集合表示此空间中的单个点。它表示一个实体（在我们的例子中是UA）的特定呈现或实例。例如，UA的“呈现”将定义其可以支持的即时操作模式。其中一种呈现方式是处理INVITE方法，该方法带有application/sdpmime类型，为说英语的用户发送给UA。
A feature set can therefore be defined as a set of feature collections. In other words, a feature set is a region of N-dimensional feature-space, that region being defined by the set of points - feature collections - that make up the space. If a particular feature collection is in the space, it means that the rendering described by that feature collection is supported by the device with that feature set.
因此，可以将要素集定义为一组要素集合。换句话说，特征集是N维特征空间的一个区域，该区域由构成该空间的点集（特征集合）定义。如果空间中存在特定功能集合，则表示具有该功能集的设备支持该功能集合描述的渲染。
How does one represent a feature set? There are many ways to describe an N-dimensional space. One way is to identify mathematical functions which identify its contours. Clearly, that is too complex to be useful. The solution taken in RFC 2533 is to define the space with a feature set predicate. A feature predicate defines a relation over an N-dimensional space; its input is any point in that space (i.e., a feature collection), and is true for all points that are in the region thus defined.
如何表示功能集？有许多方法可以描述N维空间。一种方法是识别识别其轮廓的数学函数。显然，这太复杂了，没有用处。RFC2533中采用的解决方案是使用特征集谓词定义空间。特征谓词定义N维空间上的关系；它的输入是该空间中的任何点（即特征集合），并且适用于由此定义的区域中的所有点。
RFC 2533 describes a syntax for writing down these N-dimensional boolean functions, borrowed from LDAP [14]. It uses a prolog-style syntax which is fairly self-explanatory. This representation is called a feature set predicate. The base unit of the predicate is a filter, which is a boolean expression encased in round brackets. A filter can be complex, where it contains conjunctions and
RFC2533描述了一种用于写下这些N维布尔函数的语法，借用自LDAP[14]。它使用了一种prolog风格的语法，这种语法相当不言自明。这种表示称为特征集谓词。谓词的基本单位是过滤器，它是一个用圆括号括起来的布尔表达式。过滤器可能很复杂，其中包含连接词和
disjunctions of other filters, or it can be simple. A simple filter is one that expresses a comparison operation on a single media feature tag.
其他过滤器的析取，也可以是简单的。一个简单的过滤器是在单个媒体功能标签上表示比较操作的过滤器。
For example, consider the feature set predicate:
例如，考虑特征集谓词：
(& (foo=A)
(bar=B)
(| (baz=C) (& (baz=D) (bif=E))))
(& (foo=A)
(bar=B)
(| (baz=C) (& (baz=D) (bif=E))))
This defines a function over four media features - foo, bar, baz, and bif. Any point in feature space with foo equal to A, bar equal to B, and baz equal to either C or D, and bif equal to E, is in the feature set defined by this feature set predicate.
这定义了四种媒体功能的函数-foo、bar、baz和bif。特征空间中foo等于A、bar等于B、baz等于C或D、bif等于E的任何点都位于由该特征集谓词定义的特征集中。
Note that the predicate doesn't say anything about the number of dimensions in feature space. The predicate operates on a feature space of any number of dimensions, but only those dimensions labeled foo, bar, baz, and bif matter. The result is that values of other media features don't matter. The feature collection {foo=A,bar=B,baz=C,bop=F} is in the feature set described by the predicate, even though the media feature tag "bop" isn't mentioned. Feature set predicates are therefore inclusive by default. A feature collection is present unless the boolean predicate rules it out. This was a conscious design choice in RFC 2533.
请注意，谓词没有说明要素空间中维度的数量。谓词对任意数量的维度的特征空间进行操作，但只有标记为foo、bar、baz和bif的维度才起作用。结果是，其他媒体功能的价值并不重要。功能集合{foo=A，bar=B，baz=C，bop=F}位于谓词描述的功能集中，即使没有提到媒体功能标签“bop”。因此，默认情况下，功能集谓词是包含的。要素集合存在，除非布尔谓词排除它。这是RFC2533中有意识的设计选择。
RFC 2533 also talks about matching a preference with a capability set. This is accomplished by representing both with a feature set. A preference is a feature set - its a specification of a number of feature collections, any one of which would satisfy the requirements of the sender. A capability is also a feature set - its a specification of the feature collections that the recipient supports. There is a match when the spaces defined by both feature sets overlap. When there is overlap, there exists at least one feature collection that exists in both feature sets, and therefore a modality or rendering desired by the sender which is supported by the recipient.
RFC2533还讨论了将首选项与功能集相匹配的问题。这是通过用一个特征集来表示两者来实现的。首选项是一个功能集—它是一个多个功能集合的规范，其中任何一个都可以满足发送者的要求。功能也是一个功能集—它是收件人支持的功能集合的规范。当两个要素集定义的空间重叠时，存在匹配。当存在重叠时，两个特征集中至少存在一个特征集合，因此，发送方需要一个模态或呈现，接收方支持该模态或呈现。
This leads directly to the definition of a match. Two feature sets match if there exists at least one feature collection present in both feature sets.
这将直接导致匹配的定义。如果两个要素集中至少存在一个要素集合，则两个要素集匹配。
Computing a match for two general feature set predicates is not easy. Section 5 of RFC 2533 presents an algorithm for doing it by expanding an arbitrary expression into disjunctive normal form. However, the feature set predicates used by this specification are constrained. They are always in conjunctive normal form, with each term in the conjunction describing values for different media features. This
计算两个通用功能集谓词的匹配并不容易。RFC2533的第5节通过将任意表达式扩展为析取范式给出了一种算法。但是，此规范使用的功能集谓词受到约束。它们始终是合取范式，合取中的每个术语描述不同媒体功能的值。这
makes computation of a match easy. It is computed independently for each media feature, and then the feature sets overlap if media features specified in both sets overlap. Computing the overlap of a single media feature is very straightforward, and is a simple matter of computing whether two finite sets overlap.
使匹配的计算变得简单。它是为每个媒体特征单独计算的，如果两个特征集中指定的媒体特征重叠，则特征集重叠。计算单个媒体特征的重叠非常简单，只需计算两个有限集是否重叠即可。
Authors' Addresses
作者地址
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg dynamicsoft 600美国新泽西州帕西帕尼拉尼德斯广场07054
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
Henning Schulzrinne哥伦比亚大学M/S 0401 1214美国纽约州阿姆斯特丹大道10027号
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue BXB500 C2-2 Boxboro, MA 01719 US
Paul Kyzivat Cisco Systems 1414马萨诸塞大道BXB500 C2-2美国马萨诸塞州Boxboro 01719
EMail: pkyzivat@cisco.com
EMail: pkyzivat@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。