Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 5727 NeuStar, Inc.
BCP: 67 C. Jennings
Obsoletes: 3427 Cisco Systems
Updates: 3265, 3969 R. Sparks
Category: Best Current Practice Tekelec
ISSN: 2070-1721 March 2010
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 5727 NeuStar, Inc.
BCP: 67 C. Jennings
Obsoletes: 3427 Cisco Systems
Updates: 3265, 3969 R. Sparks
Category: Best Current Practice Tekelec
ISSN: 2070-1721 March 2010
Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area
会话启动协议（SIP）以及实时应用程序和基础架构领域的更改过程
Abstract
摘要
This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC 3427.
本备忘录记录了一个过程，旨在组织会话启动协议（SIP）的未来开发以及实时应用程序和基础设施（RAI）领域的相关工作。随着SIP部署环境的日益多样化，以某种方式修改或扩展SIP可能会威胁到协议的互操作性和安全性；然而，IETF过程还必须满足现有部署的现实，并满足使用SIP的实施者的需求。因此，本文件定义了RAI地区两个长期工作组的职能，分别负责维护核心SIP规范，并制定新的努力，以扩展和应用该领域的工作。本文件淘汰RFC 3427。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5727.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5727.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. History and Development . . . . . . . . . . . . . . . . . . . 3
1.1. The IETF SIPCORE Working Group . . . . . . . . . . . . . . 3
1.2. The IETF DISPATCH Working Group . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introducing New Work to RAI . . . . . . . . . . . . . . . . . 6
4. Extensibility and Architecture . . . . . . . . . . . . . . . . 7
4.1. SIP Event Packages . . . . . . . . . . . . . . . . . . . . 9
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Clarification of RFC 3969 . . . . . . . . . . . . . . . . 12
8. Overview of Changes to RFC 3427 . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. History and Development . . . . . . . . . . . . . . . . . . . 3
1.1. The IETF SIPCORE Working Group . . . . . . . . . . . . . . 3
1.2. The IETF DISPATCH Working Group . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introducing New Work to RAI . . . . . . . . . . . . . . . . . 6
4. Extensibility and Architecture . . . . . . . . . . . . . . . . 7
4.1. SIP Event Packages . . . . . . . . . . . . . . . . . . . . 9
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Clarification of RFC 3969 . . . . . . . . . . . . . . . . 12
8. Overview of Changes to RFC 3427 . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
The Session Initiation Protocol (SIP) [RFC3261] has grown well beyond its origins in Internet-based multimedia sessions and now enjoys widespread popularity in Voice-over-IP or IP telephony applications, both inside IETF and within other standards groups. One result of this popularity has been a continual flood of proposals for SIP modifications and extensions. The challenge for IETF management of SIP has been to preserve baseline interoperability across its many implementations
会话发起协议（SIP）[RFC3261]的发展远远超出了其在基于Internet的多媒体会话中的起源，现在在IETF内部和其他标准组中的IP语音或IP电话应用中广受欢迎。这种流行的一个结果是SIP修改和扩展的提案不断涌现。SIP的IETF管理面临的挑战是在其许多实现中保持基线互操作性
In order to defend SIP against changes that might reduce interoperability, the working group chairs and Area Directors responsible for its management authored the SIP change process [RFC3427]. That document defined the role of the SIP and SIPPING Working Groups (WGs) in shepherding ongoing work on the SIP standard. It also defined ways that external working groups or bodies can define extensions intended for limited usage, especially through the "P-" header field mechanism.
为了保护SIP免受可能降低互操作性的更改，工作组主席和负责其管理的区域主管编写了SIP更改流程[RFC3427]。该文件定义了SIP和SIP工作组（WG）在指导SIP标准持续工作中的作用。它还定义了外部工作组或机构可以定义用于有限用途的扩展的方式，特别是通过“P-”标题字段机制。
Over time, however, the management structure of RFC 3427 has demonstrated some limitations. The first and most significant of these concerns "P-" header fields. While "P-" header fields require expert review and IESG shepherding, in practice IETF oversight of these header fields is quite limited, and the value added by the IETF supervising their development remains unclear. More importantly, the presence of a "P-" in front of a header field name does nothing to prevent a popular header field from seeing deployment outside of the original "limited usage" it envisioned; a prominent example of this today is the P-Asserted-Identity (PAID) header field, described in RFC3325 [RFC3325].
然而，随着时间的推移，RFC 3427的管理结构显示出一些局限性。其中第一个也是最重要的一个涉及“P-”标题字段。虽然“P-”标题字段需要专家审查和IESG指导，但实际上IETF对这些标题字段的监督非常有限，IETF监督其开发的附加值仍然不清楚。更重要的是，在头字段名称前面出现“P-”并不能阻止流行的头字段看到其设想的原始“有限使用”之外的部署；今天的一个突出例子是RFC3325[RFC3325]中描述的P-Asserted-Identity（PAID）报头字段。
Consequently, this document obsoletes RFC 3427 and describes a new structure for the management of deliverables in the Real-time Applications and Infrastructure Area.
因此，本文件淘汰了RFC 3427，并描述了实时应用程序和基础设施领域可交付成果管理的新结构。
Historically, the IETF SIP Working Group (sip) was chartered to be the "owner" of the SIP protocol [RFC3261] for the duration of the working group. All changes or extensions to SIP were first required to exist as SIP Working Group documents. The SIP Working Group was charged with being the guardian of the SIP protocol for the Internet, and therefore was mandated only to extend or change the SIP protocol when there were compelling reasons to do so.
从历史上看，IETF SIP工作组（SIP）在工作组期间被特许为SIP协议[RFC3261]的“所有者”。SIP的所有变更或扩展首先要求作为SIP工作组文件存在。SIP工作组被指定为互联网SIP协议的监护人，因此只有在有充分理由时才被授权扩展或更改SIP协议。
The SIPCORE Working Group replaces the function of the SIP Working Group in the original [RFC3427] account. Documents that must be handled by the SIPCORE Working Group include all documents that update or obsolete RFCs 3261 through 3265 or their successors. All SIP extensions considered in SIPCORE must be Standards Track. They may be based upon requirements developed externally in other IETF working groups.
SIPCORE工作组取代了原始[RFC3427]账户中SIP工作组的职能。SIPCORE工作组必须处理的文件包括更新或废弃RFC 3261至3265或其后续文件的所有文件。SIPCORE中考虑的所有SIP扩展必须是标准跟踪。它们可能基于其他IETF工作组外部制定的要求。
Typical IETF working groups do not live forever; however, SIPCORE's charter is open-ended in order to allow it to remain the place where core SIP development will continue. In the event that the SIPCORE Working Group has closed and no suitable replacement or follow-on working group is active (and this specification also has not been superseded), then when modifications to the core SIP protocol are proposed, the RAI Area Directors will use the non-working-group Standards Track document process (described in Section 6.1.2 of RFC 2026 [RFC2026]) using the SIPCORE mailing list and Designated Experts from the SIP community for review.
典型的IETF工作组不会永远存在；然而，SIPCORE的章程是开放的，以允许其继续作为核心SIP开发的场所。如果SIPCORE工作组已关闭，且没有合适的替代或后续工作组处于活动状态（本规范也未被取代），则当提议修改核心SIP协议时，RAI区域主管将使用非工作组标准跟踪文件流程（如RFC 2026[RFC2026]第6.1.2节所述）使用SIPCORE邮件列表和SIP社区指定的专家进行审查。
It is appropriate for any IETF working group to develop SIP event packages [RFC3265], but the working group must have charter approval to do so. The IETF will also require [RFC5226] IETF Review for the registration of event packages developed outside the scope of an IETF working group. Instructions for event package registrations are provided in Section 4.1.
任何IETF工作组开发SIP事件包[RFC3265]都是合适的，但工作组必须获得特许批准才能这样做。IETF还将要求[RFC5226]IETF审查，以注册在IETF工作组范围外开发的事件包。第4.1节提供了事件包注册说明。
Historically, the IETF Session Initiation Protocol Proposal Investigation (sipping) Working Group was chartered to be a filter in front of the SIP Working Group. This working group investigated requirements for applications of SIP, some of which led to requests for extensions to SIP. These requirements may come from the community at large or from individuals who are reporting the requirements as determined by another standards body.
从历史上看，IETF会话发起协议提案调查（SIPING）工作组被特许成为SIP工作组面前的过滤器。该工作组调查了SIP应用程序的需求，其中一些需求导致了对SIP扩展的请求。这些要求可能来自整个社区，也可能来自报告其他标准机构确定的要求的个人。
The DISPATCH Working Group replaces the function of the SIPPING WG, although with several important changes to its functionality -- the most notable being that its scope expands beyond just SIP to the entire work of the RAI Area. Like SIPPING, DISPATCH considers new proposals for work in the RAI Area, but rather than taking on specification deliverables as charter items itself, DISPATCH identifies the proper venue for work. If no such venue yet exists in the RAI Area, DISPATCH will develop charters and consensus for a BoF, working group, or exploratory group [RFC5111] as appropriate. Unlike the previous change structure, a DISPATCH review of any proposed change to core SIP is not required before it progresses to SIPCORE;
调度工作组取代了SIPING工作组的功能，但对其功能进行了几项重要的更改——最值得注意的是，其范围超出了SIP，扩展到了RAI地区的整个工作。与SIPPING一样，DISPATCH考虑RAI地区的新工作建议，但不是将规范交付物本身作为特许项目，而是确定合适的工作地点。如果RAI区域内尚不存在此类场所，调度部将酌情为BoF、工作组或勘探组[RFC5111]制定章程并达成共识。与之前的变更结构不同，在向SIPCORE进展之前，无需对核心SIP的任何拟议变更进行调度审查；
however, any new proposed work that does not clearly fall within the charter of an existing RAI Area effort should be examined by DISPATCH.
然而，任何不明显属于现有RAI区域工作章程范围内的新拟定工作应由调度部门进行审查。
In reaction to a proposal, the DISPATCH Working Group may determine that:
针对提案，派遣工作组可决定：
1. these requirements justify a change to the core SIP specifications (RFCs 3261 through 3265) and thus any resulting work must transpire in SIPCORE;
1. 这些要求证明了对核心SIP规范（RFCs 3261至3265）的更改是合理的，因此任何由此产生的工作必须在SIPCORE中进行；
2. these requirements do not change the SIP core specifications but require a new effort in the RAI Area (be that a working group, a BoF, or what have you);
2. 这些要求不会改变SIP核心规范，但需要在RAI领域做出新的努力（可以是一个工作组、一个BoF，或者你所拥有的任何东西）；
3. these requirements fall within the scope of existing chartered work in the RAI Area; or
3. 这些要求属于RAI地区现有特许工程的范围；或
4. the proposal should not be acted upon at this time.
4. 目前不应执行该建议。
Because the SIP protocol gets so much attention, some application designers may want to use it just because it is there, such as for controlling household appliances. DISPATCH should act as a filter, accepting only proposals that play to the strengths of SIP, not those that confuse its applicability or ultimately reduce its usefulness as a means for immediate personal communications on the Internet.
由于SIP协议受到如此多的关注，一些应用程序设计者可能仅仅因为它存在就想使用它，例如用于控制家用电器。派遣应充当过滤器，只接受发挥SIP优势的建议，而不是混淆其适用性或最终降低其作为互联网上即时个人通信手段的有用性的建议。
In practice, it is expected that the DISPATCH WG behaves as a RAI "Open Area" working group, similar to those employed in other areas of the IETF. While it does not have the traditional deliverables of a working group, DISPATCH may, at the discretion of its chairs and Area Directors, adopt milestones in accordance with standard working group milestone-adoption procedures, such as the production of charter text for a BoF or working group, a "-00" problem statement document that explicates a proposed work effort, or a document explaining why a particular direction for standards development was not pursued.
在实践中，预计调度工作组将作为RAI“开放区域”工作组，类似于IETF其他区域中使用的工作组。虽然派遣公司没有工作组的传统可交付成果，但其主席和区域总监可自行决定根据标准工作组里程碑采用程序采用里程碑，如为BoF或工作组编制章程文本，a“-00”说明拟定工作的问题陈述文件，或说明为何未追求标准开发的特定方向的文件。
In this document, the key words "MAY", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. This document additionally uses [RFC5226] language to describe IANA registrations.
在本文件中，关键词“可能”、“必须”、“不得”、“应该”和“不应该”应按照[RFC2119]中所述进行解释。本文件还使用[RFC5226]语言描述IANA注册。
As with any new work in the IETF, proposals are best formulated in individual Internet-Drafts. New ideas arising within the chartered scope of a RAI Area working group naturally should be treated as candidates for adoption as a working group item there. Experience has demonstrated that authoring a problem statement or set of initial requirements prior to (or at least separately from) submitting a protocol mechanism speeds the consensus-making process significantly. A problem statement should explain what problem needs to be solved, why existing mechanisms are insufficient, and, for proposals to modify SIP, why SIP is the appropriate solution for this problem. A problem statement must also detail any security issues that may result from meeting these requirements. When proposed new work does not fall within the bounds of existing RAI Area working group charters, the DISPATCH Working Group assists the authors of proposals, the RAI Area Directors and the RAI community to decide the best way to approach the problem. Authors of proposals may submit their problem statements to the DISPATCH Working Group for community consideration and review.
与IETF中的任何新工作一样，提案最好在单独的互联网草案中制定。在RAI地区工作组特许范围内产生的新想法自然应被视为作为工作组项目采用的候选方案。经验表明，在提交协议机制之前（或至少与之分开）编写一份问题陈述或一组初始需求，可以显著加快达成共识的过程。问题陈述应解释需要解决的问题，现有机制不足的原因，以及修改SIP的建议，为什么SIP是解决此问题的合适方案。问题声明还必须详细说明满足这些要求可能导致的任何安全问题。当提议的新工程不在现有RAI地区工作组章程的范围内时，派遣工作组协助提案作者、RAI地区主管和RAI社区决定解决问题的最佳方式。提案作者可向派遣工作组提交问题陈述，供社区审议和审查。
The DISPATCH Working Group chairs, in conjunction with the RAI Area Directors, will determine if the particular problems raised in the requirements problem statement are indeed outside the charter of existing efforts and, if so, if they warrant a DISPATCH milestone for the definition of a new effort; this DISPATCH deliverable may take the form of a problem statement Internet-Draft, charter, or similar milestone that provides enough information to make a decision, but must not include protocol development. The DISPATCH Working Group should consider whether the requirements can be merged with other requirements from other applications, and refine the problem statement accordingly.
调度工作组主席将与RAI区域主管一起，确定需求问题声明中提出的特定问题是否确实超出现有工作的范围，如果超出范围，则确定是否需要确定新工作定义的调度里程碑；该调度交付物可以采用问题陈述、互联网草案、章程或类似里程碑的形式，提供足够的信息以做出决策，但不得包括协议开发。调度工作组应考虑需求是否可以与其他应用程序的其他要求合并，并相应地细化问题陈述。
Once a new effort has been defined in DISPATCH and there is working group consensus that it should go forward, if the new effort will take the form of a working group or BoF, then the ADs will present the proposed new effort charter to the IESG and IAB, in accordance with the usual chartering process. If the new effort involves the rechartering of an existing working group, then similarly the existing working group rechartering functions will be performed by the appropriate WG chairs and ADs. If the IESG (with IAB advice) approves of the new charter or BoF, the DISPATCH Working Group has completed its deliverable and the new effort becomes autonomous.
一旦在调度中定义了新的工作，并且工作组一致认为应继续进行，如果新工作将采取工作组或BoF的形式，则ADs将按照通常的特许流程向IESG和IAB提交拟议的新工作章程。如果新的工作涉及现有工作组的重组，则类似地，现有工作组重组职能将由相应的工作组主席和ADs执行。如果IESG（有IAB建议）批准新章程或BoF，调度工作组已完成其可交付成果，新的工作将变得自主。
Anyone proposing requirements for new work is welcome to jointly develop, in a separate Internet-Draft, a mechanism that would meet the requirements. No working group is required to adopt the proposed solution from this additional Internet-Draft.
欢迎任何对新工作提出要求的人在单独的互联网草案中共同制定一个满足要求的机制。无需任何工作组通过本附加互联网草案中的拟议解决方案。
Work overseen by the SIPCORE Working Group is required to protect the architectural integrity of SIP and must not add features that do not have general use beyond the specific case. Also, SIPCORE must not add features just to make a particular function more efficient at the expense of simplicity or robustness.
SIPCORE工作组监督的工作需要保护SIP的体系结构完整性，不得添加除特定情况外不具有一般用途的功能。此外，SIPCORE不能仅仅为了提高特定功能的效率而添加功能，而牺牲简单性或健壮性。
The DISPATCH process is not the sole place that requirements for new work are considered in the RAI Area. For example, some working groups generate requirements for SIP solutions and/or extensions. At the time this document was written, groups with such chartered deliverables include SIP for Instant Messaging and Presence Leveraging Extensions (simple), Basic Level of Interoperability for SIP Services (bliss) and Session Peering for Multimedia Interconnect (speermint). The work of these and similar groups is not affected by the DISPATCH process.
调度流程不是RAI区域考虑新工程要求的唯一场所。例如，一些工作组为SIP解决方案和/或扩展生成需求。在编写本文档时，拥有此类特许交付成果的团队包括用于即时消息和状态利用扩展的SIP（简单）、用于SIP服务的基本互操作性（bliss）和用于多媒体互连的会话对等（speermint）。这些小组和类似小组的工作不受派遣流程的影响。
Of course, the RAI Area Directors may accept charter revisions from existing working groups that add new milestones or scope to their charters at their discretion, in the standard IETF manner, without any actions on the part of the DISPATCH Working Group. DISPATCH exists to assist new work in finding a home expeditiously in those cases where it does not naturally fall into an existing bucket.
当然，RAI区域主管可以接受现有工作组的章程修订，这些工作组可以自行决定，以标准IETF方式，在派遣工作组不采取任何行动的情况下，向其章程添加新的里程碑或范围。派遣旨在协助新工作人员在不自然落入现有桶中的情况下迅速找到住所。
In an idealized protocol model, extensible design would be self-contained, and it would be inherent that new extensions and new header fields would naturally have an architectural coherence with the original protocol.
在理想化的协议模型中，可扩展设计是自包含的，新的扩展和新的头字段自然会与原始协议具有架构一致性。
However, this idealized vision has not been attained in the world of Standards Track protocols. While interoperability implications can be addressed by capabilities negotiation rules, the effects of adding features that overlap, or that deal with a point solution and are not general, are much harder to control with rules. Therefore, the RAI Area calls for architectural guardianship and application of Occam's Razor by the SIPCORE and DISPATCH Working Groups.
然而，在标准轨道协议的世界中还没有实现这种理想化的愿景。虽然互操作性的影响可以通过能力协商规则来解决，但添加重叠的功能，或处理点解决方案的功能，而不是通用的功能，其影响更难通过规则来控制。因此，RAI地区要求SIPCORE和派遣工作组对建筑进行监护并使用Occam剃须刀。
In keeping with the IETF tradition of "running code and rough consensus", it is valid to allow for the development of SIP extensions that are either not ready for Standards Track, but might be understood for that role after some running code or are private or proprietary in nature because a characteristic motivating them is usage that is known not to fit the Internet architecture for SIP. In the past, header fields associated with those extensions were called "P-" header fields for "preliminary", "private", or "proprietary".
根据IETF“运行代码并达成大致共识”的传统，允许开发SIP扩展是有效的，这些扩展要么没有准备好进行标准跟踪，但在运行一些代码后，可能会理解为该角色，或者本质上是私有的或专有的，因为激发它们的一个特征是已知的不适合SIP的Internet体系结构的使用。在过去，与这些扩展相关联的头字段被称为“P-”头字段，用于“初步”、“私有”或“专有”。
However, the "P-" header field process has not served the purpose for which it was designed -- namely, to restrict to closed environments the usage of mechanisms the IETF would not (yet) endorse for general usage. In fact, some "P-" header fields have enjoyed widespread implementation; because of the "P-" prefix, however, there seems to be no plausible migration path to designate these as general-usage header fields without trying to force implausible changes on large installed bases.
然而，“P-”头字段过程并没有达到它设计的目的——也就是说，将IETF不会（尚未）认可的机制的使用限制在封闭环境中。事实上，一些“P-”头字段已经得到了广泛的实现；然而，由于“P-”前缀，似乎没有合理的迁移路径来将这些字段指定为通用标题字段，而不尝试在大型安装基础上强制进行不合理的更改。
Accordingly, this specification deprecates the previous [RFC3427] guidance on the creation of "P-" header fields. Existing "P-" header fields are to be handled by user agents and proxy servers as the "P-" header field specifications describe; the deprecation of the change process mechanism entails no change in protocol behavior. New proposals to document SIP header fields of an experimental or private nature, however, shall not use the "P-" prefix (unless existing deployments or standards use the prefix already, in which case they may be admitted as grandfathered cases at the discretion of the Designated Expert).
因此，本规范不推荐先前[RFC3427]关于创建“P-”标题字段的指导。现有的“P-”头字段将由用户代理和代理服务器处理，如“P-”头字段规范所述；对变更处理机制的反对并不意味着协议行为的改变。但是，记录实验性或私有性质SIP标题字段的新提案不得使用“P-”前缀（除非现有部署或标准已经使用前缀，在这种情况下，指定专家可酌情将其视为祖传案例）。
Instead, the registration of SIP header fields in Informational RFCs, or in documents outside the IETF, is now permitted under the Designated Expert (per [RFC5226]) criteria. The future use of any header field name prefix ("P-" or "X-" or what have you) to designate SIP header fields of limited applicability is discouraged. Experts are advised to review documents for overlap with existing chartered work in the RAI Area, and are furthermore instructed to ensure the following two criteria are met:
相反，根据指定专家（根据[RFC5226]）标准，现在允许在信息RFC或IETF之外的文档中注册SIP头字段。不鼓励将来使用任何标题字段名称前缀（“P-”或“X-”或您所拥有的东西）来指定适用性有限的SIP标题字段。建议专家审查与RAI地区现有特许工程重叠的文件，并进一步指示专家确保满足以下两个标准：
1. The proposed header field MUST be of a purely informational nature and MUST NOT significantly change the behavior of SIP entities that support it. Header fields that merely provide additional information pertinent to a request or a response are acceptable; these header fields are thus expected to have few, if any, implications for interoperability and backwards compatibility. Similarly, header fields that provide data consumed by applications at the ends of SIP's rendezvous function, rather than changing the behavior of the rendezvous function, are likely to be providing information in this sense. If the header fields redefine or contradict normative behavior defined in Standards Track SIP specifications, that is what is meant by significantly different behavior. Ultimately, the significance of differences in behavior is a judgment call that must be made by the expert reviewer.
1. 建议的头字段必须是纯信息性的，并且不能显著改变支持它的SIP实体的行为。仅提供与请求或响应相关的附加信息的标题字段是可接受的；因此，这些标题字段对互操作性和向后兼容性几乎没有影响（如果有的话）。类似地，在SIP的会合功能结束时提供应用程序使用的数据的头字段（而不是更改会合功能的行为）很可能提供这种意义上的信息。如果标题字段重新定义或与标准跟踪SIP规范中定义的规范性行为相矛盾，这就是显著不同行为的含义。归根结底，行为差异的重要性是专家评审员必须做出的判断。
2. The proposed header field MUST NOT undermine SIP security in any sense. The Internet-Draft proposing the new header field MUST address security issues in detail, as if it were a Standards
2. 建议的标头字段不得在任何意义上破坏SIP安全性。提议新标题字段的Internet草案必须详细解决安全问题，就像它是一个标准一样
Track document. Note that, if the intended application scenario makes certain assumptions regarding security, the security considerations only need to meet the intended application scenario rather than the general Internet case. In any case, security issues need to be discussed for arbitrary usage scenarios (including the general Internet case).
跟踪文档。请注意，如果预期的应用场景对安全性做出了某些假设，那么安全考虑事项只需要满足预期的应用场景，而不是一般的Internet情况。在任何情况下，都需要讨论任意使用场景（包括一般Internet情况）的安全问题。
Note that the deprecation of the "P-" header field process does not alter processes for the registration of SIP methods, URI parameters, response codes, or option tags.
请注意，“P-”头字段进程的弃用不会改变注册SIP方法、URI参数、响应代码或选项标记的进程。
SIP events [RFC3265] defines two different types of event packages: normal event packages and event template-packages. Event template-packages can only be created and registered by the publication of a Standards Track RFC (from an IETF Working Group). Note that the guidance in [RFC3265] states that the IANA registration policy for normal event packages is "First Come First Serve"; this document replaces that policy with the following:
SIP事件[RFC3265]定义了两种不同类型的事件包：普通事件包和事件模板包。事件模板包只能通过发布标准跟踪RFC（来自IETF工作组）来创建和注册。请注意，[RFC3265]中的指导说明，正常事件包的IANA注册政策为“先到先得”；本文档将该策略替换为以下内容：
Individuals may wish to publish SIP Event packages that they believe fall outside the scope of any chartered work currently in RAI. Individual proposals for registration of a SIP event package MUST first be published as Internet-Drafts for review by the DISPATCH Working Group, or the working group, mailing list, or expert designated by the RAI Area Directors if the DISPATCH Working Group has closed. Proposals should include a strong motivational section, a thorough description of the proposed syntax and semantics, event package considerations, security considerations, and examples of usage. Authors should submit their proposals as individual Internet-Drafts and post an announcement to the working group mailing list to begin discussion. The DISPATCH Working Group will determine if a proposed package is
个人可能希望发布他们认为不属于RAI当前特许工作范围的SIP事件包。SIP事件包注册的个人提案必须首先作为互联网草稿发布，以供调度工作组或RAI区域主管指定的工作组、邮件列表或专家（如果调度工作组已关闭）审查。提案应包括一个强有力的动机部分，对提议的语法和语义、事件包注意事项、安全注意事项和使用示例的全面描述。作者应将其提案作为个人互联网草案提交，并向工作组邮件列表发布公告，以开始讨论。调度工作组将决定是否批准拟定的包
a) an appropriate usage of SIP that should be spun into a new effort,
a) 适当地使用SIP，并将其转化为新的成果，
b) applicable to SIP but not sufficiently interesting, general, or in-scope to adopt as a working group effort,
b) 适用于SIP，但没有足够的趣味性、一般性或范围作为工作组的工作，
c) contrary to similar work chartered in an existing effort, or
c) 与现有工作中特许的类似工作相反，或
d) recommended to be adopted as or merged with chartered work elsewhere in RAI.
d) 建议作为特许工程采用或与RAI其他地方的特许工程合并。
"RFC Required" in conjunction with "Designated Expert" (both as defined in RFC 5226) is the procedure for registration of event packages developed outside the scope of an IETF working group, according to the following guidelines:
“需要RFC”与“指定专家”（两者均在RFC 5226中定义）是根据以下指南，在IETF工作组范围外开发的事件包注册程序：
1. A Designated Expert (as defined in RFC 5226) must review the proposal for applicability to SIP and conformance with these guidelines. The Designated Expert will send email to the IESG on this determination. The expert reviewer can cite one or more of the guidelines that have not been followed in his/her opinion.
1. 指定专家（定义见RFC 5226）必须审查该提案对SIP的适用性以及是否符合这些指南。指定专家将就此决定向IESG发送电子邮件。专家评审员可以引用他/她的意见中未遵循的一个或多个指南。
2. The proposed extension MUST NOT define an event template-package.
2. 建议的扩展不能定义事件模板包。
3. The function of the proposed package MUST NOT overlap with current or planned chartered packages.
3. 拟定包的功能不得与当前或计划的特许包重叠。
4. The event package MUST NOT redefine or contradict the normative behavior of SIP events [RFC3265], SIP [RFC3261], or related Standards Track extensions. (See Section 4.)
4. 事件包不得重新定义或违反SIP事件[RFC3265]、SIP[RFC3261]或相关标准跟踪扩展的规范行为。（见第4节。）
5. The proposed package MUST NOT undermine SIP security in any sense. The Internet-Draft proposing the new package MUST address security issues in detail as if it were a Standards Track document. Security issues need to be discussed for arbitrary usage scenarios (including the general Internet case).
5. 提议的包在任何意义上都不得破坏SIP安全性。提出新方案的互联网草案必须详细解决安全问题，就像它是一份标准跟踪文件一样。需要讨论任意使用场景（包括一般Internet情况）的安全问题。
6. The proposed package MUST be clearly documented in an (Individual) Informational RFC and registered with IANA. The package MUST document all the package considerations required in Section 4 of SIP events [RFC3265].
6. 建议的包必须清楚地记录在（单独的）信息RFC中，并在IANA注册。包必须记录SIP事件[RFC3265]第4节中要求的所有包注意事项。
7. If determined by the Designated Expert or the chairs or ADs of the DISPATCH WG, an applicability statement in the Informational RFC MUST clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP in the Internet.
7. 如果由指定专家或派遣工作组主席或广告确定，信息RFC中的适用性声明必须清楚地记录提案的有用范围，并解释其局限性以及为什么不适合在互联网上普遍使用SIP。
1. Documents that update or obsolete RFCs 3261 through 3265 must advance through the SIPCORE WG.
1. 更新或废弃RFC 3261至3265的文件必须通过SIPCORE工作组提交。
2. Standard SIP extensions that do not update RFCs 3261 through 3265, including event packages, may advance through chartered activity in any RAI Area WG or (with the agreement of the RAI ADs) any IETF working group that constitutes an appropriate venue.
2. 未更新RFC 3261至3265的标准SIP扩展，包括活动包，可通过任何RAI工作组或（经RAI ADs同意）任何IETF工作组（构成适当场所）的特许活动推进。
3. Documents that specify Informational header fields pass through an Expert Review system.
3. 指定信息标题字段的文档通过专家评审系统。
Complex, indeterminate, and hard-to-define protocol behavior, depending on the interaction of many optional extensions, is a fine breeding ground for security flaws.
复杂、不确定且难以定义的协议行为（取决于许多可选扩展的交互）是安全缺陷的良好滋生地。
All Internet-Drafts that present new requirements for SIP must include a discussion of the security requirements and implications inherent in the proposal. All RFCs that modify or extend SIP must show that they have adequate security, must consider the security implications of feature interactions, and most of all must not worsen SIP's existing security considerations.
所有提出SIP新要求的互联网草案必须包括对提案中固有的安全要求和影响的讨论。所有修改或扩展SIP的RFC都必须显示它们具有足够的安全性，必须考虑特征交互的安全影响，并且最重要的是不能恶化SIP的现有安全考虑。
RFC 3261 directs the Internet Assigned Numbers Authority (IANA) to establish a registry for SIP method names, a registry for SIP option tags, and a registry for SIP response codes, and to amend the practices used for the existing registry for SIP header fields. Reiterating the guidance of RFC 3261, method names, option tags, and SIP response codes require a Standards Action for inclusion in the IANA registry. Authors of specifications should also be aware that the SIP parameter registry is further elaborated in [RFC3968].
RFC 3261指示Internet Assigned Numbers Authority（IANA）建立SIP方法名称注册表、SIP选项标记注册表和SIP响应代码注册表，并修改SIP头字段现有注册表的做法。重申RFC 3261、方法名称、选项标签和SIP响应代码的指导，需要在IANA注册表中包含标准操作。规范的作者还应注意，[RFC3968]中进一步阐述了SIP参数注册表。
Previously in RFC 3427, all new SIP header field registrations required a Standards Action (per RFC 5226) with the exception of "P-" header fields; now, Informational registration of non-"P-" header fields is permitted if approved by a Designated Expert, as described in Section 4.
以前在RFC 3427中，所有新的SIP头字段注册都需要标准操作（根据RFC 5226），但“P-”头字段除外；现在，如第4节所述，如果指定专家批准，则允许对非“P-”标题字段进行信息注册。
Each RFC shall include an IANA Considerations section that directs IANA to create appropriate registrations. Registration shall be done at the time the IESG announces its approval of the draft containing the registration requests.
每个RFC应包括一个IANA注意事项部分，指导IANA创建适当的注册。注册应在IESG宣布批准包含注册请求的草案时完成。
Standard header fields and messages MUST NOT begin with the leading characters "P-". Existing "P-" header field registrations are considered grandfathered, but new registrations of Informational header fields should not begin with the leading characters "P-" (unless the "P-" would preserve compatibility with a pre-existing, unregistered usage of the header field, at the discretion the Designated Expert). Short forms of header fields MUST only be assigned to Standards Track header fields.
标准标题字段和消息不得以前导字符“P-”开头。现有的“P-”标题字段注册被视为加号，但信息标题字段的新注册不应以前导字符“P-”开头（除非“P-”将保留与预先存在的未注册标题字段用法的兼容性，由指定专家自行决定）。短格式的标题字段只能指定给标准的磁道标题字段。
Similarly, [RFC3265] directs the IANA to establish a registry for SIP event packages and SIP event template-packages. For event template-packages, registrations must follow the [RFC5226] processes for Standards Action within an IETF working group. For normal event packages, as stated previously, registrations minimally require [RFC5226] "RFC Required" with "Designated Expert". In either case, the IESG announcement of RFC approval authorizes IANA to make the registration.
类似地，[RFC3265]指示IANA为SIP事件包和SIP事件模板包建立注册表。对于事件模板包，注册必须遵循IETF工作组内的[RFC5226]标准行动流程。如前所述，对于正常事件包，注册最低要求[RFC5226]“需要RFC”和“指定专家”。在任何一种情况下，IESG关于RFC批准的公告授权IANA进行注册。
[RFC3969] stipulates that the (original) [RFC2434] rule of "Specification Required" applies to registrations of new SIP URI parameters; however, Section 3 of that same document mandates that a Standards Action is required to register new parameters with the IANA. This contradiction arose from a misunderstanding of the nature of the [RFC2434] categories; the intention was for the IANA Considerations to mandate that Standards Action is required.
[RFC3969]规定，“所需规范”的（原始）[RFC2434]规则适用于新SIP URI参数的注册；然而，同一文件的第3节规定，需要标准行动向IANA注册新参数。这一矛盾源于对[RFC2434]类别性质的误解；其目的是为了IANA的考虑，要求采取标准行动。
This section provides a high-level overview of the changes between this document and RFC 3427. It is not a substitute for the document as a whole -- the details are necessarily not represented.
本节从高层次概述了本文档与RFC 3427之间的更改。它不能代替整个文件——细节不一定代表。
This document:
本文件：
1. Changes the description of the SIP and SIPPING WG functions to the SIPCORE and DISPATCH WG functions using the context of the RAI Area.
1. 使用RAI区域的上下文将SIP和SIPING WG函数的描述更改为SIPCORE和DISPATCH WG函数。
2. Deprecates the process for "P-" header field registration, and changes the requirements for registration of SIP header fields of a purely informational nature.
2. 不推荐“P-”头字段注册的过程，并更改注册纯信息性质的SIP头字段的要求。
3. Updates IANA registry requirements, reflecting the publication of RFC 5226, clarifying the policies in RFC 3969, and clarifying that the original RFC 3237 updated the policies in RFC 3265.
3. 更新IANA注册要求，反映RFC 5226的发布，澄清RFC 3969中的政策，并澄清原始RFC 3237更新了RFC 3265中的政策。
The credit for the notion that SIP required careful management belongs to the original authors: Allison Mankin, Scott Bradner, Rohan Mahy, Dean Willis, Joerg Ott, and Brian Rosen. The current editors have provided only an update to reflect lessons learned from running the code and from the changing situation of the IETF and the IANA registration procedures. Gonzalo Camarillo was instrumental to the development of the concept of SIPCORE and DISPATCH. Useful comments
认为SIP需要仔细管理的观点应该归功于最初的作者：Allison Mankin、Scott Bradner、Rohan Mahy、Dean Willis、Joerg Ott和Brian Rosen。目前的编辑只提供了一个更新，以反映从运行代码以及IETF和IANA注册程序不断变化的情况中吸取的经验教训。冈萨洛·卡马里洛对SIPCORE和调度概念的发展起到了重要作用。有用的评论
were provided by Jonathan Rosenberg, Mary Barnes, Dan York, John Elwell, Alan Johnston, Spencer Dawkins, Alfred Hoenes, Russ Housley, and Dean Willis. The thorough review from Stephen Hanna of the Security Directorate proved enormously valuable. The authors also appreciated IESG feedback from Alexey Melnikov, Adrian Farrel, Dan Romascanu, and Magnus Westerlund.
由Jonathan Rosenberg、Mary Barnes、Dan York、John Elwell、Alan Johnston、Spencer Dawkins、Alfred Hoenes、Russ Housley和Dean Willis提供。安全局的斯蒂芬·汉纳（Stephen Hanna）的彻底审查证明是非常有价值的。作者还感谢来自Alexey Melnikov、Adrian Farrel、Dan Romascanu和Magnus Westerlund的IESG反馈。
The original authors thanked their IESG and IAB colleagues (especially Randy Bush, Harald Alvestrand, John Klensin, Leslie Daigle, Patrik Faltstrom, and Ned Freed) for valuable discussions of extensibility issues in a wide range of protocols, including those that our area brings forward and others. Thanks to the many members of the SIP community engaged in interesting dialogue about this document as well, including and especially Jonathan Rosenberg, Henning Schulzrinne, and William Marshall.
最初的作者感谢他们的IESG和IAB同事（特别是Randy Bush、Harald Alvestrand、John Klesins、Leslie Daigle、Patrik Faltstrom和Ned Freed）在广泛的协议中对可扩展性问题进行了有价值的讨论，包括我们领域提出的协议和其他协议。感谢SIP社区的许多成员参与了关于本文件的有趣对话，包括尤其是乔纳森·罗森博格、亨宁·舒尔兹林内和威廉·马歇尔。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3969] 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.
[RFC3969]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC3427] 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.
[RFC3427]Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的更改过程”，BCP 67，RFC 3427，2002年12月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月。
[RFC5111] Aboba, B. and L. Dondeti, "Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF)", RFC 5111, January 2008.
[RFC5111]Aboba，B.和L.Dondeti，“互联网工程任务组（IETF）内探索小组形成的实验”，RFC 5111，2008年1月。
Authors' Addresses
作者地址
Jon Peterson NeuStar, Inc.
乔恩·彼得森纽斯达公司。
EMail: jon.peterson@neustar.biz
EMail: jon.peterson@neustar.biz
Cullen Jennings Cisco Systems
库伦詹宁斯思科系统公司
EMail: fluffy@cisco.com
EMail: fluffy@cisco.com
Robert Sparks Tekelec
罗伯特·斯帕克斯·特凯莱克
EMail: rjsparks@nostrum.com
EMail: rjsparks@nostrum.com