Change Process for the Session Initiation Protocol (SIP)
RFC 3427
| Document | Type |
RFC - Best Current Practice
(December 2002; No errata)
Obsoleted by RFC 5727
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | Legacy | ||
| Formats | plain text pdf html 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
Show full document text