Network Working Group J. Rosenberg
Request for Comments: 4485 Cisco Systems
Category: Informational H. Schulzrinne
Columbia University
May 2006
Network Working Group J. Rosenberg
Request for Comments: 4485 Cisco Systems
Category: Informational H. Schulzrinne
Columbia University
May 2006
Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)
会话启动协议（SIP）扩展作者指南
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions.
会话发起协议（SIP）是一种灵活而简单的工具，用于在Internet上建立交互式通信会话。这种灵活性的一部分是易于扩展。为了促进对SIP的有效和可互操作的扩展，在开发SIP扩展时需要遵循一些准则。本文档为SIP扩展的作者概述了一组这样的指南。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Should I Define a SIP Extension? ................................3
3.1. SIP's Solution Space .......................................4
3.2. SIP Architectural Model ....................................5
4. Issues to Be Addressed ..........................................7
4.1. Backwards Compatibility ....................................7
4.2. Security ..................................................10
4.3. Terminology ...............................................10
4.4. Syntactic Issues ..........................................10
4.5. Semantics, Semantics, Semantics ...........................13
4.6. Examples Section ..........................................14
4.7. Overview Section ..........................................14
4.8. IANA Considerations Section ...............................14
4.9. Document-Naming Conventions ...............................16
4.10. Additional Considerations for New Methods ................16
4.11. Additional Considerations for New Header Fields
or Header Field ..........................................17
4.12. Additional Considerations for New Body Types .............18
5. Interactions with SIP Features .................................18
6. Security Considerations ........................................19
7. Acknowledgements ...............................................19
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Should I Define a SIP Extension? ................................3
3.1. SIP's Solution Space .......................................4
3.2. SIP Architectural Model ....................................5
4. Issues to Be Addressed ..........................................7
4.1. Backwards Compatibility ....................................7
4.2. Security ..................................................10
4.3. Terminology ...............................................10
4.4. Syntactic Issues ..........................................10
4.5. Semantics, Semantics, Semantics ...........................13
4.6. Examples Section ..........................................14
4.7. Overview Section ..........................................14
4.8. IANA Considerations Section ...............................14
4.9. Document-Naming Conventions ...............................16
4.10. Additional Considerations for New Methods ................16
4.11. Additional Considerations for New Header Fields
or Header Field ..........................................17
4.12. Additional Considerations for New Body Types .............18
5. Interactions with SIP Features .................................18
6. Security Considerations ........................................19
7. Acknowledgements ...............................................19
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
The Session Initiation Protocol (SIP) [2] is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended (with new methods, new header fields, new body types, and new parameters), and there have been countless proposals that have been made to do just that. An IETF process has been put into place that defines how extensions are to be made to the SIP protocol [10]. That process is designed to ensure that extensions are made that are appropriate for SIP (as opposed to being done in some other protocol), that these extensions fit within the model and framework provided by SIP and are consistent with its operation, and that these extensions solve problems generically rather than for a specific use case. However, [10] does not provide the technical guidelines needed to assist that process. This specification helps to meet that need.
会话发起协议（SIP）[2]是一个灵活但简单的工具，用于在Internet上建立交互式通信会话。这种灵活性的一部分是可以轻松地进行扩展（使用新方法、新标题字段、新正文类型和新参数），为此已经提出了无数建议。IETF过程已经到位，它定义了如何对SIP协议进行扩展[10]。该过程旨在确保进行适合SIP的扩展（而不是在其他协议中进行），确保这些扩展符合SIP提供的模型和框架，并且与SIP的操作一致，并且这些扩展解决一般性问题，而不是特定的用例。然而，[10]没有提供协助这一进程所需的技术指导方针。本规范有助于满足这一需求。
This specification first provides a set of guidelines to help decide whether a certain piece of functionality is appropriately done in SIP. Assuming the functionality is appropriate, it then points out
本规范首先提供了一组指导原则，以帮助确定某项功能是否在SIP中适当完成。假设该功能是适当的，那么它指出
issues that extensions should deal with from within their specification. Finally, it discusses common interactions with existing SIP features that often cause difficulties in extensions.
扩展应该在其规范中处理的问题。最后，本文讨论了与现有SIP特性的常见交互，这些交互通常会给扩展带来困难。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释，并指出符合性实施的要求级别。
The first question to be addressed when defining a SIP extension is whether a SIP extension is the best solution to the problem. SIP has been proposed as a solution for numerous problems, including mobility, configuration and management, QoS control, call control, caller preferences, device control, third-party call control, and MPLS path setup, to name a few. Clearly, not every problem can be solved by a SIP extension. More importantly, some problems that could be solved by a SIP extension probably shouldn't.
定义SIP扩展时要解决的第一个问题是SIP扩展是否是问题的最佳解决方案。SIP已经被提出作为许多问题的解决方案，包括移动性、配置和管理、QoS控制、呼叫控制、呼叫方偏好、设备控制、第三方呼叫控制和MPLS路径设置等。显然，并不是每个问题都可以通过SIP扩展解决。更重要的是，一些可以通过SIP扩展解决的问题可能不应该解决。
To assist engineers in determining whether a SIP extension is an appropriate solution to their problem, we present two broad criteria. First, the problem SHOULD fit into the general purview of SIP's solution space. Secondly, the solution MUST conform to the general SIP architectural model.
为了帮助工程师确定SIP扩展是否适合解决他们的问题，我们提出了两个广泛的标准。首先，这个问题应该适合SIP解决方案空间的一般范围。其次，解决方案必须符合通用SIP体系结构模型。
Although the first criteria might seem obvious, we have observed that numerous extensions to SIP have been proposed because some function is needed in a device that also speaks SIP. The argument is generally given that "I'd rather implement one protocol than many". As an example, user agents, like all other IP hosts, need some way to obtain their IP address. This is generally done through DHCP [11]. SIP's multicast registration mechanisms might supply an alternate way to obtain an IP address. This would eliminate the need for DHCP in clients. However, we do not believe such extensions are appropriate. We believe that protocols should be defined to provide specific, narrow functions, rather than be defined for all protocols needed between a pair of devices. The former approach to protocol design yields modular protocols with broad application. It also facilitates extensibility and growth; single protocols can be removed and changed without affecting the entire system. We observe that this approach to protocol engineering mirrors object-oriented software engineering.
虽然第一个标准似乎很明显，但我们已经注意到，由于也讲SIP的设备中需要一些功能，已经提出了许多SIP扩展。通常的观点是“我宁愿实现一个协议也不愿实现多个协议”。例如，与所有其他IP主机一样，用户代理需要某种方式来获取其IP地址。这通常是通过DHCP实现的[11]。SIP的多播注册机制可能提供另一种获取IP地址的方法。这将消除客户端对DHCP的需求。然而，我们认为这样的扩展是不合适的。我们认为，应该定义协议以提供特定的、狭窄的功能，而不是为一对设备之间需要的所有协议定义协议。前一种协议设计方法产生了具有广泛应用的模块化协议。它还促进了可扩展性和增长；可以删除和更改单个协议，而不会影响整个系统。我们观察到，这种协议工程方法反映了面向对象的软件工程。
Our second criteria, that the extension must conform to the general SIP architectural model, ensures that the protocol remains manageable and broadly applicable.
我们的第二个标准，即扩展必须符合通用SIP体系结构模型，确保协议保持可管理性和广泛适用性。
In order to evaluate the first criteria, it is necessary to define exactly what SIP's solution space is, and what it is not.
为了评估第一个标准，有必要准确地定义什么是SIP的解决方案空间，什么不是。
SIP is a protocol for initiating, modifying, and terminating interactive sessions. This process involves the discovery of users, (or, more generally, entities that can be communicated with, including services, such as voicemail or translation devices) wherever they may be located, so that a description of the session can be delivered to the user. It is assumed that these users or communications entities are mobile, and that their point of attachment to the network changes over time. The primary purpose of SIP is a rendezvous function, to allow a request initiator to deliver a message to a recipient wherever they may be. Such a rendezvous is needed to establish a session, but it can be used for other purposes related to communications, such as querying for capabilities or delivery of an instant message.
SIP是用于启动、修改和终止交互式会话的协议。该过程涉及用户（或更一般地，可与之通信的实体，包括诸如语音邮件或翻译设备之类的服务）的发现，无论用户位于何处，以便会话的描述可以传递给用户。假设这些用户或通信实体是移动的，并且它们与网络的连接点随时间而变化。SIP的主要用途是会合功能，允许请求发起人将消息传递到收件人所在的任何位置。建立会话需要这样一个集合点，但它可以用于与通信相关的其他目的，例如查询功能或即时消息的传递。
Much of SIP focuses on this discovery and rendezvous component. Its ability to fork, its registration capabilities, and its routing capabilities are all present for the singular purpose of finding the desired user wherever they may be. As such, features and capabilities such as personal mobility, automatic call distribution, and follow-me are well within the SIP solution space.
SIP的大部分内容都集中在这个发现和会合组件上。它的分叉能力、注册能力和路由能力都是为了在任何地方找到所需的用户。因此，诸如个人移动性、自动呼叫分配和follow me等特性和功能在SIP解决方案领域内都很好。
Session initiation also depends on the ability of the called party to have enough information about the session itself to make a decision on whether to join. That information includes data about the caller, the purpose for the invitation, and parameters of the session itself. For this reason, SIP includes this kind of information.
会话启动还取决于被叫方是否有足够的会话信息来决定是否加入。这些信息包括有关调用者的数据、邀请的目的以及会话本身的参数。因此，SIP包含此类信息。
Part of the process of session initiation is the communication of progress and the final results of establishment of the session. SIP provides this information as well.
会议启动过程的一部分是交流会议的进展和最终结果。SIP也提供了这些信息。
SIP itself is independent of the session, and the session description is delivered as an opaque body within SIP messages. Keeping SIP independent of the sessions it initiates and terminates is fundamental. As such, there are many functions that SIP explicitly does not provide. It is not a session management protocol or a conference control protocol. The particulars of the communications within the session are outside of SIP. This includes features such as media transport, voting and polling, virtual microphone passing, chairman election, floor control, and feedback on session quality.
SIP本身独立于会话，并且会话描述在SIP消息中作为不透明体传递。保持SIP独立于它发起和终止的会话是最基本的。因此，有许多SIP明确不提供的功能。它不是会话管理协议或会议控制协议。会话内的通信细节不在SIP范围内。这包括媒体传输、投票和投票、虚拟麦克风传递、主席选举、发言控制和会话质量反馈等功能。
SIP is not a resource reservation protocol for sessions. This is fundamentally because (1) SIP is independent of the underlying
SIP不是会话的资源保留协议。这基本上是因为（1）SIP独立于底层
session it establishes, and (2) the path of SIP messages is completely independent from the path that session packets may take. The path independence refers to paths within a provider's network and the set of providers itself. For example, it is perfectly reasonable for a SIP message to traverse a completely different set of autonomous systems than the audio in a session SIP establishes.
它建立会话，并且（2）SIP消息的路径完全独立于会话数据包可能采用的路径。路径独立性指的是提供者网络内的路径和提供者本身的集合。例如，SIP消息穿越与SIP会话中的音频完全不同的自治系统集是完全合理的。
SIP is not a general purpose transfer protocol. It is not meant to send large amounts of data unrelated to SIP's operation. It is not meant as a replacement for HTTP. This is not to say that carrying payloads in SIP messages is never a good thing; in many cases, the data is very much related to SIP's operation. In those cases, congestion-controlled transports end-to-end are critical.
SIP不是通用传输协议。它并不意味着发送与SIP操作无关的大量数据。它不是HTTP的替代品。这并不是说在SIP消息中携带有效负载从来都不是一件好事；在许多情况下，数据与SIP的操作密切相关。在这些情况下，端到端的拥塞控制传输至关重要。
SIP is not meant to be a general Remote Procedure Call (RPC) mechanism. None of its user discovery and registration capabilities are needed for RPC, and neither are most of its proxy functions.
SIP并不是一种通用的远程过程调用（RPC）机制。RPC不需要它的任何用户发现和注册功能，它的大多数代理功能也不需要。
SIP is not meant to be used as a strict Public Switched Telephone Network (PSTN) signaling replacement. It is not a superset of the Integrated Services Digital Network (ISDN) User Part (ISUP). Although it can support gatewaying of PSTN signaling and can provide many features present in the PSTN, the mere existence of a feature or capability in the PSTN is not a justification for its inclusion in SIP. Extensions needed to support telephony MUST meet the other criteria described here.
SIP并不打算用作严格的公共交换电话网（PSTN）信令替代。它不是综合业务数字网（ISDN）用户部分（ISUP）的超集。尽管它可以支持PSTN信令的网关化，并且可以提供PSTN中存在的许多功能，但是PSTN中仅仅存在一个功能或能力并不是将其包含在SIP中的理由。支持电话所需的扩展必须满足此处描述的其他标准。
SIP is a poor control protocol. It is not meant to be used for one entity to tell another to pick up or answer a phone, to send audio using a particular codec, or to provide a new value for a configuration parameter. Control protocols have different trust relationships from that assumed in SIP and are more centralized in architecture than SIP is, as SIP is a very distributed protocol.
SIP是一个糟糕的控制协议。它并不用于一个实体告诉另一个实体拿起或接听电话、使用特定编解码器发送音频或为配置参数提供新值。控制协议具有不同于SIP中假定的信任关系，并且在体系结构上比SIP更集中，因为SIP是一种非常分布式的协议。
There are many network layer services needed to make SIP function. These include quality of service, mobility, and security, among others. Rather than build these capabilities into SIP itself, they SHOULD be developed outside of SIP and then used by it. Specifically, any protocol mechanisms that are needed by SIP, but that are also needed by many other application layer protocols SHOULD NOT be addressed within SIP.
要实现SIP功能，需要许多网络层服务。其中包括服务质量、移动性和安全性等。与其将这些功能构建到SIP本身中，不如在SIP之外开发这些功能，然后由SIP使用。具体地说，SIP需要的任何协议机制，但许多其他应用层协议也需要这些机制，不应该在SIP中解决。
We describe here some of the primary architectural assumptions that underlie SIP. Extensions that violate these assumptions should be examined more carefully to determine their appropriateness for SIP.
我们在这里描述了构成SIP基础的一些主要架构假设。应该更仔细地检查违反这些假设的扩展，以确定它们是否适合SIP。
Session independence: SIP is independent of the session it establishes. This includes the type of session, be it audio, video, game, chat session, or virtual reality. SIP operation SHOULD NOT depend on some characteristic of the session. SIP is not specific to voice only. Any extensions to SIP MUST consider the application of SIP to a variety of different session types.
会话独立性：SIP独立于它所建立的会话。这包括会话类型，可以是音频、视频、游戏、聊天会话或虚拟现实。SIP操作不应依赖于会话的某些特征。SIP不仅仅针对语音。对SIP的任何扩展都必须考虑将SIP应用到各种不同的会话类型中。
SIP and Session path independence: We have already touched on this once, but it is worth noting again. The set of routers, networks, and/or autonomous systems traversed by SIP messages are unrelated to the set of routers, networks, and/or autonomous systems traversed by session packets. They may be the same in some cases, but it is fundamental to SIP's architecture that they need not be the same. Standards-track extensions MUST NOT be defined that work only when the signaling and session paths are coupled. Non-standard P-header extensions [10] are required for any extension that only works in such a case.
SIP和会话路径独立性：我们已经讨论过一次，但值得再次注意。由SIP消息遍历的路由器、网络和/或自治系统的集合与由会话分组遍历的路由器、网络和/或自治系统的集合无关。在某些情况下，它们可能是相同的，但SIP架构的基本要求是它们不必相同。不得定义仅在信令和会话路径耦合时工作的标准轨道扩展。只有在这种情况下才能工作的任何扩展都需要非标准P头扩展[10]。
Multi-provider and multi-hop: SIP assumes that its messages will traverse the Internet. That is, SIP works through multiple networks administered by different providers. It is also assumed that SIP messages traverse many hops (where each hop is a proxy). Extensions MUST NOT work only under the assumption of a single hop or specialized network topology. They SHOULD avoid the assumption of a single SIP provider (but see the use of P-Headers, per RFC 3427 [10]).
多提供者和多跳：SIP假定其消息将穿越Internet。也就是说，SIP通过由不同提供商管理的多个网络工作。还假设SIP消息穿过多个跃点（其中每个跃点都是代理）。扩展不能仅在单跳或专用网络拓扑的假设下工作。他们应该避免假设只有一个SIP提供程序（但请参见RFC 3427[10]中P头的使用）。
Transactional: SIP is a request/response protocol, possibly enhanced with intermediate responses. Many of the rules of operation in SIP are based on general processing of requests and responses. This includes the reliability mechanisms, routing mechanisms, and state maintenance rules. Extensions SHOULD NOT add messages that are not within the request-response model.
事务性：SIP是一种请求/响应协议，可能通过中间响应进行了增强。SIP中的许多请求和响应的处理规则都是基于SIP的一般操作。这包括可靠性机制、路由机制和状态维护规则。扩展不应添加不在请求-响应模型内的消息。
Proxies can ignore bodies: In order for proxies to scale well, they must be able to operate with minimal message processing. SIP has been engineered so that proxies can always ignore bodies. Extensions SHOULD NOT require proxies to examine bodies.
代理可以忽略实体：为了使代理能够很好地扩展，它们必须能够以最小的消息处理进行操作。SIP的设计使代理始终可以忽略实体。扩展不应要求代理检查实体。
Proxies don't need to understand the method: Processing of requests in proxies does not depend on the method, except for the well-known methods INVITE, ACK, and CANCEL. This allows for extensibility. Extensions MUST NOT define new methods that must be understood by proxies.
代理不需要了解该方法：代理中请求的处理不依赖于该方法，除了众所周知的方法INVITE、ACK和CANCEL。这允许扩展性。扩展不能定义必须被代理理解的新方法。
INVITE messages carry full state: An initial INVITE message for a session is nearly identical (the exception is the tag) to a re-INVITE message to modify some characteristic of the session. This full state property is fundamental to SIP and is critical for robustness of SIP systems. Extensions SHOULD NOT modify INVITE processing such that data spanning multiple INVITEs must be collected in order to perform some feature.
INVITE消息携带完全状态：会话的初始INVITE消息与重新邀请消息几乎相同（例外是标记），以修改会话的某些特征。这种全状态属性是SIP的基础，对SIP系统的健壮性至关重要。扩展不应修改INVITE处理，以便必须收集跨越多个INVITE的数据才能执行某些功能。
Generality over efficiency: Wherever possible, SIP has favored general-purpose components rather than narrow ones. If some capability is added to support one service but a slightly broader capability can support a larger variety of services (at the cost of complexity or message sizes), the broader capability SHOULD be preferred.
通用性高于效率：只要可能，SIP都倾向于通用组件，而不是狭义组件。如果添加了一些功能以支持一个服务，但稍宽一点的功能可以支持更多种类的服务（以复杂性或消息大小为代价），则应首选更宽的功能。
The Request URI is the primary key for forwarding: Forwarding logic at SIP servers depends primarily on the request URI (this is different from request routing in SIP, which uses the Route header fields to pass a request through intermediate proxies). It is fundamental to the operation of SIP that the request URI indicate a resource that, under normal operations, resolves to the desired recipient. Extensions SHOULD NOT modify the semantics of the request URI.
请求URI是转发的主键：SIP服务器上的转发逻辑主要取决于请求URI（这与SIP中的请求路由不同，后者使用路由头字段通过中间代理传递请求）。SIP操作的基础是，请求URI指示在正常操作下解析为所需收件人的资源。扩展不应该修改请求URI的语义。
Heterogeneity is the norm: SIP supports heterogeneous devices. It has built-in mechanisms for determining the set of overlapping protocol functionalities. Extensions SHOULD NOT be defined that only function if all devices support the extension.
异构性是标准：SIP支持异构设备。它具有确定重叠协议功能集的内置机制。扩展不应定义为仅在所有设备都支持扩展时才起作用。
Given an extension has met the litmus tests in the previous section, there are several issues that all extensions should take into consideration.
假设一个扩展满足上一节中的石蕊测试，那么所有扩展都应该考虑几个问题。
One of the most important issues to consider is whether the new extension is backward compatible with baseline SIP. This is tightly coupled with how the Require, Proxy-Require, and Supported header fields are used.
要考虑的最重要的问题之一是新的扩展是否与基线SIP向后兼容。这与Require、Proxy Require和Supported头字段的使用方式密切相关。
If an extension consists of new header fields or header field parameters inserted by a user agent in a request with an existing method, and the request cannot be processed reasonably by a proxy and/or user agent without understanding the header fields or parameters, the extension MUST mandate the usage of the Require and/or Proxy-Require header fields in the request. These extensions
如果扩展由用户代理在使用现有方法的请求中插入的新标题字段或标题字段参数组成，并且在不了解标题字段或参数的情况下，代理和/或用户代理无法合理处理该请求，扩展必须强制使用请求中的Require和/或Proxy Require头字段。这些扩展
are not backwards compatible with SIP. The result of mandating usage of these header fields means that requests cannot be serviced unless the entities being communicated with also understand the extension. If some entity does not understand the extension, the request will be rejected. The UAC can then handle this in one of two ways. In the first, the request simply fails, and the service cannot be provided. This is basically an interoperability failure. In the second case, the UAC retries the request without the extension. This will preserve interoperability, at the cost of a "dual stack" implementation in a UAC (processing rules for operation with and without the extension). As the number of extensions increases, this leads to an exponential explosion in the sets of processing rules a UAC may need to implement. The result is excessive complexity.
与SIP不向后兼容。强制使用这些头字段的结果意味着，除非与之通信的实体也理解扩展，否则无法为请求提供服务。如果某个实体不理解扩展，则该请求将被拒绝。UAC可以通过以下两种方式之一处理此问题。在第一种情况下，请求失败，无法提供服务。这基本上是互操作性失败。在第二种情况下，UAC重试请求，而不使用扩展名。这将保持互操作性，代价是UAC中的“双堆栈”实现（有扩展和没有扩展的操作处理规则）。随着扩展数量的增加，这将导致UAC可能需要实现的处理规则集呈指数级增长。其结果是过于复杂。
Because of the possibility of interoperability and complexity problems that result from the usage of Require and Proxy-Require, we believe the following guidelines are appropriate:
由于使用Require和Proxy Require可能导致互操作性和复杂性问题，我们认为以下准则是合适的：
o The usage of these header fields in requests for basic SIP services (in particular, session initiation and termination) is NOT RECOMMENDED. The less frequently a particular extension is needed in a request, the more reasonable it is to use these header fields.
o 不建议在请求基本SIP服务（特别是会话启动和终止）时使用这些头字段。请求中需要特定扩展的频率越低，使用这些头字段就越合理。
o The Proxy-Require header field SHOULD be avoided at all costs. The failure likelihood in an individual proxy stays constant, but the path failure grows exponentially with the number of hops. On the other hand, the Require header field only mandates that a single entity, the UAS, support the extension. Usage of Proxy-Require is thus considered exponentially worse than usage of the Require header field.
o 应不惜一切代价避免使用Proxy Require标头字段。单个代理中的故障可能性保持不变，但路径故障随跳数呈指数增长。另一方面，Require header字段仅要求单个实体（UAS）支持扩展。因此，代理Require的使用被认为比Require头字段的使用更糟糕。
o If either Require or Proxy-Require are used by an extension, the extension SHOULD discuss how to fall back to baseline SIP operation if the request is rejected with a 420 response.
o 如果扩展使用Require或Proxy Require，那么扩展应该讨论如果请求被420响应拒绝，如何退回到基线SIP操作。
Extensions that define new methods do not need to use the Require header field. SIP defines mechanisms that allow a UAC to know whether a new method is understood by a UAS. This includes both the OPTIONS request and the 405 (Method Not Allowed) response with the Allow header field. It is fundamental to SIP that proxies need not understand the semantics of a new method in order to process it. If an extension defines a new method that must be understood by proxies in order to be processed, a Proxy-Require header field is needed. As discussed above, these kinds of extensions are frowned upon.
定义新方法的扩展不需要使用Require header字段。SIP定义了允许UAC知道UAS是否理解新方法的机制。这包括选项请求和405（方法不允许）响应以及允许标头字段。代理不需要理解新方法的语义就可以处理它，这对于SIP来说是至关重要的。如果扩展定义了代理必须理解的新方法才能进行处理，则需要一个Proxy Require头字段。如上所述，这些类型的扩展是不受欢迎的。
In order to achieve backwards compatibility for extensions that define new methods, the Allow header field is used. There are two
为了实现定义新方法的扩展的向后兼容性，使用了Allow header字段。有两个
types of new methods - those that are used for established dialogs (initiated by INVITE, for example), and those that are sent as the initial request to a UA. Since INVITE and its response both SHOULD contain an Allow header field, a UA can readily determine whether the new method can be supported within the dialog. For example, once an INVITE dialog is established, a user agent could determine whether the REFER method [12] is supported if it is present in an Allow header field. If it wasn't, the "transfer" button on the UI could be "greyed out" once the call is established.
新方法的类型-用于已建立对话（例如，由INVITE发起）的方法，以及作为初始请求发送给UA的方法。由于INVITE及其响应都应该包含一个Allow header字段，UA可以很容易地确定对话框中是否支持新方法。例如，一旦建立了INVITE对话框，用户代理就可以确定如果REFERE方法[12]存在于Allow header字段中，则该方法是否受支持。如果不是，一旦建立呼叫，UI上的“转接”按钮可能会“变灰”。
Another type of extension is that which requires a proxy to insert header fields or header field parameters into a request as it traverses the network, or for the UAS to insert header fields or header field parameters into a response. For some extensions, if the UAC or UAS does not understand these header fields, the message can still be processed correctly. These extensions are completely backwards compatible.
另一种类型的扩展需要代理在请求穿越网络时将头字段或头字段参数插入到请求中，或者UAS将头字段或头字段参数插入到响应中。对于某些扩展，如果UAC或UAS不理解这些头字段，则仍然可以正确处理消息。这些扩展是完全向后兼容的。
Most other extensions of this type require that the server only insert the header field or parameter if it is sure the client understands it. In this case, these extensions will need to make use of the Supported request header field mechanism. This mechanism allows a server to determine if the client can understand some extension, so that it can apply the extension to the response. By their nature, these extensions may not always be able to be applied to every response.
这种类型的大多数其他扩展都要求服务器仅在确保客户端理解的情况下插入头字段或参数。在这种情况下，这些扩展需要使用受支持的请求头字段机制。此机制允许服务器确定客户机是否能够理解某些扩展，以便将扩展应用于响应。就其性质而言，这些扩展可能并不总是能够应用于每个响应。
If an extension requires a proxy to insert a header field or parameter into a request and this header field or parameter needs to be understood by both UAC and UAS to be executed correctly, a combination of the Require and the Supported mechanism will need to be used. The proxy can insert a Require header field into the request if the Supported header field is present. An example of such an extension is the SIP Session Timer [13].
如果扩展需要代理将头字段或参数插入到请求中，并且UAC和UAS都需要理解此头字段或参数才能正确执行，则需要使用Require和受支持机制的组合。如果存在受支持的标头字段，则代理可以在请求中插入Require标头字段。这种扩展的一个例子是SIP会话计时器[13]。
Yet another type of extension is that which defines new body types to be carried in SIP messages. According to the SIP specification, bodies must be understood by user agents in order to process a request. As such, the interoperability issues are similar to new methods. However, the Content-Disposition header field has been defined to allow a client or server to indicate that the message body is optional [2]. Extensions that define or require new body types SHOULD make them optional for the user agent to process.
另一种扩展类型是定义SIP消息中要携带的新主体类型的扩展。根据SIP规范，用户代理必须理解主体才能处理请求。因此，互操作性问题类似于新方法。但是，Content Disposition header字段已定义为允许客户端或服务器指示消息正文是可选的[2]。定义或需要新主体类型的扩展应该使它们成为可选的，以便用户代理处理。
When a body must be understood to properly process a request or response, it is preferred that the sending entity know ahead of time whether the new body is understood by the recipient. For requests that establish a dialog, inclusion of Accept in the request and its
当必须理解一个主体以正确处理请求或响应时，发送实体最好提前知道接收方是否理解新主体。对于建立对话框的请求，在请求中包含Accept及其
success responses is RECOMMENDED. This will allow both parties to determine what body types are supported by their peers. Subsequent messaging between the peers would then only include body types that were indicated as being understood.
建议使用成功响应。这将允许双方确定其同伴支持的体型。随后，对等方之间的消息传递将只包括表示为被理解的身体类型。
Security is an important component of any protocol. Designers of SIP extensions need to carefully consider if additional security requirements are required over those described in RFC 3261. Frequently, authorization requirements and requirements for end-to-end integrity are the most overlooked.
安全性是任何协议的重要组成部分。SIP扩展的设计者需要仔细考虑是否需要在RFC 3261中描述的那些额外的安全性要求。通常，授权需求和端到端完整性需求是最容易被忽视的。
SIP extensions MUST consider how (or if) they affect usage of the general SIP security mechanisms. Most extensions should not require any new security capabilities beyond general-purpose SIP. If they do, it is likely that the security mechanism has more general-purpose application and should be considered an extension in its own right.
SIP扩展必须考虑它们如何（或如果）影响通用SIP安全机制的使用。除了通用SIP之外，大多数扩展都不需要任何新的安全功能。如果他们这样做了，那么安全机制很可能具有更广泛的用途，应该被视为其本身的一种扩展。
Overall system security requires that both the SIP signaling and the media sessions it established be secured. The media sessions normally use their own security techniques, which are quite distinct from those used by SIP itself. Extensions should take care not to conflate the two. However, specifications that define extensions that impact the media sessions in any way SHOULD consider the interactions between SIP and session security mechanisms.
总体系统安全性要求SIP信令和它建立的媒体会话都是安全的。媒体会话通常使用自己的安全技术，这与SIP本身使用的安全技术截然不同。扩展应该注意不要将两者混为一谈。然而，定义以任何方式影响媒体会话的扩展的规范应该考虑SIP和会话安全机制之间的相互作用。
RFC 3261 has an extensive terminology section that defines terms such as caller, callee, user agent, and header field. All SIP extensions MUST conform to this terminology. They MUST NOT define new terms that describe concepts already defined by a term in another SIP specification. If new terminology is needed, it SHOULD appear in a separate section towards the beginning of the document.
RFC3261有一个广泛的术语部分，它定义了诸如调用者、被调用者、用户代理和头字段等术语。所有SIP扩展必须符合此术语。他们不能定义新的术语来描述另一个SIP规范中的术语已经定义的概念。如果需要新的术语，应在文件开头的单独一节中列出。
Careful attention must be paid to the actual usage of terminology. Many documents misuse the terms header, header field, and header field values, for example. Document authors SHOULD do a careful review of their documents for proper usage of these terms.
必须仔细注意术语的实际使用。例如，许多文档滥用术语header、header字段和header字段值。文档作者应仔细审查其文档，以正确使用这些术语。
Extensions that define new methods SHOULD use all capitals for the method name. Method names SHOULD be shorter than 10 characters and SHOULD attempt to convey the general meaning of the request. Method names are case sensitive, and therefore, strictly speaking, they don't have to be capitalized. However, using capitalized method
定义新方法的扩展应该使用方法名称的所有大写字母。方法名称应少于10个字符，并应尝试传达请求的一般含义。方法名称区分大小写，因此严格来说，它们不必大写。然而，使用资本化方法
names keeps with a long-standing convention in SIP and many similar protocols, such as HTTP [15] and RTSP [16].
名称与SIP和许多类似协议（如HTTP[15]和RTSP[16]）中的长期约定保持一致。
Extensions that define new header fields that are anticipated to be heavily used MAY define a compact form if those header fields are more than six characters. "Heavily used" means that the percentage of all emitted messages that contain that header field is over thirty percent. Usage of compact forms in these cases is only a MAY because there are better approaches for reducing message overhead [20]. Compact header fields MUST be a single character. When all 26 characters are exhausted, new compact forms will no longer be defined. Header field names are defined by the "token" production in RFC 3261, Section 25.1, and thus include the upper and lowercase letters, the digits 0 through 9, the HYPHEN-MINUS (-), FULL STOP (.), EXCLAMATION MARK (!), PERCENT SIGN (%), ASTERISK (*), LOW LINE (_), PLUS SIGN (+), GRAVE ACCENT (`), APOSTROPHE ('), and TILDE (~). They SHOULD be descriptive but reasonably brief. Although header field names are case insensitive, a single common capitalization SHOULD be used throughout the document. It is RECOMMENDED that each English word present in the header field name have its first letter capitalized. For example, "ThisIsANewHeader".
如果这些标题字段超过六个字符，那么定义预计将大量使用的新标题字段的扩展可能会定义一个紧凑的表单。“大量使用”表示包含该标头字段的所有已发出消息的百分比超过30%。在这些情况下使用紧凑表单只是一种可能，因为有更好的方法来减少消息开销[20]。压缩头字段必须是单个字符。当全部26个字符用完时，将不再定义新的紧凑形式。标题字段名由RFC 3261第25.1节中的“token”生成项定义，因此包括大小写字母、数字0到9、连字符（-）、句号（）、感叹号（！）、百分号（%）、星号（*）、下线（u）、加号（+）、重重音（`）、撇号（'）和波浪号（~）。它们应该是描述性的，但相当简短。尽管标题字段名称不区分大小写，但在整个文档中应使用单个通用大小写。建议标题字段名称中的每个英文单词的首字母大写。例如，“ThisIsANewHeader”。
As an example, the following are poor choices for header field names:
例如，以下是标题字段名称的糟糕选择：
ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName --.!A Function
这是一个新的标题，它不包含任何内容，但它的名称是--。！函数
Case sensitivity of parameters and values is a constant source of confusion, a difficulty that plagued RFC 2543 [17]. This has been simplified through the usage of the BNF constructs of RFC 4234 [5], which have clear rules of case sensitivity and insensitivity. Therefore, the BNF for an extension completely defines the matching rules.
参数和值的大小写敏感度一直是混淆的根源，这是困扰RFC 2543的一个难题[17]。通过使用RFC 4234[5]的BNF结构，这一点得到了简化，它具有明确的区分大小写和不区分大小写的规则。因此，扩展的BNF完全定义了匹配规则。
Extensions MUST be consistent with the SIP conventions for case sensitivity. Methods MUST be case sensitive. Header field names MUST be case insensitive. Header field parameter names MUST be case insensitive. Header field values and parameter values are sometimes case sensitive, and sometimes case insensitive. However, generally, they SHOULD be case insensitive. Defining a case-sensitive component requires explicitly listing each character through its ASCII code.
扩展必须与SIP约定保持一致，以区分大小写。方法必须区分大小写。标题字段名称必须不区分大小写。标头字段参数名称必须不区分大小写。标题字段值和参数值有时区分大小写，有时不区分大小写。但是，一般来说，它们应该不区分大小写。定义区分大小写的组件需要通过其ASCII代码显式列出每个字符。
Extensions that contain freeform text MUST allow that text to be UTF-8, as per the IETF policies on character set usage [3]. This ensures that SIP remains an internationalized standard. As a general guideline, freeform text is never needed by programs to perform protocol processing. It is usually entered by and displayed to the
根据IETF关于字符集使用的政策[3]，包含自由格式文本的扩展必须允许该文本为UTF-8。这确保了SIP仍然是一个国际化的标准。一般来说，程序执行协议处理时不需要自由格式的文本。它通常由输入并显示给
user. If an extension uses a parameter that can contain UTF-8- encoded characters, and that extension requires a comparison to be made of this parameter to other parameters, the comparison MUST be case sensitive. Case-insensitive comparison rules for UTF-8 text are, at this time, impossible and MUST be avoided.
使用者如果扩展名使用的参数可以包含UTF-8编码的字符，并且该扩展名需要将此参数与其他参数进行比较，则比较必须区分大小写。目前，UTF-8文本的不区分大小写的比较规则是不可能的，必须避免。
Extensions that make use of dates MUST use the SIP-Date BNF defined in RFC 3261. No other date formats are allowed. However, the usage of absolute dates to determine intervals (for example, the time at which some timer fires) is NOT RECOMMENDED. This is because it requires synchronized time between peers, and this is frequently not the case. Therefore, relative times, expressed in numbers of seconds, SHOULD be used.
使用日期的扩展必须使用RFC 3261中定义的SIP日期BNF。不允许使用其他日期格式。但是，不建议使用绝对日期来确定时间间隔（例如，某些计时器触发的时间）。这是因为它需要对等点之间的同步时间，但通常情况并非如此。因此，应使用以秒为单位的相对时间。
Extensions that include network-layer addresses SHOULD permit dotted quad IPv4 addresses, IPv6 addresses in the format described in [4], and domain names.
包含网络层地址的扩展应允许IPv4地址、采用[4]中所述格式的IPv6地址和域名。
Extensions that have header fields containing URIs SHOULD be explicit about which URI schemes can be used in that header field. Header fields SHOULD allow the broadest set of URI schemes possible that are a match for the semantics of the header field.
具有包含URI的头字段的扩展应该明确说明在该头字段中可以使用哪些URI方案。标头字段应允许尽可能广泛的URI方案集，这些URI方案与标头字段的语义相匹配。
Header fields MUST follow the standard formatting for SIP, defined as follows:
标题字段必须遵循SIP的标准格式，定义如下：
header = header-name HCOLON header-value
*(COMMA header-value)
header-name = token
header-value = value *(SEMI value-parameter)
value-parameter = token [EQUAL gen-value]
gen-value = token / host / quoted-string
value = token / host / quoted-string
header = header-name HCOLON header-value
*(COMMA header-value)
header-name = token
header-value = value *(SEMI value-parameter)
value-parameter = token [EQUAL gen-value]
gen-value = token / host / quoted-string
value = token / host / quoted-string
In some cases, this form is not sufficient. That is the case for header fields that express descriptive text meant for human consumption. An example is the Subject header field in SIP [2]. In this case, an alternate form is:
在某些情况下，这种形式是不够的。这就是标题字段的情况，这些字段表示用于人类消费的描述性文本。SIP[2]中的主题标题字段就是一个例子。在这种情况下，另一种形式是：
header = header-name HCOLON [TEXT-UTF8-TRIM]
header=标题名HCOLON[TEXT-UTF8-TRIM]
Developers of extensions SHOULD allow for extension parameters in their header fields.
扩展的开发人员应该在他们的头字段中允许扩展参数。
Header fields that contain a list of URIs SHOULD follow the same syntax as the Contact header field in SIP. Implementors are also encouraged to wrap these URI in angle brackets, "<" and ">", at all times. We have found this to be a frequently misimplemented feature.
包含URI列表的头字段应遵循与SIP中联系人头字段相同的语法。还鼓励实现者始终将这些URI用尖括号括起来，“<”和“>”。我们发现这是一个经常错误实现的特性。
Beyond the compact form, there is no need to define compressed versions of header field values. Compression of SIP messages SHOULD be handled at lower layers, for example, using IP payload compression [18] or signalling compression [20].
除了压缩表单之外，不需要定义头字段值的压缩版本。SIP消息的压缩应在较低层处理，例如，使用IP有效负载压缩[18]或信令压缩[20]。
Syntax for header fields is expressed in Augmented Backus-Naur Form and MUST follow the format of RFC 4234 [5]. Extensions MUST make use of the primitive components defined in RFC 3261 [2]. If the construction for a BNF element is defined in another specification, it is RECOMMENDED that the construction be referenced rather than copied. The reference SHOULD include both the document and section number. All BNF elements must be either defined or referenced.
标题字段的语法以增广的Backus Naur形式表示，必须遵循RFC 4234[5]的格式。扩展必须使用RFC 3261[2]中定义的基本组件。如果BNF元件的结构在其他规范中定义，建议参考该结构，而不是复制该结构。参考文件应包括文件和章节号。必须定义或引用所有BNF元素。
It is RECOMMENDED that BNF be collected into a single section near the end of the document.
建议将BNF收集到文件末尾附近的单个章节中。
All tokens and quoted strings are separated by explicit linear white space. Linear white space, for better or worse, allows for line folding. Extensions MUST NOT define new header fields that use alternate linear white space rules.
所有标记和带引号的字符串由显式线性空格分隔。线性空白，无论好坏，都允许折线。扩展不能定义使用备用线性空白规则的新标题字段。
All SIP extensions MUST verify that any BNF productions that they define in their grammar do not conflict with any existing grammar defined in other SIP standards-track specifications.
所有SIP扩展必须验证它们在语法中定义的任何BNF产品是否与其他SIP标准规范中定义的任何现有语法冲突。
Developers of protocols often get caught up in syntax issues, without spending enough time on semantics. The semantics of a protocol are far more important. SIP extensions MUST clearly define the semantics of the extensions. Specifically, the extension MUST specify the behaviors expected of a UAC, UAS, and proxy in processing the extension. This is often best described by having separate sections for each of these three elements. Each section SHOULD step through the processing rules in temporal order of the most common messaging scenario.
协议的开发人员经常陷入语法问题，而没有在语义上花费足够的时间。协议的语义要重要得多。SIP扩展必须明确定义扩展的语义。具体来说，扩展必须指定UAC、UAS和代理在处理扩展时的预期行为。这通常最好通过为这三个元素中的每一个单独的部分来描述。每个部分都应该按照最常见的消息传递场景的时间顺序逐步完成处理规则。
Processing rules generally specify actions to be taken (in terms of messages to be sent, variables to be stored, and rules to be followed) on receipt of messages and expiration of timers. If an action requires transmission of a message, the rule SHOULD outline requirements for insertion of header fields or other information in the message.
处理规则通常指定在收到消息和计时器过期时要采取的操作（根据要发送的消息、要存储的变量和要遵循的规则）。如果操作需要传输消息，则规则应概述在消息中插入标题字段或其他信息的要求。
The extension SHOULD specify procedures to be taken in exceptional conditions that are recoverable, or that require some kind of user intervention. Handling of unrecoverable errors does not require specification.
扩展应该指定在可恢复的或需要某种用户干预的异常情况下采取的程序。不可恢复错误的处理不需要规范。
The specification SHOULD contain a section that gives examples of call flows and message formatting. Extensions that define substantial new syntax SHOULD include examples of messages containing that syntax. Examples of message flows should be given to cover common cases and at least one failure or unusual case.
规范应包含一节，给出调用流和消息格式的示例。定义大量新语法的扩展应该包括包含该语法的消息示例。应给出消息流示例，以涵盖常见情况和至少一种故障或异常情况。
For an example of how to construct a good examples section, see the message flows and message formatting defined in the Basic Call Flows specification [21]. Note that complete messages SHOULD be used. Be careful to include tags, Via header fields (with the branch ID cookie), Max-Forwards, Content-Lengths, Record-Route, and Route header fields. Example INVITE messages MAY omit session descriptions, and Content-Length values MAY be set to "..." to indicate that the value is not provided. However, the specification MUST explicitly call out the meaning of the "..." and explicitly indicate that session descriptions were not included.
有关如何构造好的示例部分的示例，请参阅基本调用流规范[21]中定义的消息流和消息格式。请注意，应使用完整的消息。小心地包括标签、Via头字段（带有分支ID cookie）、最大转发、内容长度、记录路由和路由头字段。示例INVITE消息可以省略会话描述，并且内容长度值可以设置为“…”以指示未提供该值。然而，规范必须明确指出“…”的含义，并明确指出未包括会话描述。
Too often, extension documents dive into detailed syntax and semantics without giving a general overview of operation. This makes understanding of the extension harder. It is RECOMMENDED that extensions have a protocol overview section that discusses the basic operation of the extension. Basic operation usually consists of the message flow, in temporal order, for the most common case covered by the extension. The most important processing rules for the elements in the call flow SHOULD be mentioned. Usage of the RFC 2119 [1] terminology in the overview section is NOT RECOMMENDED, and the specification should explicitly state that the overview is tutorial in nature only. This section SHOULD expand all acronyms, even those common in SIP systems, and SHOULD be understandable to readers who are not SIP experts. [27] provides additional guidance on writing good overview sections.
扩展文档常常深入研究详细的语法和语义，而没有给出操作的一般概述。这使得理解扩展变得更加困难。建议扩展有一个协议概述部分，讨论扩展的基本操作。对于扩展所涵盖的最常见的情况，基本操作通常包括按时间顺序排列的消息流。应该提到调用流中元素最重要的处理规则。不建议在概述部分使用RFC 2119[1]术语，规范应明确说明概述仅为教程性质。本节应扩展所有首字母缩略词，即使是SIP系统中常见的首字母缩略词，并应为非SIP专家的读者所理解。[27]提供了编写良好概述章节的额外指导。
Documents that define new SIP extensions will invariably have IANA Considerations sections.
定义新SIP扩展的文档总是包含IANA注意事项部分。
If your extension is defining a new event package, you MUST register that package. RFC 3265 [6] provides the registration template. See
如果扩展正在定义新的事件包，则必须注册该包。RFC 3265[6]提供了注册模板。看见
[22] for an example of the registration of a new event package. As discussed in RFC 3427 [10], only standards-track documents can register new event-template packages. Both standards-track and informational specifications can register event packages.
[22] 有关注册新事件包的示例，请参见。如RFC 3427[10]所述，只有标准跟踪文档才能注册新的事件模板包。标准跟踪规范和信息规范都可以注册事件包。
If your extension is defining a new header field, you MUST register that header field. RFC 3261 [2] provides a registration template. See Section 8.2 of RFC 3262 [23] for an example of how to register new SIP header fields. Both standards-track and informational P-header specifications can register new header fields [10].
如果您的扩展正在定义新的标题字段，则必须注册该标题字段。RFC 3261[2]提供了一个注册模板。有关如何注册新SIP头字段的示例，请参见RFC 3262[23]第8.2节。标准跟踪和信息性P头规范都可以注册新的头字段[10]。
If your extension is defining a new response code, you MUST register that response code. RFC 3261 [2] provides a registration template. See Section 6.4 of RFC 3329 [19] for an example of how to register a new response code. As discussed in RFC 3427 [10], only standards-track documents can register new response codes.
如果扩展正在定义新的响应代码，则必须注册该响应代码。RFC 3261[2]提供了一个注册模板。有关如何注册新响应代码的示例，请参见RFC 3329[19]第6.4节。如RFC 3427[10]所述，只有标准跟踪文档才能注册新的响应代码。
If your extension is defining a new SIP method, you MUST register that method. RFC 3261 [2] provides a registration template. See Section 10 of RFC 3311 [24] for an example of how to register a new SIP method. As discussed in RFC 3427 [10], only standards-track documents can register new methods.
如果扩展正在定义新的SIP方法，则必须注册该方法。RFC 3261[2]提供了一个注册模板。有关如何注册新SIP方法的示例，请参见RFC 3311[24]第10节。如RFC 3427[10]所述，只有标准跟踪文档才能注册新方法。
If your extension is defining a new SIP header field parameter, you MUST register that header field parameter per the guidelines in RFC 3968 [7]. Section 4.1 of that specification provides a template. Only IETF approved specifications can register new header field parameters. However, there is no requirement that these be standards track.
如果扩展正在定义新的SIP头字段参数，则必须按照RFC 3968[7]中的指南注册该头字段参数。该规范第4.1节提供了一个模板。只有IETF批准的规范才能注册新的标题字段参数。但是，没有要求这些标准必须是跟踪的。
If your extension is defining a new SIP URI parameter, you MUST register that URI parameter per the guidelines in RFC 3969 [8]. Section 4.1 of that specification provides a template. Only standards-track documents can register new URI parameters.
如果扩展正在定义新的SIP URI参数，则必须按照RFC 3969[8]中的指导原则注册该URI参数。该规范第4.1节提供了一个模板。只有标准跟踪文档才能注册新的URI参数。
Many SIP extensions make use of option tags, carried in the Require, Proxy-Require, and Supported header fields. Section 4.1 discusses some of the issues involved in the usage of these header fields. If your extension does require them, you MUST register an option tag for your extension. RFC 3261 [2] provides a registration template. See Section 8.1 of RFC 3262 [23] for an example of how to register an option tag. Only standards-track RFCs can register new option tags.
许多SIP扩展都使用选项标记，这些标记包含在Require、Proxy Require和Supported头字段中。第4.1节讨论了使用这些标题字段所涉及的一些问题。如果扩展确实需要它们，则必须为扩展注册选项标记。RFC 3261[2]提供了一个注册模板。有关如何注册选项标签的示例，请参见RFC 3262[23]第8.1节。只有标准轨道RFC可以注册新的选项标记。
Some SIP extensions will require establishment of their own IANA registries. RFC 2434 [25] provides guidance on how and when IANA registries are established. For an example of how to set one up, see Section 6 of RFC 3265 [6] for an example.
一些SIP扩展将需要建立自己的IANA注册中心。RFC 2434[25]提供了关于如何以及何时建立IANA注册的指南。有关如何设置的示例，请参见RFC 3265[6]第6节中的示例。
An important decision to be made about the extension is its title. The title MUST indicate that the document is an extension to SIP. It is RECOMMENDED that the title follow the basic form of "A [summary of function] for the Session Initiation Protocol (SIP)", where the summary of function is a one- to three-word description of the extension. For example, if an extension defines a new header field, called Make-Coffee, for making coffee, the title would read, "Making Coffee with the Session Initiation Protocol (SIP)". It is RECOMMENDED that these additional words be descriptive rather than naming the header field. For example, the extension for making coffee should not be named "The Make-Coffee Header for the Session Initiation Protocol".
关于延期的一个重要决定是它的名称。标题必须表明该文档是SIP的扩展。建议标题遵循“会话启动协议（SIP）的[功能摘要]的基本形式”，其中功能摘要是对扩展的一到三个字的描述。例如，如果扩展定义了一个新的标题字段，称为Make Coffee，用于制作咖啡，标题将为“使用会话启动协议（SIP）制作咖啡”。建议这些额外的单词是描述性的，而不是命名标题字段。例如，煮咖啡的扩展不应命名为“会话启动协议的煮咖啡头”。
For extensions that define new methods, an acceptable template for titles is "The Session Initiation Protocol (SIP) X Method" where X is the name of the method.
对于定义新方法的扩展，可接受的标题模板是“会话初始化协议（SIP）X方法”，其中X是方法的名称。
Note that the acronym SIP MUST be expanded in the titles of RFCs, as per [26].
请注意，根据[26]，首字母缩略词SIP必须在RFC标题中扩展。
Extensions that define new methods SHOULD take into consideration and discuss the following issues:
定义新方法的扩展应考虑并讨论以下问题：
o Can it contain bodies? If so, what is the meaning of the presence of those bodies? What body types are allowed?
o 它能容纳尸体吗？如果是，这些机构的存在意味着什么？允许哪些体型？
o Can a transaction with this request method occur while another transaction, in the same and/or reverse direction, is in progress?
o 使用此请求方法的事务是否可以在另一个相同和/或相反方向的事务正在进行时发生？
o The extension MUST define which header fields can be present in requests of that method. It is RECOMMENDED that this information be represented as a new column of Table 2/3 of RFC 3261 [2]. The table MUST contain rows for all header fields defined in standards-track RFCs at the time of writing of the extension.
o 扩展必须定义该方法的请求中可以存在哪些标头字段。建议将该信息表示为RFC 3261[2]表2/3中的新列。该表必须包含在编写扩展时在标准跟踪RFC中定义的所有标题字段的行。
o Can the request be sent within a dialog, or does it establish a dialog?
o 请求可以在对话框中发送，还是建立对话框？
o Is it a target refresh request?
o 它是目标刷新请求吗？
o Extensions to SIP that define new methods MAY specify whether offers and answers can appear in requests of that method or its responses. However, those extensions MUST adhere to the protocol
o 定义新方法的SIP扩展可以指定提供和应答是否可以出现在该方法的请求或其响应中。但是，这些扩展必须遵守协议
rules specified in [28] and MUST adhere to the additional constraints for offers and answers as specified in SIP [2].
[28]中规定的规则，并且必须遵守SIP[2]中规定的报价和应答的附加约束。
o Because of the nature of reliability treatment of requests with new methods, those requests need to be answered immediately by the UAS. Protocol extensions that require longer durations for the generation of a response (such as a new method that requires human interaction) SHOULD instead use two transactions - one to send the request, and another in the reverse direction to convey the result of the request. An example of that is SUBSCRIBE and NOTIFY [6].
o 由于采用新方法对请求进行可靠性处理的性质，UAS需要立即响应这些请求。需要更长时间生成响应的协议扩展（例如需要人工交互的新方法）应该使用两个事务—一个用于发送请求，另一个用于反向传输请求的结果。订阅和通知[6]就是一个例子。
o The SIP specification [2] allows new methods to specify whether transactions using that new method can be canceled using a CANCEL request. Further study of the non-INVITE transaction [14] has determined that non-INVITE transactions must be completed as soon as possible. New methods must not plan for the transaction to pend long enough for CANCEL to be meaningful. Thus, new methods MUST declare that transactions initiated by requests with that method cannot be canceled. Future work may relax this restriction, at which point these guidelines will be revised.
o SIP规范[2]允许新方法指定是否可以使用取消请求取消使用该新方法的事务。对非邀请事务的进一步研究[14]确定，必须尽快完成非邀请事务。新方法不能计划事务挂起足够长的时间，以使取消变得有意义。因此，新方法必须声明不能取消由使用该方法的请求启动的事务。今后的工作可能会放宽这一限制，届时将对这些准则进行修订。
o New methods that establish a new dialog must discuss the impacts of forking. The design of such new methods should follow the pattern of requiring an immediate request in the reverse direction from the request establishing a dialog, similar to the immediate NOTIFY sent when a subscription is created per RFC 3265 [6].
o 建立新对话框的新方法必须讨论分叉的影响。此类新方法的设计应遵循与建立对话框的请求相反方向的即时请求模式，类似于根据RFC 3265创建订阅时发送的即时通知[6]。
The reliability mechanisms for all new methods must be the same as for BYE. The delayed response feature of INVITE is only available in INVITE, never for new methods. The design of new methods must encourage an immediate response. If the application being enabled requires a delay, the design SHOULD follow a pattern using multiple transactions, similar to RFC 3265's use of NOTIFYs with different Subscription-State header field values (pending and active in particular) in response to SUBSCRIBE [6].
所有新方法的可靠性机制必须与BYE相同。INVITE的延迟响应功能仅在INVITE中可用，不适用于新方法。新方法的设计必须鼓励立即作出反应。如果启用的应用程序需要延迟，则设计应遵循使用多个事务的模式，类似于RFC 3265在响应订阅时使用具有不同订阅状态标头字段值（特别是挂起和活动）的NOTIFY[6]。
4.11. Additional Considerations for New Header Fields or Header Field Parameters
4.11. 新标题字段或标题字段参数的其他注意事项
The most important issue for extensions that define new header fields or header field parameters is backwards compatibility. See Section 4.1 for a discussion of the issues. The extension MUST detail how backwards compatibility is addressed.
对于定义新标题字段或标题字段参数的扩展，最重要的问题是向后兼容性。有关这些问题的讨论，请参见第4.1节。扩展必须详细说明如何解决向后兼容性问题。
It is often tempting to avoid creation of a new method by overloading an existing method through a header field or parameter. Header fields and parameters are not meant to fundamentally alter the meaning of the method of the request. A new header field cannot
通过头字段或参数重载现有方法，通常很容易避免创建新方法。头字段和参数并不意味着从根本上改变请求方法的含义。无法创建新的标题字段
change the basic semantic and processing rules of a method. There is no shortage of method names, so when an extension changes the basic meaning of a request, a new method SHOULD be defined.
更改方法的基本语义和处理规则。方法名并不短缺，因此当扩展更改请求的基本含义时，应该定义一个新方法。
For extensions that define new header fields, the extension MUST define the request methods the header field can appear in, and what responses it can be used in. It is RECOMMENDED that this information be represented as a new row of Table 2/3 of RFC 3261 [2]. The table MUST contain columns for all methods defined in standards-track RFCs at the time of writing of the extension.
对于定义新标题字段的扩展，扩展必须定义标题字段可以出现在其中的请求方法，以及可以在哪些响应中使用它。建议将该信息表示为RFC 3261[2]表2/3中的新行。该表必须包含在编写扩展时在标准跟踪RFCs中定义的所有方法的列。
Because SIP can run over UDP, extensions that specify the inclusion of large bodies (where large is several times the ethernet MTU) are frowned upon unless end-to-end congestion controlled transport can be guaranteed. If at all possible, the content SHOULD be included indirectly [9], even if congestion controlled transports are available.
由于SIP可以在UDP上运行，因此除非可以保证端到端的拥塞控制传输，否则不支持指定包含大型实体（其中大型实体是以太网MTU的几倍）的扩展。如果可能的话，应该间接地包括内容[9]，即使可以使用拥塞控制传输。
Note that the presence of a body MUST NOT change the nature of the message. That is, bodies cannot alter the state machinery associated with processing a request of a particular method or a response.
请注意，正文的出现不得改变消息的性质。也就是说，主体不能改变与处理特定方法的请求或响应相关的状态机制。
Bodies enhance this processing by providing additional data.
机构通过提供额外数据来加强这一处理。
We have observed that certain capabilities of SIP continually interact with extensions in unusual ways. Writers of extensions SHOULD consider the interactions of their extensions with these SIP capabilities and document any unusual interactions, if they exist. The following are the most common causes of problems:
我们已经观察到SIP的某些功能以不寻常的方式与扩展不断交互。扩展的作者应该考虑它们的扩展与这些SIP能力的相互作用，并且记录任何异常的交互，如果它们存在的话。以下是问题的最常见原因：
Forking: Forking by far presents the most troublesome interactions with extensions. This is generally because it can cause (1) a single transmitted request to be received by an unknown number of UASes, and (2) a single INVITE request to have multiple responses.
分叉：到目前为止，分叉与扩展的交互是最麻烦的。这通常是因为它会导致（1）一个发送的请求被未知数量的UASE接收，以及（2）一个INVITE请求具有多个响应。
CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in that they are exceptions to many of the general request processing rules. The main reason for this special status is that CANCEL and ACK are always associated with another request. New methods SHOULD consider the meaning of cancellation, as described above. Extensions that define new header fields in INVITE requests SHOULD consider whether they also need to be included in ACK and CANCEL. Frequently they do, in order to allow a stateless proxy to route the CANCEL or ACK identically to the INVITE.
CANCEL和ACK:CANCEL和ACK是“特殊”SIP请求，因为它们是许多一般请求处理规则的例外。此特殊状态的主要原因是CANCEL和ACK始终与另一个请求关联。新方法应考虑取消的意义，如上所述。在邀请请求中定义新的头字段的扩展应该考虑它们是否还需要包含在ACK和取消中。它们经常这样做，以便允许无状态代理以相同的方式将取消或确认路由到INVITE。
Routing: The presence of Route header fields in a request can cause it to be sent through intermediate proxies. Requests that establish dialogs can be record-routed, so that the initial request goes through one set of proxies, and subsequent requests through a different set. These SIP features can interact in unusual ways with extensions.
路由：请求中存在路由头字段会导致它通过中间代理发送。建立对话框的请求可以记录路由，以便初始请求通过一组代理，后续请求通过另一组代理。这些SIP功能可以以不同寻常的方式与扩展进行交互。
Stateless Proxies: SIP allows a proxy to be stateless. Stateless proxies are unable to retransmit messages and cannot execute certain services. Extensions that depend on some kind of proxy processing SHOULD consider how stateless proxies affect that processing.
无状态代理：SIP允许代理是无状态的。无状态代理无法重新传输消息，也无法执行某些服务。依赖于某种代理处理的扩展应该考虑无状态代理如何影响处理。
Dialog Usages: SIP allows for requests that normally create their own dialog (such as SUBSCRIBE) to be used within a dialog created by another method (such as INVITE). In such a case, there are said to be multiple usages of that dialog. Extensions SHOULD consider their interaction with dialog usages. In particular, extensions that define new error response codes SHOULD describe whether that response code causes the dialog and all usages to terminate, or just a specific usage.
对话框用法：SIP允许通常创建自己的对话框（如SUBSCRIBE）的请求在另一个方法（如INVITE）创建的对话框中使用。在这种情况下，据说该对话框有多种用法。扩展应该考虑它们与对话用法的交互。特别是，定义新错误响应代码的扩展应该描述该响应代码是导致对话框和所有用法终止，还是仅导致特定用法终止。
The nature of this document is such that it does not introduce any new security considerations. However, many of the principles described in the document affect whether a potential SIP extension design is likely to support the SIP security architecture.
本文件的性质是不会引入任何新的安全注意事项。然而，文档中描述的许多原则会影响潜在的SIP扩展设计是否可能支持SIP安全体系结构。
The authors would like to thank Rohan Mahy and Spencer Dawkins for their comments. Robert Sparks contributed important text on CANCEL issues. Thanks to Allison Mankin for her support.
作者要感谢Rohan Mahy和Spencer Dawkins的评论。罗伯特·斯帕克斯提供了关于取消问题的重要文本。感谢Allison Mankin的支持。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[3] Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[4] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[5] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[7] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[7] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[8] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[8] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[9] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[9] Burger，E.，Ed.“会话初始化协议（SIP）消息中的内容间接寻址机制”，RFC 4483，2006年5月。
[10] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[10] Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的变更过程”，BCP 67，RFC 3427，2002年12月。
[11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[11] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[12] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[13] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[13] Donovan，S.和J.Rosenberg，“会话启动协议（SIP）中的会话计时器”，RFC 4028，2005年4月。
[14] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, January 2006.
[14] Sparks，R.，“与会话启动协议（SIP）非邀请事务相关的问题识别”，RFC 4321，2006年1月。
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[15] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[16] Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[17] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[17] Handley，M.，Schulzrinne，H.，Schooler，E.，和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[18] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[18] Shacham，A.，Monsour，B.，Pereira，R.，和M.Thomas，“IP有效载荷压缩协议（IPComp）”，RFC 31732001年9月。
[19] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
[19] Arkko，J.，Torvinen，V.，Camarillo，G.，Niemi，A.，和T.Haukka，“会话启动协议（SIP）的安全机制协议”，RFC 33292003年1月。
[20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[20] Price，R.，Bormann，C.，Christofferson，J.，Hannu，H.，Liu，Z.，和J.Rosenberg，“信号压缩（SigComp）”，RFC3320，2003年1月。
[21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[21] Johnston，A.，Donovan，S.，Sparks，R.，Cunningham，C.，和K.Summers，“会话发起协议（SIP）基本呼叫流示例”，BCP 75，RFC 3665，2003年12月。
[22] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[22] Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC 36802004年3月。
[23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[23] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[24] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[25] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[26] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Work in Progress, July 2004.
[26] Reynolds，J.和R.Braden，“征求意见书（RFC）作者须知”，进展中的工作，2004年7月。
[27] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[27] Rescorla，E.和IAB，“编写协议模型”，RFC 41012005年6月。
[28] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[28] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
Authors' Addresses
作者地址
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054号
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@cisco.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
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。