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) 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.
AbstractThis 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. 1].
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. 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. 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. 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 ) 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. It is appropriate for any working group to develop SIP event packages , 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.
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. 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. 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. 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. 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. 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. 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.
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).
Informational SIP Headers can be registered as "P-" headers if all of the following conditions are met: 1. A designated expert (as defined in RFC 2434 ) 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. 2. The proposed extension MUST NOT define SIP option tags, response codes, or methods. 3. The function of the proposed header MUST NOT overlap with current or planned chartered extensions. 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. 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). 6. The proposed header MUST be clearly documented in an (Individual or Working Group) Informational RFC, and registered with 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. 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
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. 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. 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.
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: 1. A designated expert (as defined in RFC 2434 ) 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. 2. The proposed extension MUST NOT define an event template-package. 3. The function of the proposed package MUST NOT overlap with current or planned chartered packages. 4. The event package MUST NOT redefine or contradict the normative behavior of SIP events , SIP , or related standards track extensions. 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). 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 . 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.
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 headers. With the exception of P-headers, entries go into these registries only by approval of an Internet-Draft as a standards track 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. Standard headers and messages MUST NOT begin with the leading characters "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. Short forms of headers MUST only be assigned to standards track headers. In other words, P-headers MUST NOT have short forms. Similarly, RFC 3265  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.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.  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.  Roach, A., "Session Initiation Protocol (SIP) - Specific Event Notification", RFC 3265, June 2002.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.