[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 3427

Transport Area                                                S. Bradner
Internet-Draft                                        Harvard University
Expires: November 25, 2002                                     A. Mankin
                                                                 USC/ISI
                                                                 R. Mahy
                                                                   Cisco
                                                               D. Willis
                                                             dynamicsoft
                                                                B. Rosen
                                                                 Marconi
                                                                  J. Ott
                                                                IPDialog
                                                            May 27, 2002


        Change Process for the Session Initiation Protocol (SIP)
                     draft-tsvarea-sipchange-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

   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 http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 25, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The IETF's Session Initiation Protocol (SIP, RFC 3261), is becoming
   popular for a growing number of applications.  One result of this



Bradner, et al.         Expires November 25, 2002               [Page 1]

Internet-Draft             SIP Change Process                   May 2002


   popularity is a continuous flood of suggestions for SIP modifications
   and extensions.  This memo describes how the Transport Area directors
   along with the SIP and SIPPING working group chairs have decided to
   deal with such suggestions.   The effects of adding new features,
   often in a case where a point solution is sought, can be to damage
   security or to greatly increase complexity.  Therefore this memo
   documents a process intended to apply architectural discipline to the
   future development of SIP.

1. Development of SIP

   The IETF Session Initiation Protocol (sip) Working Group is chartered
   to be the "owner" of the SIP protocol [1].  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.  It 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 reponse 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, from requirements provided by the
   SIPPING Working Group.

   SIP event packages [3] are appropriate to develop in the Working
   Groups that use them, but they will need charter approval to create a
   SIP event package as a working group effort.  The IETF will also
   require (Individual) RFC publication for 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.

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
   determined by another standards body.

   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, that the requirements should be
   combined with other requirements to solve a more general problem, or



Bradner, et al.         Expires November 25, 2002               [Page 2]

Internet-Draft             SIP Change Process                   May 2002


   to 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
   detailing cars using the new SIP BRUSH method.  SIPPING should act as
   a filter, accepting only requirements which are applicable to SIP.

   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. 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
   individual ID 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 the
   requirements.  After this 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 Transport
   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 merge with other
   requirements from other or related applications, and refine the ID
   accordingly.

   If the chairs and the ADs both feel that the particular new problems
   should be added to the SIPPING Working Group charter, 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
   Internet-Draft.

   In a separate Internet-Draft, the authors may describe a set of
   changes to SIP that would meet the requirements.  This Internet-Draft
   would be passed on to the SIP working group for consideration (if



Bradner, et al.         Expires November 25, 2002               [Page 3]

Internet-Draft             SIP Change Process                   May 2002


   warranted).  There is no requirement on the SIP working group that
   the proposed solution from this additional ID be adopted.

   The SIPPING working group may also evaluate such proposals for
   extensions if the requirements are judged to be appropriate to SIP,
   but the requirements 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 Transport ADs may, on a case by case basis, support a process in
   which the requirements analysis is implicit and the SIP working group
   requests 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 (with the exception of P- headers as described in Section
   4.1) come only from the SIP Working Group, and only from the IETF, as
   the body that created SIP.  The IETF will not publish a SIP extension
   RFC outside of the process described here.

   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 - they also 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 of writing, these
   include SIP for Instant Messaging and Presence Leveraging Extensions
   (simple), Service in the PSTN/IN Requesting InTernet Service
   (spirits), and Telephone Number Mapping (enum).

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 tracks 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
   general are much harder to control with rules.  Therefore the
   Transport Area calls for architectural guardianship and application
   of Occam's Razor by the SIP Working Group.




Bradner, et al.         Expires November 25, 2002               [Page 4]

Internet-Draft             SIP Change Process                   May 2002


   We encourage other protocol working groups with highly extensible
   protocols to review whether they need more coordination of extensions
   (including restricting them to IETF) as in the SIP case.

   In keeping with the IETF tradition of "running code and rough
   consensus", it is valid to allow for 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
   "proprietary".

   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 identfiers has been widely used to
   indicate experimental extensions in other protocols, and this
   approach is applied in modified form here by use of a "P-" header
   extension.

   Informational SIP Headers can be registered as "P-" headers if all of
   the following conditions are met:

   1.  A designated expert (as defined in RFC2434 [2]) MUST review the
       proposal for applicability to SIP and conformance to these
       guidelines.  The Expert Reviewer will send email to the Transport
       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 purely an informational nature,
       and MUST NOT significantly change the behavior of SIP entities
       which support it.  Headers which merely provide additional



Bradner, et al.         Expires November 25, 2002               [Page 5]

Internet-Draft             SIP Change Process                   May 2002


       information pertinent to a request or a response are acceptable.
       If the headers redefine or contradict normative behavior defined
       in bis or other standards track documents then the behavior is
       significantly different.

   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 proposed header MUST be clearly documented in an (Individual
       or Working Group) Informational RFC, and registered with IANA.

   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
   specififcations.  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 normative behavior.

4.2 Preventing Identity Conflicts Between P-Extensions:

   In order to prevent identity conflicts between P-extensions, this
   document provides an IANA process (See: "IANA Considerations" below)
   to allow for the registration of private or experimental extension
   headers.  All implemented extension headers SHOULD meet the P-Header
   requirements in 4.1, and any extension 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.

4.3 SIP Event Packages

   SIP events defines two different types of event pacakges: normal
   event packages, and event template-packages.  Event template-packages



Bradner, et al.         Expires November 25, 2002               [Page 6]

Internet-Draft             SIP Change Process                   May 2002


   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.

   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.
   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
   charted work.

   The IETF requires (Individual) RFC publication for registration of
   event packages developed outside the scope of an IETF working group,
   according to the following guidelines:

   1.  A designated expert (as defined in RFC2434 [2]) MUST review the
       proposal for applicability to SIP and conformance to these
       guidelines.  The Expert Reviewer will send email to the IESG 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 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 [3], SIP [1], or related standards track
       extensions.

   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



Bradner, et al.         Expires November 25, 2002               [Page 7]

Internet-Draft             SIP Change Process                   May 2002


       package MUST document all the package considerations required in
       Section 5 of SIP events [3]

   7.  If necessary as determined by the expert reviewer 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 [1] directs the Internet Assigned Numbers Authority 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.

   With the exception of P-headers, entries go into these registries
   only by approval of a draft for standards track RFC (the IESG
   announcement of approval authorizes IANA to make the registration).
   For P-headers this requirement is relaxed to allow registration when
   any RFC is approved by the IESG (non-standards track).

   Each RFC shall include an IANA Considerations section which directs
   IANA to create appropriate registrations.  Standard headers and
   messages MUST NOT begin with the leading characters "P-".

   "P-" header names MUST being 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.  These "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



Bradner, et al.         Expires November 25, 2002               [Page 8]

Internet-Draft             SIP Change Process                   May 2002


   headers.

7. Acknowledgements

   The Transport ADs thank our IESG and IAB colleagues (especially Randy
   Bush, Harald Alvestrand and John Klensin) for valuable discussions of
   extensibility issues in a wide range of protocols, including those
   that our area brings forward and others, and many members of the SIP
   community at IETF for dialogue on these issues for SIP.

Normative References

   [1]  Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation
        Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),
        February 2002.

   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [3]  Roach, A., "SIP-Specific Event Notification", draft-ietf-sip-
        events-05 (work in progress), March 2002.


Authors' Addresses

   Scott Bradner
   Harvard University

   EMail: sob@harvard.edu


   Allison Mankin
   USC/ISI

   EMail: mankin@isi.edu


   Rohan Mahy
   Cisco

   EMail: rohan@cisco.com


   Dean Willis
   dynamicsoft

   EMail: dean.willis@softarmor.com




Bradner, et al.         Expires November 25, 2002               [Page 9]

Internet-Draft             SIP Change Process                   May 2002


   Brian Rosen
   Marconi

   EMail: brian.rosen@marconi.com


   Joerg Ott
   IPDialog

   EMail: jo@ipdialog.com









































Bradner, et al.         Expires November 25, 2002              [Page 10]

Internet-Draft             SIP Change Process                   May 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Bradner, et al.         Expires November 25, 2002              [Page 11]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/