Network Working Group                                        J. Peterson
Internet-Draft                                                   NeuStar
Intended status: Best Current                                C. Jennings
Practice                                                   Cisco Systems
Expires: August 18, 2008                               February 15, 2008

        Change Process for the Session Initiation Protocol (SIP)

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 18, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   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 RAI Area directors, along with the SIP and
   Session Initiation Proposal Investigation (SIPPING) working group

Peterson & Jennings      Expires August 18, 2008                [Page 1]

Internet-Draft                 RFC3427bis                  February 2008

   chairs, have provided suggestions for SIP modifications and

Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  History and Development  . . . . . . . . . . . . . . . . . . .  3
     2.1.  The IETF SIP Working group . . . . . . . . . . . . . . . .  3
     2.2.  The IETF SIPPING Working Group . . . . . . . . . . . . . .  4
   3.  The SIP Change Process . . . . . . . . . . . . . . . . . . . .  4
   4.  Extensibility and Architecture . . . . . . . . . . . . . . . .  6
     4.1.  Indicating a P- Header . . . . . . . . . . . . . . . . . .  6
     4.2.  Preventing Identity Conflicts Between P-Extensions . . . .  8
     4.3.  SIP Event Packages . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Clarification of RFC3969 . . . . . . . . . . . . . . . . . 10
   7.  Changes from RFC3427 . . . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Informational References . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Peterson & Jennings      Expires August 18, 2008                [Page 2]

Internet-Draft                 RFC3427bis                  February 2008

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].
   This document additionally uses RFC2434bis language to describe IANA

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.

   This document updates [7].

2.1.  The IETF SIP Working group

   The IETF SIP Working Group (sip) 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 RAI 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

Peterson & Jennings      Expires August 18, 2008                [Page 3]

Internet-Draft                 RFC3427bis                  February 2008

   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
   [6], but the working group must have charter approval to do so.  The
   IETF will also require RFC2434bis IETF Review for the registration of
   event packages developed outside the scope of an IETF working group.
   The template for event package registrations is provided in
   Section 4.3.

2.2.  The IETF SIPPING Working Group

   The IETF Session Initiation Protocol Proposal Investigation (sipping)
   Working Group is chartered to be a filter in front of the SIP Working
   Group.  This working group will investigate requirements for
   applications of SIP, some of which may lead to requests for
   extensions to SIP.  These requirements may come from the community at
   large, or from individuals who are reporting the requirements as
   determined by another standards body.  The SIPPING Working Group will
   also not live forever, with similar consideration to the sections

   The SIPPING Working Group may determine: that these requirements can
   be satisfied by SIP without modifications, that the requirements are
   not sufficiently general to warrant a change to SIP, that the
   requirements justify a change to SIP, or that the requirements should
   be combined with other requirements to solve a more general problem
   or solve the same problem in a more flexible way.

   Because the SIP protocol gets so much attention, some application
   designers may want to use it just because it is there, such as for
   controlling household appliances.  SIPPING should act as a filter,
   accepting only requirements which play to the best strengths of SIP,
   such as realtime presence.

   When the SIPPING working group decides on a set of requirements, it
   forwards them to the SIP working group.  The SIPPING Working Group
   may also document usage or applications of SIP which do not require
   any protocol extensions.

   The SIPPING working group also acts as a filter for proposed event
   packages as described in Section 4.3.

3.  The SIP Change Process

   Anyone who thinks that the existing SIP protocol is applicable to
   their application, yet not sufficient for their task must write an

Peterson & Jennings      Expires August 18, 2008                [Page 4]

Internet-Draft                 RFC3427bis                  February 2008

   individual Internet-Draft explaining the problem they are trying to
   solve, why SIP is the applicable protocol, and why the existing SIP
   protocol will not work.  The Internet-Draft must include a detailed
   set of requirements (distinct from solutions) that SIP would need to
   meet to solve the particular problem.  The Internet-Draft must also
   describe in detail any security issues that arise from meeting those
   requirements.  After the Internet-Draft is published, the authors
   should send a note to the SIPPING Working Group mailing list to start
   discussion on the Internet-Draft.

   The SIPPING working group chairs, in conjunction with the RAI 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

   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

   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 RAI 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.

Peterson & Jennings      Expires August 18, 2008                [Page 5]

Internet-Draft                 RFC3427bis                  February 2008

   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), Basic Level of Interoperability for
   SIP Services (bliss) and Session Peering for Multimedia Interconnect

4.  Extensibility and Architecture

   In an idealized protocol model, extensible design would be self-
   contained, and it would be inherent that new extensions and new
   headers would naturally have an architectural coherence with the
   original protocol.

   However, this idealized vision has not been attained in the world of
   standards track protocols.  While, interoperability implications can
   be addressed by capabilities negotiation rules, the effects of adding
   features that overlap, or that deal with a point solution and are
   not, are much harder to control with rules.  Therefore, the RAI Area
   calls for architectural guardianship and application of Occam's Razor
   by the SIP Working Group.

   In keeping with the IETF tradition of "running code and rough
   consensus", it is valid to allow for the development of SIP
   extensions that are either not ready for standards track, but might
   be understood for that role after some running code, or are private
   or proprietary in nature, because a characteristic motivating them is
   usage that is known not to fit the Internet architecture for SIP.  We
   call these "P-" headers, for "preliminary", "private", or

   There are two key issues to consider with respect to keeping the "P-"
   header extension space "safe":
   1.  Clearly indicating the unarchitected or not-yet understood nature
       of the extension.
   2.  Preventing identity conflicts between extensions.

4.1.  Indicating a P- Header

   Use of an "X-" prefix on textual identifiers has been widely used to
   indicate experimental extensions in other protocols.  This approach

Peterson & Jennings      Expires August 18, 2008                [Page 6]

Internet-Draft                 RFC3427bis                  February 2008

   is applied in modified form here by use of a "P-" header extension.
   However, there are a number of stronger constraints for "P-" headers,
   including documentation that get Expert and IESG review, and other
   SIP protocol criteria described below.

   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 2434bis [5]) MUST review
       the proposal for applicability to SIP and conformance to these
       guidelines.  The Designated Expert will send email to the RAI
       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 registration process for proposed headers is "RFC Required"
       per RFC2434bis.
   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

Peterson & Jennings      Expires August 18, 2008                [Page 7]

Internet-Draft                 RFC3427bis                  February 2008

   normative behavior.

4.2.  Preventing Identity Conflicts Between P-Extensions

   In order to prevent identity conflicts between P-headers, this
   document provides an IANA process (See: Section 6 below) to register
   the P-headers.  The handling of unknown P-headers is to ignore them,
   however, Section 4.1 is to be taken seriously, and users of P-headers
   will have best results with adherence.  All implemented P-headers
   SHOULD meet the P-Header requirements in Section 4.1.  Any P-header
   used outside of a very restricted research or teaching environment
   (such as a student lab on implementing extensions) MUST meet those
   requirements and MUST be documented in an RFC and be IANA registered
   (i.e.  RFC2434bis RFC Required).  IANA registration is permitted when
   the IESG approves the internet- draft.

4.3.  SIP Event Packages

   SIP events [6] 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.  Note that the guidance in RFC3265
   states that the IANA registration policy for normal event packages is
   "First Come First Serve"; this document replaces that policy with the

   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 RAI
   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

   RFC2434bis "RFC Required" is the procedure for registration of event
   packages developed outside the scope of an IETF working group,

Peterson & Jennings      Expires August 18, 2008                [Page 8]

Internet-Draft                 RFC3427bis                  February 2008

   according to the following guidelines:
   1.  A Designated Expert (as defined in RFC 2434bis [5]) MUST review
       the proposal for applicability to SIP and conformance with these
       guidelines.  The Designated Expert 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 [6], SIP [3], or related standards track
   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 [6].
   7.  If determined by the Designated Expert 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.

5.  Security Considerations

   Complexity and indeterminate or hard to define protocol behavior,
   depending on which of many extensions operate, is a fine breeding
   ground for security flaws.

   All Internet-Drafts that present new requirements for SIP must
   include a discussion of the security requirements and implications
   inherent in the proposal.  All RFCs that modify or extend SIP must
   show that they have adequate security and do not worsen SIP's
   existing security considerations.

6.  IANA Considerations

   RFC 3261 [3] 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.
   Reiterating the guidance of RFC3261, method names, option tags and

Peterson & Jennings      Expires August 18, 2008                [Page 9]

Internet-Draft                 RFC3427bis                  February 2008

   SIP response codes require a Standards Action for inclusion in the
   IANA registry.

   With the exception of P-headers, entries go into these registries
   only through RFC2434bis Standards Action.

   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 [6] directs the IANA to establish a registry for
   SIP event packages and SIP event template packages.  For event
   template packages, registrations must follow the RFC2434bis processes
   for Standards Action.  For ordinary event packages, as stated
   previously registrations require RFC2434bis IETF Review.  In either
   case, the IESG announcement of approval authorizes IANA to make the

6.1.  Clarification of RFC3969

   RFC3969 [4] stipulates that the (original) RFC2434 rule of
   "Specification Required" applies to registrations of new SIP URI
   parameters; however Section 3 of that same document mandates that a
   standards action is required to register new parameters with the
   IANA.  This contradiction arose from a misunderstanding of the nature
   of the RFC2434 categories; the intention was for the IANA
   Considerations to mandate that Standards Action is required.

Peterson & Jennings      Expires August 18, 2008               [Page 10]

Internet-Draft                 RFC3427bis                  February 2008

7.  Changes from RFC3427
      References to the Transport Areas have been changed to point to
      the RAI ADs.
      Rewrote IANA registry requirements in terms of RFC2434bis.
      Updated list of working groups at the end of Section 3.
      Clarified that the original RFC3427 altered the IANA registration
      policy of RFC3265.
      Clarified the IANA registration policy in 3969.

8.  Acknowledgments

   The credit for this work belongs to the original authors: Allison
   Mankin, Scott Bradner, Rohan Mahy, Dean Willis, Joerg Ott, and Brian
   Rosen.  The current editors have provided only an incremental update
   to reflect changes to the structure of the IETF and the IANA
   registration procedures.

   The original authors thanked their IESG and IAB colleagues
   (especially Randy Bush, Harald Alvestrand, John Klensin, Leslie
   Daigle, Patrik Faltstrom, and Ned Freed) for valuable discussions of
   extensibility issues in a wide range of protocols, including those
   that our area brings forward and others.  Thanks to the many members
   of the SIP community engaged in interesting dialogue about this
   document as well; including and especially Jonathan Rosenberg,
   Henning Schulzrinne and William Marshall.

9.  Informational References

   [1]  Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", RFC 2119, March 1997.

   [2]  Bradner, S., "The Internet Standards Process -- Revision 3",
        RFC 2026, October 1996.

   [3]  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.

   [4]  Camarillo, G., "The Internet Assigned Number Authority (IANA)
        Uniform Resource Identifier (URI) Parameter Registry for the
        Session Initiation Protocol (SIP)", RFC 3969, December 2004.

   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs",
        draft-narten-iana-considerations-08 (work in progress),
        October 2007.

Peterson & Jennings      Expires August 18, 2008               [Page 11]

Internet-Draft                 RFC3427bis                  February 2008

   [6]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [7]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
        Rosen, "Change Process for the Session Initiation Protocol
        (SIP)", RFC 3427, December 2002.

Authors' Addresses

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520

   Phone: +1 925/363-8720

   Cullen Jennings
   Cisco Systems
   170 West Tasman Drive
   MS: SJC-21/2
   San Jose, CA  95134

   Phone: +1 408 902-3341

Peterson & Jennings      Expires August 18, 2008               [Page 12]

Internet-Draft                 RFC3427bis                  February 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Peterson & Jennings      Expires August 18, 2008               [Page 13]