doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc3427.txt b/doc/rfc/rfc3427.txt
new file mode 100644
index 0000000..a87fb5b
--- /dev/null
+++ b/doc/rfc/rfc3427.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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]
+