Network Working Group Scott Bradner Internet-Draft Harvard University Rohan Mahy Cisco Allison Mankin USC/ISI Joerg Ott IPDialog Brian Rosen Marconi Dean Willis Dynamicsoft November 2001 SIP Change Process 1. Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC 2026. 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 Copyright (C) The Internet Society (2001). All Rights Reserved. 2. Abstract The IETF's Session Initiation Protocol (SIP) [RFC 2543] is becoming quite popular for a growing number of applications. One result of this 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. 3. The IETF SIP Working Group The IETF Session Initiation Protocol (sip) Working Group is chartered to be the "owner" of the SIP protocol. All changes or extensions to Transport ADs and SIP* Chairs [Page 1] Internet-Draft SIP Change Process November 2001 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 and new SIP headers. SIP extensions must be standards track and must be developed in the IETF, from requirements provided by the SIPPING Working Group. The process for SIP packages will be addressed case-by-case until there is more standards experience with this format. 4. The IETF SIPPING Working Group The IETF Session Initiation Protocol Proposal INvestiGation (sipping) Working Group is chartered to be a much needed filter in front of the SIP Working Group. This working group is to investigate requirements for applications of SIP, some of which may lead to requests for extensions to SIP. These requirements may come from individuals who are reporting the requirements determined by another standards body. In some cases the requirements can be met by SIP as it exists, in other cases the requirement will not be seen by the SIPPING working group as general enough to warrant a change to SIP, and in some cases multiple requirements may be combined into a single set. SIPPING should also act as a filter to the applicability of SIP. Because the 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. When the SIPPING working group decides on a set of requirements, it forwards them to the SIP working group. 5. SIP Change Process Anyone who thinks that the existing SIP protocol will not do 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 Internet-Draft warrants being added to the SIPPING charter based on the mailing list discussion. The SIPPING working group should Transport ADs and SIP* Chairs [Page 2] Internet-Draft SIP Change Process November 2001 consider whether the requirements merge with others 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 for SIP working group consideration (if warranted). There is no requirement on the SIP working group that the solution idea of this additional ID be adopted. With respect to standardization, this process means that SIP extensions 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 some function more efficient at the expense of simplicity or generality. 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 (simple) and Service in the PSTN/IN Requesting InTernet Service (spirits). 6. Extensibility and Architecture In an idealized technical design, the extensibility 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. Implications for interopability 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 this architectural guardianship and application of Occam's Razor by a Working Group. Transport ADs and SIP* Chairs [Page 3] Internet-Draft SIP Change Process November 2001 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. 7. 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 explore the security considerations of the modifications and extensions. 8. References [RFC 2543] " SIP: Session Initiation Protocol.", M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, RFC 2543, March 1999 9. Author's Addresses Scott Bradner Email: sob@harvard.edu Rohan Mahy Email: rohan@cisco.com Allison Mankin Email: mankin@isi.edu Joerg Ott Email: jo@ipdialog.com Brian Rosen Email: brian.rosen@marconi.com Dean Willis Email: dean.willis@softarmor.com 10. Acknowledgements The Transport ADs thank our IESG and IAB colleagues 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. Transport ADs and SIP* Chairs [Page 4] Internet-Draft SIP Change Process November 2001 10. Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Transport ADs and SIP* Chairs [Page 5]