GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3427

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)
 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 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 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
 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 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 in RFC 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 compliant

Mankin, 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 in RFC 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 in
     Section 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 2002

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

7. 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", BCP
      9, 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 2002

9. 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.com

Mankin, et. al. Best Current Practice [Page 11] RFC 3427 Change Process for SIP December 2002

10. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3427.txt · Last modified: 2002/12/09 19:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki