From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5727.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc5727.txt (limited to 'doc/rfc/rfc5727.txt') 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] + -- cgit v1.2.3