Change Process for the Session Initiation Protocol (SIP)
RFC 3427

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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)