doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5727.txt b/doc/rfc/rfc5727.txt
new file mode 100644
index 0000000..b2b21a1
--- /dev/null
+++ b/doc/rfc/rfc5727.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       J. Peterson
+Request for Comments: 5727                                 NeuStar, Inc.
+BCP: 67                                                      C. Jennings
+Obsoletes: 3427                                            Cisco Systems
+Updates: 3265, 3969                                            R. Sparks
+Category: Best Current Practice                                  Tekelec
+ISSN: 2070-1721                                               March 2010
+
+
+        Change Process for the Session Initiation Protocol (SIP)
+         and the Real-time Applications and Infrastructure Area
+
+Abstract
+
+   This memo documents a process intended to organize the future
+   development of the Session Initiation Protocol (SIP) and related work
+   in the Real-time Applications and Infrastructure (RAI) Area.  As the
+   environments in which SIP is deployed grow more numerous and diverse,
+   modifying or extending SIP in certain ways may threaten the
+   interoperability and security of the protocol; however, the IETF
+   process must also cater to the realities of existing deployments and
+   serve the needs of the implementers working with SIP.  This document
+   therefore defines the functions of two long-lived working groups in
+   the RAI Area that are, respectively, responsible for the maintenance
+   of the core SIP specifications and the development of new efforts to
+   extend and apply work in this space.  This document obsoletes RFC
+   3427.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5727.
+
+
+
+
+
+
+
+
+
+
+Peterson, et al.          Best Current Practice                 [Page 1]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  History and Development  . . . . . . . . . . . . . . . . . . .  3
+     1.1.  The IETF SIPCORE Working Group . . . . . . . . . . . . . .  3
+     1.2.  The IETF DISPATCH Working Group  . . . . . . . . . . . . .  4
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Introducing New Work to RAI  . . . . . . . . . . . . . . . . .  6
+   4.  Extensibility and Architecture . . . . . . . . . . . . . . . .  7
+     4.1.  SIP Event Packages . . . . . . . . . . . . . . . . . . . .  9
+   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
+     7.1.  Clarification of RFC 3969  . . . . . . . . . . . . . . . . 12
+   8.  Overview of Changes to RFC 3427  . . . . . . . . . . . . . . . 12
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+Peterson, et al.          Best Current Practice                 [Page 2]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+1.  History and Development
+
+   The Session Initiation Protocol (SIP) [RFC3261] has grown well beyond
+   its origins in Internet-based multimedia sessions and now enjoys
+   widespread popularity in Voice-over-IP or IP telephony applications,
+   both inside IETF and within other standards groups.  One result of
+   this popularity has been a continual flood of proposals for SIP
+   modifications and extensions.  The challenge for IETF management of
+   SIP has been to preserve baseline interoperability across its many
+   implementations
+
+   In order to defend SIP against changes that might reduce
+   interoperability, the working group chairs and Area Directors
+   responsible for its management authored the SIP change process
+   [RFC3427].  That document defined the role of the SIP and SIPPING
+   Working Groups (WGs) in shepherding ongoing work on the SIP standard.
+   It also defined ways that external working groups or bodies can
+   define extensions intended for limited usage, especially through the
+   "P-" header field mechanism.
+
+   Over time, however, the management structure of RFC 3427 has
+   demonstrated some limitations.  The first and most significant of
+   these concerns "P-" header fields.  While "P-" header fields require
+   expert review and IESG shepherding, in practice IETF oversight of
+   these header fields is quite limited, and the value added by the IETF
+   supervising their development remains unclear.  More importantly, the
+   presence of a "P-" in front of a header field name does nothing to
+   prevent a popular header field from seeing deployment outside of the
+   original "limited usage" it envisioned; a prominent example of this
+   today is the P-Asserted-Identity (PAID) header field, described in
+   RFC3325 [RFC3325].
+
+   Consequently, this document obsoletes RFC 3427 and describes a new
+   structure for the management of deliverables in the Real-time
+   Applications and Infrastructure Area.
+
+1.1.  The IETF SIPCORE Working Group
+
+   Historically, the IETF SIP Working Group (sip) was chartered to be
+   the "owner" of the SIP protocol [RFC3261] for the duration of the
+   working group.  All changes or extensions to SIP were first required
+   to exist as SIP Working Group documents.  The SIP Working Group was
+   charged with being the guardian of the SIP protocol for the Internet,
+   and therefore was mandated only to extend or change the SIP protocol
+   when there were compelling reasons to do so.
+
+
+
+
+
+
+Peterson, et al.          Best Current Practice                 [Page 3]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+   The SIPCORE Working Group replaces the function of the SIP Working
+   Group in the original [RFC3427] account.  Documents that must be
+   handled by the SIPCORE Working Group include all documents that
+   update or obsolete RFCs 3261 through 3265 or their successors.  All
+   SIP extensions considered in SIPCORE must be Standards Track.  They
+   may be based upon requirements developed externally in other IETF
+   working groups.
+
+   Typical IETF working groups do not live forever; however, SIPCORE's
+   charter is open-ended in order to allow it to remain the place where
+   core SIP development will continue.  In the event that the SIPCORE
+   Working Group has closed and no suitable replacement or follow-on
+   working group is active (and this specification also has not been
+   superseded), then when modifications to the core SIP protocol are
+   proposed, the RAI Area Directors will use the non-working-group
+   Standards Track document process (described in Section 6.1.2 of RFC
+   2026 [RFC2026]) using the SIPCORE mailing list and Designated Experts
+   from the SIP community for review.
+
+   It is appropriate for any IETF working group to develop SIP event
+   packages [RFC3265], but the working group must have charter approval
+   to do so.  The IETF will also require [RFC5226] IETF Review for the
+   registration of event packages developed outside the scope of an IETF
+   working group.  Instructions for event package registrations are
+   provided in Section 4.1.
+
+1.2.  The IETF DISPATCH Working Group
+
+   Historically, the IETF Session Initiation Protocol Proposal
+   Investigation (sipping) Working Group was chartered to be a filter in
+   front of the SIP Working Group.  This working group investigated
+   requirements for applications of SIP, some of which led 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 DISPATCH Working Group replaces the function of the SIPPING WG,
+   although with several important changes to its functionality -- the
+   most notable being that its scope expands beyond just SIP to the
+   entire work of the RAI Area.  Like SIPPING, DISPATCH considers new
+   proposals for work in the RAI Area, but rather than taking on
+   specification deliverables as charter items itself, DISPATCH
+   identifies the proper venue for work.  If no such venue yet exists in
+   the RAI Area, DISPATCH will develop charters and consensus for a BoF,
+   working group, or exploratory group [RFC5111] as appropriate.  Unlike
+   the previous change structure, a DISPATCH review of any proposed
+   change to core SIP is not required before it progresses to SIPCORE;
+
+
+
+
+Peterson, et al.          Best Current Practice                 [Page 4]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+   however, any new proposed work that does not clearly fall within the
+   charter of an existing RAI Area effort should be examined by
+   DISPATCH.
+
+   In reaction to a proposal, the DISPATCH Working Group may determine
+   that:
+
+   1.  these requirements justify a change to the core SIP
+       specifications (RFCs 3261 through 3265) and thus any resulting
+       work must transpire in SIPCORE;
+
+   2.  these requirements do not change the SIP core specifications but
+       require a new effort in the RAI Area (be that a working group, a
+       BoF, or what have you);
+
+   3.  these requirements fall within the scope of existing chartered
+       work in the RAI Area; or
+
+   4.  the proposal should not be acted upon at this time.
+
+   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.  DISPATCH should act as a filter,
+   accepting only proposals that play to the strengths of SIP, not those
+   that confuse its applicability or ultimately reduce its usefulness as
+   a means for immediate personal communications on the Internet.
+
+   In practice, it is expected that the DISPATCH WG behaves as a RAI
+   "Open Area" working group, similar to those employed in other areas
+   of the IETF.  While it does not have the traditional deliverables of
+   a working group, DISPATCH may, at the discretion of its chairs and
+   Area Directors, adopt milestones in accordance with standard working
+   group milestone-adoption procedures, such as the production of
+   charter text for a BoF or working group, a "-00" problem statement
+   document that explicates a proposed work effort, or a document
+   explaining why a particular direction for standards development was
+   not pursued.
+
+2.  Terminology
+
+   In this document, the key words "MAY", "MUST", "MUST NOT", "SHOULD",
+   and "SHOULD NOT", are to be interpreted as described in [RFC2119].
+   This document additionally uses [RFC5226] language to describe IANA
+   registrations.
+
+
+
+
+
+
+
+Peterson, et al.          Best Current Practice                 [Page 5]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+3.  Introducing New Work to RAI
+
+   As with any new work in the IETF, proposals are best formulated in
+   individual Internet-Drafts.  New ideas arising within the chartered
+   scope of a RAI Area working group naturally should be treated as
+   candidates for adoption as a working group item there.  Experience
+   has demonstrated that authoring a problem statement or set of initial
+   requirements prior to (or at least separately from) submitting a
+   protocol mechanism speeds the consensus-making process significantly.
+   A problem statement should explain what problem needs to be solved,
+   why existing mechanisms are insufficient, and, for proposals to
+   modify SIP, why SIP is the appropriate solution for this problem.  A
+   problem statement must also detail any security issues that may
+   result from meeting these requirements.  When proposed new work does
+   not fall within the bounds of existing RAI Area working group
+   charters, the DISPATCH Working Group assists the authors of
+   proposals, the RAI Area Directors and the RAI community to decide the
+   best way to approach the problem.  Authors of proposals may submit
+   their problem statements to the DISPATCH Working Group for community
+   consideration and review.
+
+   The DISPATCH Working Group chairs, in conjunction with the RAI Area
+   Directors, will determine if the particular problems raised in the
+   requirements problem statement are indeed outside the charter of
+   existing efforts and, if so, if they warrant a DISPATCH milestone for
+   the definition of a new effort; this DISPATCH deliverable may take
+   the form of a problem statement Internet-Draft, charter, or similar
+   milestone that provides enough information to make a decision, but
+   must not include protocol development.  The DISPATCH Working Group
+   should consider whether the requirements can be merged with other
+   requirements from other applications, and refine the problem
+   statement accordingly.
+
+   Once a new effort has been defined in DISPATCH and there is working
+   group consensus that it should go forward, if the new effort will
+   take the form of a working group or BoF, then the ADs will present
+   the proposed new effort charter to the IESG and IAB, in accordance
+   with the usual chartering process.  If the new effort involves the
+   rechartering of an existing working group, then similarly the
+   existing working group rechartering functions will be performed by
+   the appropriate WG chairs and ADs.  If the IESG (with IAB advice)
+   approves of the new charter or BoF, the DISPATCH Working Group has
+   completed its deliverable and the new effort becomes autonomous.
+
+   Anyone proposing requirements for new work is welcome to jointly
+   develop, in a separate Internet-Draft, a mechanism that would meet
+   the requirements.  No working group is required to adopt the proposed
+   solution from this additional Internet-Draft.
+
+
+
+Peterson, et al.          Best Current Practice                 [Page 6]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+   Work overseen by the SIPCORE 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, SIPCORE must not
+   add features just to make a particular function more efficient at the
+   expense of simplicity or robustness.
+
+   The DISPATCH process is not the sole place that requirements for new
+   work are considered in the RAI Area.  For example, some working
+   groups generate requirements for SIP solutions and/or extensions.
+   At the time this document was written, groups with such chartered
+   deliverables include SIP for Instant Messaging and Presence
+   Leveraging Extensions (simple), Basic Level of Interoperability for
+   SIP Services (bliss) and Session Peering for Multimedia Interconnect
+   (speermint).  The work of these and similar groups is not affected by
+   the DISPATCH process.
+
+   Of course, the RAI Area Directors may accept charter revisions from
+   existing working groups that add new milestones or scope to their
+   charters at their discretion, in the standard IETF manner, without
+   any actions on the part of the DISPATCH Working Group.  DISPATCH
+   exists to assist new work in finding a home expeditiously in those
+   cases where it does not naturally fall into an existing bucket.
+
+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
+   header fields 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 RAI
+   Area calls for architectural guardianship and application of Occam's
+   Razor by the SIPCORE and DISPATCH Working Groups.
+
+   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.  In
+   the past, header fields associated with those extensions were called
+   "P-" header fields for "preliminary", "private", or "proprietary".
+
+
+
+
+
+Peterson, et al.          Best Current Practice                 [Page 7]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+   However, the "P-" header field process has not served the purpose for
+   which it was designed -- namely, to restrict to closed environments
+   the usage of mechanisms the IETF would not (yet) endorse for general
+   usage.  In fact, some "P-" header fields have enjoyed widespread
+   implementation; because of the "P-" prefix, however, there seems to
+   be no plausible migration path to designate these as general-usage
+   header fields without trying to force implausible changes on large
+   installed bases.
+
+   Accordingly, this specification deprecates the previous [RFC3427]
+   guidance on the creation of "P-" header fields.  Existing "P-" header
+   fields are to be handled by user agents and proxy servers as the "P-"
+   header field specifications describe; the deprecation of the change
+   process mechanism entails no change in protocol behavior.  New
+   proposals to document SIP header fields of an experimental or private
+   nature, however, shall not use the "P-" prefix (unless existing
+   deployments or standards use the prefix already, in which case they
+   may be admitted as grandfathered cases at the discretion of the
+   Designated Expert).
+
+   Instead, the registration of SIP header fields in Informational RFCs,
+   or in documents outside the IETF, is now permitted under the
+   Designated Expert (per [RFC5226]) criteria.  The future use of any
+   header field name prefix ("P-" or "X-" or what have you) to designate
+   SIP header fields of limited applicability is discouraged.  Experts
+   are advised to review documents for overlap with existing chartered
+   work in the RAI Area, and are furthermore instructed to ensure the
+   following two criteria are met:
+
+   1.  The proposed header field MUST be of a purely informational
+       nature and MUST NOT significantly change the behavior of SIP
+       entities that support it.  Header fields that merely provide
+       additional information pertinent to a request or a response are
+       acceptable; these header fields are thus expected to have few, if
+       any, implications for interoperability and backwards
+       compatibility.  Similarly, header fields that provide data
+       consumed by applications at the ends of SIP's rendezvous
+       function, rather than changing the behavior of the rendezvous
+       function, are likely to be providing information in this sense.
+       If the header fields redefine or contradict normative behavior
+       defined in Standards Track SIP specifications, that is what is
+       meant by significantly different behavior.  Ultimately, the
+       significance of differences in behavior is a judgment call that
+       must be made by the expert reviewer.
+
+   2.  The proposed header field MUST NOT undermine SIP security in any
+       sense.  The Internet-Draft proposing the new header field MUST
+       address security issues in detail, as if it were a Standards
+
+
+
+Peterson, et al.          Best Current Practice                 [Page 8]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+       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).
+
+   Note that the deprecation of the "P-" header field process does not
+   alter processes for the registration of SIP methods, URI parameters,
+   response codes, or option tags.
+
+4.1.  SIP Event Packages
+
+   SIP events [RFC3265] 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).  Note that the
+   guidance in [RFC3265] states that the IANA registration policy for
+   normal event packages is "First Come First Serve"; this document
+   replaces that policy with the following:
+
+   Individuals may wish to publish SIP Event packages that they believe
+   fall outside the scope of any chartered work currently in RAI.
+   Individual proposals for registration of a SIP event package MUST
+   first be published as Internet-Drafts for review by the DISPATCH
+   Working Group, or the working group, mailing list, or expert
+   designated by the RAI Area Directors if the DISPATCH 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.  Authors should submit their proposals as individual Internet-
+   Drafts and post an announcement to the working group mailing list to
+   begin discussion.  The DISPATCH Working Group will determine if a
+   proposed package is
+
+   a)  an appropriate usage of SIP that should be spun into a new
+       effort,
+
+   b)  applicable to SIP but not sufficiently interesting, general, or
+       in-scope to adopt as a working group effort,
+
+   c)  contrary to similar work chartered in an existing effort, or
+
+   d)  recommended to be adopted as or merged with chartered work
+       elsewhere in RAI.
+
+
+
+
+
+
+Peterson, et al.          Best Current Practice                 [Page 9]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+   "RFC Required" in conjunction with "Designated Expert" (both as
+   defined in RFC 5226) is the procedure 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 5226) must review the
+       proposal for applicability to SIP and conformance with these
+       guidelines.  The Designated Expert 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 [RFC3265], SIP [RFC3261], or related
+       Standards Track extensions.  (See Section 4.)
+
+   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 4 of SIP events [RFC3265].
+
+   7.  If determined by the Designated Expert or the chairs or ADs of
+       the DISPATCH 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.  Summary
+
+   1.  Documents that update or obsolete RFCs 3261 through 3265 must
+       advance through the SIPCORE WG.
+
+   2.  Standard SIP extensions that do not update RFCs 3261 through
+       3265, including event packages, may advance through chartered
+       activity in any RAI Area WG or (with the agreement of the RAI
+       ADs) any IETF working group that constitutes an appropriate
+       venue.
+
+
+
+
+Peterson, et al.          Best Current Practice                [Page 10]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+   3.  Documents that specify Informational header fields pass through
+       an Expert Review system.
+
+6.  Security Considerations
+
+   Complex, indeterminate, and hard-to-define protocol behavior,
+   depending on the interaction of many optional extensions, 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, must consider the security
+   implications of feature interactions, and most of all must not worsen
+   SIP's existing security considerations.
+
+7.  IANA Considerations
+
+   RFC 3261 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 header fields.
+   Reiterating the guidance of RFC 3261, method names, option tags, and
+   SIP response codes require a Standards Action for inclusion in the
+   IANA registry.  Authors of specifications should also be aware that
+   the SIP parameter registry is further elaborated in [RFC3968].
+
+   Previously in RFC 3427, all new SIP header field registrations
+   required a Standards Action (per RFC 5226) with the exception of "P-"
+   header fields; now, Informational registration of non-"P-" header
+   fields is permitted if approved by a Designated Expert, as described
+   in Section 4.
+
+   Each RFC shall include an IANA Considerations section that 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 header fields and messages MUST NOT begin with the leading
+   characters "P-".  Existing "P-" header field registrations are
+   considered grandfathered, but new registrations of Informational
+   header fields should not begin with the leading characters "P-"
+   (unless the "P-" would preserve compatibility with a pre-existing,
+   unregistered usage of the header field, at the discretion the
+   Designated Expert).  Short forms of header fields MUST only be
+   assigned to Standards Track header fields.
+
+
+
+
+
+Peterson, et al.          Best Current Practice                [Page 11]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+   Similarly, [RFC3265] directs the IANA to establish a registry for SIP
+   event packages and SIP event template-packages.  For event template-
+   packages, registrations must follow the [RFC5226] processes for
+   Standards Action within an IETF working group.  For normal event
+   packages, as stated previously, registrations minimally require
+   [RFC5226] "RFC Required" with "Designated Expert".  In either case,
+   the IESG announcement of RFC approval authorizes IANA to make the
+   registration.
+
+7.1.  Clarification of RFC 3969
+
+   [RFC3969] stipulates that the (original) [RFC2434] rule of
+   "Specification Required" applies to registrations of new SIP URI
+   parameters; however, Section 3 of that same document mandates that a
+   Standards Action is required to register new parameters with the
+   IANA.  This contradiction arose from a misunderstanding of the nature
+   of the [RFC2434] categories; the intention was for the IANA
+   Considerations to mandate that Standards Action is required.
+
+8.  Overview of Changes to RFC 3427
+
+   This section provides a high-level overview of the changes between
+   this document and RFC 3427.  It is not a substitute for the document
+   as a whole -- the details are necessarily not represented.
+
+   This document:
+
+   1.  Changes the description of the SIP and SIPPING WG functions to
+       the SIPCORE and DISPATCH WG functions using the context of the
+       RAI Area.
+
+   2.  Deprecates the process for "P-" header field registration, and
+       changes the requirements for registration of SIP header fields of
+       a purely informational nature.
+
+   3.  Updates IANA registry requirements, reflecting the publication of
+       RFC 5226, clarifying the policies in RFC 3969, and clarifying
+       that the original RFC 3237 updated the policies in RFC 3265.
+
+9.  Acknowledgments
+
+   The credit for the notion that SIP required careful management
+   belongs to the original authors: Allison Mankin, Scott Bradner, Rohan
+   Mahy, Dean Willis, Joerg Ott, and Brian Rosen.  The current editors
+   have provided only an update to reflect lessons learned from running
+   the code and from the changing situation of the IETF and the IANA
+   registration procedures.  Gonzalo Camarillo was instrumental to the
+   development of the concept of SIPCORE and DISPATCH.  Useful comments
+
+
+
+Peterson, et al.          Best Current Practice                [Page 12]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+   were provided by Jonathan Rosenberg, Mary Barnes, Dan York, John
+   Elwell, Alan Johnston, Spencer Dawkins, Alfred Hoenes, Russ Housley,
+   and Dean Willis.  The thorough review from Stephen Hanna of the
+   Security Directorate proved enormously valuable.  The authors also
+   appreciated IESG feedback from Alexey Melnikov, Adrian Farrel, Dan
+   Romascanu, and Magnus Westerlund.
+
+   The original authors thanked their 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, including and especially Jonathan Rosenberg,
+   Henning Schulzrinne, and William Marshall.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3261]  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.
+
+   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
+              Event Notification", RFC 3265, June 2002.
+
+   [RFC3969]  Camarillo, G., "The Internet Assigned Number Authority
+              (IANA) Uniform Resource Identifier (URI) Parameter
+              Registry for the Session Initiation Protocol (SIP)",
+              BCP 99, RFC 3969, December 2004.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+10.2.  Informative References
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+
+
+Peterson, et al.          Best Current Practice                [Page 13]
+
+RFC 5727                       SIP Change                     March 2010
+
+
+   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
+              Extensions to the Session Initiation Protocol (SIP) for
+              Asserted Identity within Trusted Networks", RFC 3325,
+              November 2002.
+
+   [RFC3427]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
+              and B. Rosen, "Change Process for the Session Initiation
+              Protocol (SIP)", BCP 67, RFC 3427, December 2002.
+
+   [RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
+              (IANA) Header Field Parameter Registry for the Session
+              Initiation Protocol (SIP)", BCP 98, RFC 3968,
+              December 2004.
+
+   [RFC5111]  Aboba, B. and L. Dondeti, "Experiment in Exploratory Group
+              Formation within the Internet Engineering Task Force
+              (IETF)", RFC 5111, January 2008.
+
+Authors' Addresses
+
+   Jon Peterson
+   NeuStar, Inc.
+
+   EMail: jon.peterson@neustar.biz
+
+
+   Cullen Jennings
+   Cisco Systems
+
+   EMail: fluffy@cisco.com
+
+
+   Robert Sparks
+   Tekelec
+
+   EMail: rjsparks@nostrum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson, et al.          Best Current Practice                [Page 14]
+