RFC 3427 (rfc3427) - Page 2 of 12

Change Process for the Session Initiation Protocol (SIP)

Alternative Format: Original Text Document
< Previous
Next >
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
< Previous
Next >