Network Working Group A. Mankin
Request for Comments: 3427 Bell Labs, Lucent Corporation
BCP: 67 S. Bradner
Category: Best Current Practice Harvard University
R. Mahy
Cisco
D. Willis
dynamicsoft
J. Ott
ipDialog / Uni Bremen TZI
B. Rosen
Marconi
December 2002
Network Working Group A. Mankin
Request for Comments: 3427 Bell Labs, Lucent Corporation
BCP: 67 S. Bradner
Category: Best Current Practice Harvard University
R. Mahy
Cisco
D. Willis
dynamicsoft
J. Ott
ipDialog / Uni Bremen TZI
B. Rosen
Marconi
December 2002
Change Process for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的更改过程
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions.
本备忘录记录了一个旨在将架构规程应用于会话启动协议（SIP）未来开发的过程。有人对新的SIP提案表示关注。具体而言，添加新的SIP功能可能会损害安全性和/或大大增加协议的复杂性。交通区域主管以及SIP和会话启动提案调查（SIPING）工作组主席为SIP修改和扩展提供了建议。
In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in Keywords [1].
在本文件中，关键词“可能”、“必须”、“不得”、“应该”和“不应该”应按照关键词[1]中所述进行解释。
The IETF's Session Initiation Protocol (SIP) [3] was originally developed for initiation of multimedia sessions. Internet multimedia, voice over IP, IP telephony, and SIP have become quite popular, both inside IETF and with other standards groups, and the applications of SIP have grown. One result of this popularity has been a continual flood of suggestions for SIP modifications and extensions. The task for IETF management of SIP has been to keep the protocol development focused on SIP's core strengths and the applications it does best.
IETF的会话启动协议（SIP）[3]最初是为启动多媒体会话而开发的。Internet多媒体、IP语音、IP电话和SIP在IETF内部和其他标准组中都非常流行，SIP的应用也在增长。这种流行的一个结果就是不断涌现出大量关于SIP修改和扩展的建议。IETF管理SIP的任务是使协议开发集中于SIP的核心优势和它最擅长的应用。
The IETF SIP Working Group has been chartered to be the "owner" of the SIP protocol [3], as long as the working group exists. All changes or extensions to SIP must first exist as SIP Working Group documents. The SIP Working group is charged with being the guardian of the SIP protocol for the Internet, and therefore should only extend or change the SIP protocol when there are compelling reasons to do so.
IETF SIP工作组被特许为SIP协议的“所有者”[3]，只要该工作组存在。对SIP的所有更改或扩展必须首先作为SIP工作组文件存在。SIP工作组负责作为互联网SIP协议的监护人，因此只有在有迫切理由时才应扩展或更改SIP协议。
Documents that must be handled by the SIP working group include new SIP methods, new SIP option tags, new response codes, and new standards track SIP headers. With the exception of "P-" headers described in Section 4.1, all SIP extensions must be standards track and must be developed in the IETF based upon requirements provided by the SIPPING Working Group.
必须由SIP工作组处理的文档包括新的SIP方法、新的SIP选项标记、新的响应代码和新的标准跟踪SIP头。除第4.1节中描述的“P-”标题外，所有SIP扩展必须是标准跟踪，并且必须根据啜饮工作组提供的要求在IETF中开发。
IETF working groups do not live forever; typically, mailing lists continue after the working group is concluded. If the SIP Working Group has closed and no suitable replacement or follow-on working group is active, the Transport Area directors will the use the non-working group standards track document process (described in section 6.1.2 of RFC 2026--IETF Standards Process [2]) using the SIP and SIPPING mailing lists and designated experts from the SIP community for advice. The IETF will remain the home of extensions of SIP and the requirement of standards track action will remain as defined in the rest of this document. The rate of growth of extensions of any protocol in the IETF is hoped to be low.
IETF工作组不会永远存在；通常，邮件列表在工作组结束后继续。如果SIP工作组已经结束，且没有合适的替代或后续工作组处于活动状态，则运输区域主管将使用非工作组标准跟踪文件流程（如RFC 2026——IETF标准流程[2]第6.1.2节所述）使用SIP和SIP邮件列表以及SIP社区的指定专家寻求建议。IETF仍将是SIP扩展的所在地，标准跟踪行动的要求仍将如本文件其余部分所定义。IETF中任何协议扩展的增长率都希望很低。
It is appropriate for any working group to develop SIP event packages [4], but the working group must have charter approval to do so. The IETF will also require (Individual) RFC publication for the registration of event packages developed outside the scope of an IETF working group. Requirements for publishing event packages are described in detail in Section 4.3.
任何工作组开发SIP事件包[4]都是合适的，但工作组必须获得特许批准才能这样做。IETF还将要求（单独）RFC出版物，用于注册在IETF工作组范围外开发的事件包。第4.3节详细描述了发布事件包的要求。
The IETF Session Initiation Protocol Proposal Investigation (sipping) Working Group is chartered to be a filter in front of the SIP Working Group. This working group will investigate requirements for applications of SIP, some of which may lead 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. The SIPPING Working Group will also not live forever, with similar consideration to the sections above.
IETF会话发起协议提案调查（SIPING）工作组被授权为SIP工作组前面的过滤器。该工作组将调查SIP应用程序的需求，其中一些可能导致SIP扩展请求。这些要求可能来自整个社区，也可能来自报告其他标准机构确定的要求的个人。啜饮工作组也不会永远存在，与上述章节的考虑类似。
The SIPPING Working Group may determine: that these requirements can be satisfied by SIP without modifications, that the requirements are not sufficiently general to warrant a change to SIP, that the requirements justify a change to SIP, or that the requirements should be combined with other requirements to solve a more general problem or solve the same problem in a more flexible way.
SIP工作组可确定：SIP无需修改即可满足这些要求，这些要求不足以保证SIP变更，这些要求证明SIP变更是合理的，或者，这些需求应该与其他需求相结合，以解决更一般的问题，或者以更灵活的方式解决相同的问题。
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. SIPPING should act as a filter, accepting only requirements which play to the best strengths of SIP, such as realtime presence.
由于SIP协议受到如此多的关注，一些应用程序设计者可能仅仅因为它存在就想使用它，例如用于控制家用电器。啜饮应该充当一个过滤器，只接受发挥SIP最佳优势的需求，如实时存在。
When the SIPPING working group decides on a set of requirements, it forwards them to the SIP working group. The SIPPING Working Group may also document usage or applications of SIP which do not require any protocol extensions.
当SIP工作组决定一组要求时，它将其转发给SIP工作组。啜饮工作组还可以记录不需要任何协议扩展的SIP的使用或应用。
The SIPPING working group also acts as a filter for proposed event packages as described in Section 4.3.
啜饮工作组还充当第4.3节所述拟议事件包的过滤器。
Anyone who thinks that the existing SIP protocol is applicable to their application, yet not sufficient for their task must write an individual Internet-Draft explaining the problem they are trying to solve, why SIP is the applicable protocol, and why the existing SIP protocol will not work. The Internet-Draft must include a detailed set of requirements (distinct from solutions) that SIP would need to meet to solve the particular problem. The Internet-Draft must also describe in detail any security issues that arise from meeting those requirements. After the Internet-Draft is published, the authors should send a note to the SIPPING Working Group mailing list to start discussion on the Internet-Draft.
任何认为现有SIP协议适用于其应用程序，但不足以完成其任务的人都必须编写一份单独的互联网草案，解释他们试图解决的问题、为什么SIP是适用的协议以及为什么现有SIP协议不起作用。互联网草案必须包括一组详细的要求（不同于解决方案），SIP需要满足这些要求才能解决特定问题。互联网草案还必须详细描述因满足这些要求而产生的任何安全问题。互联网草案发布后，作者应向啜饮工作组邮件列表发送一份说明，开始讨论互联网草案。
The SIPPING working group chairs, in conjunction with the Transport Area Directors, will determine if the particular problems raised in the requirements Internet-Draft warrants being added to the SIPPING charter based on the mailing list discussion. The SIPPING working group should consider whether the requirements can be merged with other requirements from other applications, and refine the ID accordingly.
啜饮工作组主席将与运输区域主管一起，根据邮件列表讨论，确定要求互联网草案中提出的特定问题是否需要添加到啜饮章程中。啜饮工作组应考虑需求是否可以与其他应用程序的其他要求合并，并相应地细化ID。
If the chairs and the ADs both feel that the particular new problems should be added to the SIPPING Working Group charter, then the ADs will present the proposed SIPPING charter modifications to the IESG and IAB, in accordance with the usual process for charter expansion. If the IESG (with IAB advice) approves of the charter changes, the SIPPING working group can then work on the problems described in the Internet-Draft.
如果主席和ADs都认为应将特定的新问题添加到啜饮工作组章程中，则ADs将根据章程扩展的通常流程，向IESG和IAB提交提议的啜饮章程修改。如果IESG（提供IAB建议）批准章程变更，那么啜饮工作组可以处理互联网草案中描述的问题。
In a separate Internet-Draft, the authors may describe a set of changes to SIP that would meet the requirements. The Internet-Draft would then be passed to the SIP working group for consideration (if warranted). The SIP working group is not required to adopt the proposed solution from this additional Internet-Draft.
在一份单独的互联网草案中，作者可能会描述一组符合要求的SIP变更。然后，互联网草案将提交SIP工作组审议（如有必要）。SIP工作组无需采纳本附加互联网草案中的拟议解决方案。
The SIPPING working group may also evaluate such proposals for extensions if the requirements are judged to be appropriate to SIP, but are not sufficiently general for standards track activity. The SIPPING working group will attempt to determine if the new proposal meets the requirements for publication as a "P-" header, as described in Section 4.1, within a specific scope of applicability.
如果判定要求适用于SIP，但对于标准跟踪活动而言不够普遍，则SIP工作组也可以评估此类扩展建议。啜饮工作组将尝试确定新提案是否符合第4.1节所述的在特定适用范围内作为“P-”标题发布的要求。
The Transport ADs may, on a case by case basis, support a process in which the requirements analysis is implicit and the SIP working group requests the addition of a charter item for an extension without a full SIPPING process as described. This will be the exception.
交通ADs可在个案基础上支持一个过程，在该过程中，需求分析是隐含的，SIP工作组要求在没有如所述的完全啜饮过程的情况下为扩展添加特许项目。这将是一个例外。
With respect to standardization, this process means that SIP extensions come only from the IETF, the body that created SIP. The IETF will not publish a SIP extension RFC outside of the processes described here.
关于标准化，这个过程意味着SIP扩展只来自IETF，即创建SIP的主体。IETF不会在此处描述的过程之外发布SIP扩展RFC。
The SIP 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, they must not add features just to make a particular function more efficient at the expense of simplicity or robustness.
SIP工作组必须保护SIP的体系结构完整性，并且不得添加除特定情况外不具有一般用途的功能。此外，他们不能仅仅为了提高特定功能的效率而添加功能，而以牺牲简单性或健壮性为代价。
Some working groups besides SIPPING generate requirements for SIP solutions and/or extensions as well. At the time this document was written, these include SIP for Instant Messaging and Presence Leveraging Extensions (simple), Service in the PSTN/IN Requesting InTernet Service (spirits), and Telephone Number Mapping (enum).
除了SIPPING之外，一些工作组还生成了SIP解决方案和/或扩展的需求。在编写本文档时，其中包括用于即时消息和状态扩展的SIP（简单）、PSTN/in请求InTernet服务中的服务（spirits）和电话号码映射（enum）。
In an idealized protocol model, extensible design would be self-contained, and it would be inherent that new extensions and new headers 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 Transport Area calls for architectural guardianship and application of Occam's Razor by the SIP Working Group.
然而，在标准轨道协议的世界中还没有实现这种理想化的愿景。虽然互操作性的影响可以通过能力协商规则来解决，但添加重叠的功能，或处理点解决方案的功能，而不是通用的功能，其影响更难通过规则来控制。因此，交通区域要求SIP工作组对建筑进行监护并使用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. We call these "P-" headers, for "preliminary", "private", or "proprietary".
根据IETF“运行代码和大致共识”的传统，允许开发SIP扩展是有效的，这些扩展要么未准备好用于标准跟踪，但在运行一些代码后可能会被理解为该角色，要么是私有的或专有的，因为激发他们的一个特征是已知的不适合SIP的Internet体系结构的使用。我们将这些标题称为“P-”，表示“初步”、“私有”或“专有”。
There are two key issues to consider with respect to keeping the "P-" header extension space "safe":
关于保持“p”标题扩展空间“安全”，有两个关键问题需要考虑：
1. Clearly indicating the unarchitected or not-yet understood nature of the extension.
1. 明确指出扩展的未架构或尚未理解的性质。
2. Preventing identity conflicts between extensions.
2. 防止扩展之间的身份冲突。
4.1 Indicating a "P-" Header:
4.1 指示“P-”标题：
Use of an "X-" prefix on textual identifiers has been widely used to indicate experimental extensions in other protocols. This approach is applied in modified form here by use of a "P-" header extension. However, there are a number of stronger constraints for "P-" headers, including documentation that get Expert and IESG review, and other SIP protocol criteria described below.
在文本标识符上使用“X-”前缀已被广泛用于指示其他协议中的实验性扩展。这里使用“P-”标题扩展以修改的形式应用此方法。然而，“P-”头有许多更严格的限制，包括获得专家和IESG审查的文档，以及下面描述的其他SIP协议标准。
Informational SIP Headers can be registered as "P-" headers if all of the following conditions are met:
如果满足以下所有条件，则信息性SIP头可以注册为“P-”头：
1. A designated expert (as defined in RFC 2434 [4]) MUST review the proposal for applicability to SIP and conformance to these guidelines. The Expert Reviewer will send email to the Transport Area Directors on this determination. The expert reviewer can cite one or more of the guidelines that haven't been followed in his/her opinion.
1. 指定专家（如RFC 2434[4]中所定义）必须审查提案对SIP的适用性以及是否符合这些指南。专家评审员将就此决定向运输区主管发送电子邮件。专家评审员可以引用他/她的意见中未遵循的一个或多个指南。
2. The proposed extension MUST NOT define SIP option tags, response codes, or methods.
2. 建议的扩展不得定义SIP选项标记、响应代码或方法。
3. The function of the proposed header MUST NOT overlap with current or planned chartered extensions.
3. 拟定标题的功能不得与当前或计划的特许扩展重叠。
4. The proposed header MUST be of a purely informational nature, and MUST NOT significantly change the behavior of SIP entities which support it. Headers which merely provide additional information pertinent to a request or a response are acceptable. If the headers redefine or contradict normative behavior defined in standards track SIP specifications, that is what is meant by significantly different behavior.
4. 建议的头必须是纯信息性的，并且不能显著改变支持它的SIP实体的行为。仅提供与请求或响应相关的附加信息的标题是可以接受的。如果标头重新定义或与标准跟踪SIP规范中定义的规范性行为相矛盾，这就是显著不同行为的含义。
5. The proposed header MUST NOT undermine SIP security in any sense. The Internet Draft proposing the new header MUST address security issues in detail as if it were a Standards 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).
5. 提议的报头不得在任何意义上破坏SIP安全性。提议新标题的互联网草案必须详细解决安全问题，就像它是一份标准跟踪文件一样。请注意，如果预期的应用场景对安全性做出了某些假设，那么安全考虑事项只需要满足预期的应用场景，而不是一般的Internet情况。在任何情况下，都需要讨论任意使用场景（包括一般Internet情况）的安全问题。
6. The proposed header MUST be clearly documented in an (Individual or Working Group) Informational RFC, and registered with IANA.
6. 建议的标题必须清楚地记录在（个人或工作组）信息RFC中，并在IANA注册。
7. 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。
Any implementation of a "P-" header (meaning "not specified by a standards-track RFC issued through the SIP Working Group") MUST include a "P-" prefix on the header, as in "P-Headername". Note that "P-" extensions are not IETF standards of any kind, and MUST NOT be required by any production deployment considered compliant to IETF specifications. Specifically, implementations are only SIP compliant
“P-”标题的任何实现（意思是“未由SIP工作组发布的标准跟踪RFC指定”）必须在标题上包含“P-”前缀，如“P-标题名称”中所述。请注意，“P-”扩展不是任何类型的IETF标准，任何被认为符合IETF规范的生产部署都不需要。具体来说，实现仅符合SIP
if a) they fall back to baseline behavior when they ignore all P-headers, and b) when using P- headers they do not contradict any normative behavior.
如果a）当他们忽略所有P-标题时，他们退回到基线行为，并且b）当使用P-标题时，他们不违反任何规范行为。
4.2 Preventing Identity Conflicts Between P-Extensions:
4.2 防止P扩展之间的身份冲突：
In order to prevent identity conflicts between P-headers, this document provides an IANA process (See: "IANA Considerations" below) to register the P-headers. The handling of unknown P-headers is to ignore them, however, section 4.1 is to be taken seriously, and users of P-headers will have best results with adherence. All implemented P-headers SHOULD meet the P-Header requirements in 4.1. Any P-header used outside of a very restricted research or teaching environment (such as a student lab on implementing extensions) MUST meet those requirements and MUST be documented in an RFC and be IANA registered. IANA registration is permitted when the IESG approves the internet-draft.
为了防止P-Header之间的身份冲突，本文档提供了注册P-Header的IANA流程（请参阅下面的“IANA注意事项”）。处理未知的P-Header将忽略它们，但是，应认真对待第4.1节，P-Header的用户将获得最佳的遵守结果。所有实施的P-Header应满足4.1中的P-Header要求。在非常有限的研究或教学环境（如实施扩展的学生实验室）之外使用的任何P-header必须满足这些要求，并且必须记录在RFC中，并经过IANA注册。当IESG批准互联网草案时，允许IANA注册。
events [4] 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). Normal event packages can be created and registered by the publication of any Working Group RFC (Informational, Standards Track, Experimental), provided that the RFC is a chartered working group item.
events[4]定义了两种不同类型的事件包：普通事件包和事件模板包。事件模板包只能通过发布标准跟踪RFC（来自IETF工作组）来创建和注册。正常事件包可以通过发布任何工作组RFC（信息、标准跟踪、实验）来创建和注册，前提是RFC是特许工作组项目。
Individuals may also wish to publish SIP Event packages. Individual proposals for registration of a SIP event package MUST first be published as Internet-drafts for review by the SIPPING Working Group, or the working group, mailing list, or expert designated by the Transport Area Directors if the SIPPING 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. The author should submit his or her proposal as an individual Internet-Draft, and post an announcement to the working group mailing list to begin discussion. The SIPPING Working Group will determine if the proposed package is a) an inappropriate usage of SIP, b) applicable to SIP but not sufficiently interesting, general, or in-scope to adopt as a working group effort, c) contrary to similar work planned in the Working Group, or d) should be adopted as or merged with chartered work.
个人也可能希望发布SIP事件包。SIP活动包注册的个人提案必须首先作为互联网草稿发布，以供啜饮工作组或工作组、邮件列表或运输区域主管指定的专家（如果啜饮工作组已关闭）审查。提案应包括一个强有力的动机部分，对提议的语法和语义、事件包注意事项、安全注意事项和使用示例的全面描述。提交人应将其提案作为个人互联网草案提交，并向工作组邮寄名单发布公告，开始讨论。啜饮工作组将确定提议的包装是否为a）不适当的SIP使用，b）适用于SIP但不足以作为工作组工作的有趣、一般或范围，c）与工作组中计划的类似工作相反，或d）应作为特许工作采用或与特许工作合并。
The IETF requires (Individual) RFC publication for registration of event packages developed outside the scope of an IETF working group, according to the following guidelines:
根据以下指南，IETF要求（单独）RFC出版物用于注册在IETF工作组范围外开发的事件包：
1. A designated expert (as defined in RFC 2434 [4]) MUST review the proposal for applicability to SIP and conformance with these guidelines. The Expert Reviewer 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 2434[4]中所定义）必须审查提案对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 [4], SIP [3], or related standards track extensions.
4. 事件包不得重新定义或违反SIP事件[4]、SIP[3]或相关标准跟踪扩展的规范行为。
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 5 of SIP events [4].
6. 建议的包必须清楚地记录在（单独的）信息RFC中，并在IANA注册。软件包必须记录SIP事件[4]第5节中要求的所有软件包注意事项。
7. If determined by the expert reviewer or the chairs or ADs of the SIPPING 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。
Complexity and indeterminate or hard to define protocol behavior, depending on which of many extensions operate, 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 and do not worsen SIP's existing security considerations.
所有提出SIP新要求的互联网草案必须包括对提案中固有的安全要求和影响的讨论。所有修改或扩展SIP的RFC必须表明它们具有足够的安全性，并且不会恶化SIP现有的安全考虑。
RFC 3261 [3] 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 headers.
RFC 3261[3]指示互联网分配号码管理局（IANA）建立SIP方法名称注册中心、SIP选项标签注册中心和SIP响应代码注册中心，并修改现有SIP头注册中心的做法。
With the exception of P-headers, entries go into these registries only by approval of an Internet-Draft as a standards track RFC.
除了P-Header之外，条目只有在互联网草案作为标准跟踪RFC获得批准后才能进入这些注册中心。
Each RFC shall include an IANA Considerations section which 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 headers and messages MUST NOT begin with the leading characters "P-".
标准标题和消息不得以前导字符“P-”开头。
"P-" header names MUST begin with the leading characters "P-". No "P-" header which conflicts with (would, without the "P-" prefix have the same name as) an existing standards track header is allowed. Each registration of a "P-" header will also reserve the name of the header as it would appear without the "P-" prefix. However, the reserved name without the "P-" will not explicitly appear in the registry. It will only appear if there is a later standards track document (which is unlikely in most cases!). Please do not accept the registration of IANA-Greeting when you see: P-IANA-Greeting. P-header's "reserved standard names" MUST NOT be used in a SIP implementation prior to standardization of the header.
“P-”标题名称必须以前导字符“P-”开头。不允许存在与现有标准曲目标题冲突的“P-”标题（如果没有“P-”前缀，则与现有标准曲目标题同名）。“P-”标题的每次注册也将保留标题的名称，因为它不带“P-”前缀。但是，没有“P-”的保留名称不会显式显示在注册表中。只有在有更晚的标准跟踪文档（在大多数情况下不太可能！）时才会出现。当您看到：P-IANA-Greeting时，请不要接受IANA问候语的注册。在对报头进行标准化之前，不得在SIP实现中使用P报头的“保留标准名称”。
Short forms of headers MUST only be assigned to standards track headers. In other words, P-headers MUST NOT have short forms.
短格式的标题只能指定给标准曲目标题。换句话说，P-header不能有缩写形式。
Similarly, RFC 3265 [4] directs the IANA to establish a registry for SIP event packages and SIP event template packages. For event template packages, entries go into this registry only by approval of a draft for standards track RFC. For ordinary event packages, entries go into this registry only by approval of a draft for RFC (of any type). In either case, the IESG announcement of approval authorizes IANA to make the registration.
类似地，RFC 3265[4]指示IANA为SIP事件包和SIP事件模板包建立注册表。对于事件模板包，只有在批准标准跟踪RFC草案后，条目才会进入此注册表。对于普通事件包，只有在批准RFC（任何类型）草案后，条目才会进入此注册表。无论哪种情况，IESG的批准公告都授权IANA进行注册。
The Transport ADs thank our 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; Jonathan Rosenberg and Jon Peterson gave us useful reviews. Thanks also to Henning Schulzrinne and William Marshall.
交通广告感谢我们的IESG和IAB同事（特别是Randy Bush、Harald Alvestrand、John Klesins、Leslie Daigle、Patrik Faltstrom和Ned Freed）就广泛协议中的可扩展性问题进行了有价值的讨论，包括我们地区提出的协议和其他协议。感谢SIP社区的许多成员就本文件进行了有趣的对话；乔纳森·罗森博格和乔恩·彼得森给了我们有用的评论。还要感谢亨宁·舒尔兹林内和威廉·马歇尔。
[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] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[3] 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.
[3] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[4] Roach, A., "Session Initiation Protocol (SIP) - Specific Event Notification", RFC 3265, June 2002.
[4] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
Allison Mankin Bell Labs, Lucent Corporation
朗讯公司Allison Mankin Bell实验室
EMail: mankin@psg.com
EMail: mankin@psg.com
Scott Bradner Harvard University
斯科特·布拉德纳哈佛大学
EMail: sob@harvard.edu
EMail: sob@harvard.edu
Rohan Mahy Cisco
Rohan Mahy Cisco
EMail: rohan@cisco.com
EMail: rohan@cisco.com
Dean Willis dynamicsoft
迪安·威利斯动力软件公司
EMail: dean.willis@softarmor.com
EMail: dean.willis@softarmor.com
Brian Rosen Marconi
布莱恩·罗森·马可尼
EMail: brian.rosen@marconi.com
EMail: brian.rosen@marconi.com
Joerg Ott ipDialog / Uni Bremen TZI
Joerg Ott ipDialog/不来梅大学TZI
EMail: jo@ipdialog.com
EMail: jo@ipdialog.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。