Change Process for the Session Initiation Protocol (SIP)
RFC 3427
Document | Type |
RFC - Best Current Practice
(December 2002; No errata)
Obsoleted by RFC 5727
Was draft-tsvarea-sipchange (tsv)
|
|
---|---|---|---|
Authors | Rohan Mahy , Joerg Ott , Dean Willis , Allison Mankin , Brian Rosen , Scott Bradner | ||
Last updated | 2020-02-26 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 3427 (Best Current Practice) | |
Telechat date | |||
Responsible AD | Harald Alvestrand | ||
IESG note | Responsible: RFC Editor | ||
Send notices to | (None) |
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. 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. 1. Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in Keywords [1]. Mankin, et. al. Best Current Practice [Page 1] RFC 3427 Change Process for SIP December 2002 2. History and Development 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. 2.1 The IETF SIP Working Group 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. 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 [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. 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. Mankin, et. al. Best Current Practice [Page 2] RFC 3427 Change Process for SIP December 2002 2.2 The IETF SIPPING Working Group The IETF Session Initiation Protocol Proposal Investigation (sipping)Show full document text