Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5727

Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area

Pages: 14
Best Current Practice: 67
Errata
Obsoletes:  3427
Updates:  32653969
Updated by:  7957

Top   ToC   RFC5727 - Page 1
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.
Top   ToC   RFC5727 - Page 2
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
Top   ToC   RFC5727 - Page 3

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.
Top   ToC   RFC5727 - Page 4
   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;
Top   ToC   RFC5727 - Page 5
   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.
Top   ToC   RFC5727 - Page 6

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.
Top   ToC   RFC5727 - Page 7
   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".
Top   ToC   RFC5727 - Page 8
   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
Top   ToC   RFC5727 - Page 9
       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.
Top   ToC   RFC5727 - Page 10
   "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.
Top   ToC   RFC5727 - Page 11
   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.
Top   ToC   RFC5727 - Page 12
   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
Top   ToC   RFC5727 - Page 13
   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.
Top   ToC   RFC5727 - Page 14
   [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