Movatterモバイル変換

Network Working Group                                          A. MankinRequest for Comments: 3427                 Bell Labs, Lucent CorporationBCP: 67                                                       S. BradnerCategory: Best Current Practice                       Harvard University                                                                 R. Mahy                                                                   Cisco                                                               D. Willis                                                             dynamicsoft                                                                  J. Ott                                               ipDialog / Uni Bremen TZI                                                                B. Rosen                                                                 Marconi                                                           December 2002Change 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 20022. 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 inSection 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 insection6.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 inSection 4.3.Mankin, et. al.          Best Current Practice                  [Page 2]

RFC 3427                 Change Process for SIP            December 20022.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   above.   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 inSection 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 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.Mankin, et. al.          Best Current Practice                  [Page 3]

RFC 3427                 Change Process for SIP            December 2002   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 can be merged with   other requirements from other 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, 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   Internet-Draft.   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   inSection 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 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.   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.Mankin, et. al.          Best Current Practice                  [Page 4]

RFC 3427                 Change Process for SIP            December 2002   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), 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 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   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.   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   "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 identifiers has been widely used to   indicate experimental extensions in other protocols.  This approach   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.Mankin, et. al.          Best Current Practice                  [Page 5]

RFC 3427                 Change Process for SIP            December 2002   Informational SIP Headers can be registered as "P-" headers if all of   the following conditions are met:   1.  A designated expert (as defined inRFC 2434 [4]) 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 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 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   specifications.  Specifically, implementations are only SIP compliantMankin, et. al.          Best Current Practice                  [Page 6]

RFC 3427                 Change Process for SIP            December 2002   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-headers, this   document provides an IANA process (See: "IANA Considerations" 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 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.   IANA registration is permitted when the IESG approves the internet-   draft.4.3 SIP Event Packages   events [4] 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.   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   Transport 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 work.Mankin, et. al.          Best Current Practice                  [Page 7]

RFC 3427                 Change Process for SIP            December 2002   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 inRFC 2434 [4]) MUST review the       proposal for applicability to SIP and conformance with 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 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 [4], SIP [3], 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       package MUST document all the package considerations required inSection 5 of SIP events [4].   7.  If 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.Mankin, et. al.          Best Current Practice                  [Page 8]

RFC 3427                 Change Process for SIP            December 20026. IANA ConsiderationsRFC 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.   With the exception of P-headers, entries go into these registries   only by approval of an Internet-Draft as a standards track RFC.   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 [4] directs the IANA to establish a registry for   SIP event packages and SIP event template packages.  For event   template packages, entries go into this registry only by approval of   a draft for standards track RFC.  For ordinary event packages,   entries go into this registry only by approval of a draft for RFC (of   any type).  In either case, the IESG announcement of approval   authorizes IANA to make the registration.Mankin, et. al.          Best Current Practice                  [Page 9]

RFC 3427                 Change Process for SIP            December 20027. Acknowledgements   The Transport ADs thank our 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; Jonathan Rosenberg and Jon Peterson gave us useful reviews.   Thanks also to Henning Schulzrinne and William Marshall.8. Normative References   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement        Levels",BCP 14,RFC 2119, March 1997.   [2]  Bradner, S., "The Internet Standards Process -- Revision 3",BCP9,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]  Roach, A., "Session Initiation Protocol (SIP) - Specific Event        Notification",RFC 3265, June 2002.Mankin, et. al.          Best Current Practice                 [Page 10]

RFC 3427                 Change Process for SIP            December 20029. Authors' Addresses   Allison Mankin   Bell Labs, Lucent Corporation   EMail: mankin@psg.com   Scott Bradner   Harvard University   EMail: sob@harvard.edu   Rohan Mahy   Cisco   EMail: rohan@cisco.com   Dean Willis   dynamicsoft   EMail: dean.willis@softarmor.com   Brian Rosen   Marconi   EMail: brian.rosen@marconi.com   Joerg Ott   ipDialog / Uni Bremen TZI   EMail: jo@ipdialog.comMankin, et. al.          Best Current Practice                 [Page 11]

RFC 3427                 Change Process for SIP            December 200210.  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.Mankin, et. al.          Best Current Practice                 [Page 12]