RFC 5727

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

📅 published March 2010, from ietf

RFC 5727: Change Process for SIP and the RAI Area 🎀

okay bestie, RFC 5727 is a Best Current Practice (BCP 67) with ISSN 2070-1721, dated March 2010. Three people wrote it: J. Peterson from NeuStar, Inc., C. Jennings from Cisco Systems, and R. Sparks from Tekelec. It obsoletes RFC 3427 and updates RFC 3265 and RFC 3969 💅✨

The title is Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area. ngl the title is a mouthful but the vibe is clear 🌸

Abstract 🫧

This memo writes down a process for organizing how SIP and related work in the Real-time Applications and Infrastructure (RAI) Area gets developed in the future 🦋 SIP is being deployed in more and more places, and changing or extending it in certain ways could threaten interoperability and security 😭 At the same time, the IETF process has to deal with existing deployments and keep implementers happy, so it's a balancing act.

The document defines two long-lived working groups in the RAI Area. One looks after the core SIP specifications, and the other develops new work that extends and applies SIP. 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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 5741 ✨

You can find the current status of this document, any errata, and a way to give feedback at http://www.rfc-editor.org/info/rfc5727 💖

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

1. History and Development 🕰️

SIP [RFC3261] has grown way past its roots in Internet-based multimedia sessions 📞 It's hugely popular for Voice-over-IP and IP telephony, both inside the IETF and in other standards groups. The downside of being this popular is a constant flood of proposed changes and extensions to SIP 😅 The big challenge for IETF management of SIP has been keeping baseline interoperability across its many implementations.

To protect SIP from changes that could reduce interoperability, the working group chairs and Area Directors who manage it wrote 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 described how external working groups or bodies could define extensions meant for limited usage, mainly through the "P-" header field mechanism.

Over time, though, the management structure of RFC 3427 showed some limits 👀 The biggest one is about "P-" header fields. Those need expert review and IESG shepherding, but in practice the IETF's oversight of them is pretty limited, and it's unclear how much value the IETF adds by supervising their development. Even worse, putting a "P-" in front of a header field name doesn't stop a popular header field from getting deployed beyond its original "limited usage" 🙈 A big example today is the P-Asserted-Identity (PAID) header field, described in RFC3325 [RFC3325].

So this document obsoletes RFC 3427 and describes a new structure for managing 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 whole life of the working group. Every change or extension to SIP had to exist first as a SIP Working Group document. That group was the guardian of the SIP protocol for the Internet, so it was only supposed to extend or change SIP when there were compelling reasons 🛡️

The SIPCORE Working Group replaces the function of the SIP Working Group from the original [RFC3427] account. Documents that have to be handled by SIPCORE include all documents that update or obsolete RFCs 3261 through 3265 or their successors. Every SIP extension considered in SIPCORE has to be Standards Track. They can be based on requirements developed externally in other IETF working groups ✨

Typical IETF working groups don't live forever, but SIPCORE's charter is open-ended so it can stay the place where core SIP development keeps going 💜 If SIPCORE has closed and there's no suitable replacement or follow-on working group active (and this specification hasn't been superseded either), then when someone proposes changes to the core SIP protocol, the RAI Area Directors will use the non-working-group Standards Track document process (described in Section 6.1.2 of RFC 2026 [RFC2026]). Review happens on the SIPCORE mailing list and with Designated Experts from the SIP community 🧚

Any IETF working group can develop SIP event packages [RFC3265], but that working group has to get charter approval first 📋 The IETF will also require [RFC5226] IETF Review for registering event packages developed outside the scope of an IETF working group. Instructions for event package registrations are 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 🔍 It looked into requirements for SIP applications, and some of those led to requests for SIP extensions. The requirements could come from the community at large, or from individuals reporting requirements that another standards body had determined.

The DISPATCH Working Group replaces the function of the SIPPING WG, but with a few important changes, the biggest being that its scope now extends beyond SIP to the entire work of the RAI Area 🎀 Like SIPPING, DISPATCH considers new proposals for work in the RAI Area. But instead of taking on specification deliverables as charter items itself, DISPATCH figures out the right venue for the work. If no such venue exists yet in the RAI Area, DISPATCH develops 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 moves on to SIPCORE. However, any new proposed work that doesn't clearly fall within the charter of an existing RAI Area effort should be examined by DISPATCH 👀

When DISPATCH gets a proposal, it may decide 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 SIP gets so much attention, some application designers may want to use it just because it's there, like for controlling household appliances 🏠 DISPATCH should act as a filter, accepting only proposals that play to SIP's strengths. It should not accept proposals that confuse its applicability or end up reducing its usefulness as a means for immediate personal communications on the Internet 💅

In practice, DISPATCH is expected to behave as a RAI "Open Area" working group, similar to the ones used in other areas of the IETF ✨ It doesn't have the traditional deliverables of a working group, but at the discretion of its chairs and Area Directors, DISPATCH may adopt milestones following standard working group milestone-adoption procedures. Those could be things like producing charter text for a BoF or working group, a "-00" problem statement document that explains a proposed work effort, or a document explaining why a particular direction for standards development wasn't 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 🫧

More to come in the next part, bestie ✨🦋

3. Introducing New Work to RAI ✨

okay so, new ideas are always best started as individual Internet-Drafts 📝 and if the idea fits inside the chartered scope of a RAI Area working group, it should be considered for adoption as a working group item there 🎀 Writing a problem statement or a set of initial requirements first (or at least separately from the protocol mechanism) makes consensus go SO much faster 🚀 A problem statement should explain what problem needs solving and why existing mechanisms aren't enough. If the proposal is about changing SIP, it also has to explain why SIP is the right tool for the job 🦋 And a problem statement MUST NOT skip the security issues that could come up from meeting those requirements. (Okay, that's a real MUST, bestie 😭 jk it's a must not skip, same vibe, lowercase energy 🫶)

If proposed new work doesn't fit inside any existing RAI Area working group charter, the DISPATCH Working Group steps in 💜 It helps the authors, the RAI Area Directors, and the wider RAI community figure out the best way to approach the problem 🌈 Authors can also send their problem statements to DISPATCH so the community can look at them and review them 👀

The DISPATCH Working Group chairs, working together with the RAI Area Directors, decide whether the problems in the requirements problem statement really are outside existing efforts' charters 🧐 If they are, and they're worth a DISPATCH milestone for defining a new effort, then it's go time ✨ That DISPATCH deliverable can be a problem statement Internet-Draft, a charter, or a similar milestone, as long as it has enough info to make a decision 💅 But it must not include protocol development, so no building the actual thing here, babe 🙅‍♀️ DISPATCH should also think about whether the requirements can be merged with requirements from other applications, and then tweak the problem statement to match 🧚

Once a new effort is defined in DISPATCH and the working group agrees it should move forward, the ADs present the proposed charter to the IESG and IAB, following the usual chartering process 🎀 If the new effort is going to be a working group or a BoF, that's the path. If it's a rechartering of an existing working group, the WG chairs and ADs handle it in the same way they normally would 🤝 If the IESG (with IAB advice) approves the new charter or BoF, then DISPATCH has finished its deliverable, and the new effort goes off on its own, fully autonomous, main character style 👑

Anyone who has proposed requirements for new work is totally welcome to team up and develop a mechanism that would meet those requirements, in a separate Internet-Draft 🌸 And no working group is required to adopt the proposed solution from that extra Internet-Draft, so no pressure 🫶

Work overseen by the SIPCORE Working Group is required to protect the architectural integrity of SIP 🛡️ It must not add features unless they have general use beyond one specific case, and SIPCORE must not add features just to make one particular function more efficient if that comes at the expense of simplicity or robustness 🙅‍♀️ Simplicity and robustness are the vibe, periodt 💖

The DISPATCH process isn't the only place where requirements for new work get considered in the RAI Area, ngl 💅 Some working groups make requirements for SIP solutions and/or extensions too. When this document was written, the groups with chartered deliverables like that included 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 groups, and similar ones, is not affected by the DISPATCH process at all ✨

Of course, the RAI Area Directors can accept charter revisions from existing working groups that add new milestones or scope, at their discretion, in the standard IETF way, and DISPATCH doesn't need to do anything for that 🦋 DISPATCH is really there to help new work find a home quickly in cases where it doesn't naturally fit into an existing bucket 🧚💜

4. Extensibility and Architecture

in an idealized protocol model, extensible design would be totally self-contained, and new extensions and new header fields would naturally fit architecturally with the original protocol 🥹 It's giving perfect harmony 🎀

BUT this idealized vision hasn't happened in the world of Standards Track protocols 😭 Interoperability stuff can be handled with capabilities negotiation rules, but the effects of adding features that overlap, or that solve a point problem and aren't general, are way harder to control with rules 💀 So the RAI Area calls for architectural guardianship and for applying Occam's Razor, done by the SIPCORE and DISPATCH Working Groups 🔥

In keeping with the IETF tradition of "running code and rough consensus" 🌸, it's valid to allow development of SIP extensions that aren't ready for Standards Track yet, but might be understood for that role after some running code. It's also valid for extensions that are private or proprietary, because the thing motivating them is usage that's known not to fit the Internet architecture for SIP 🙈 Back in the day, header fields for those extensions were called "P-" header fields, for "preliminary", "private", or "proprietary" 🧸

Here's the tea ☕: the "P-" header field process didn't actually do its job. Its whole purpose was to keep usage of mechanisms the IETF wouldn't (yet) endorse for general use inside closed environments 🔒 But some "P-" header fields ended up with widespread implementation anyway 😳 And because of the "P-" prefix, there doesn't seem to be a realistic migration path to making them general-usage header fields without forcing unrealistic changes on large installed bases 💔

So this specification deprecates the earlier [RFC3427] guidance on creating "P-" header fields 💅 Existing "P-" header fields keep being handled by user agents and proxy servers the way their "P-" header field specifications describe, and deprecating the change process doesn't change protocol behavior at all 🫶 New proposals to document SIP header fields of an experimental or private nature, though, shall not use the "P-" prefix. The exception is if existing deployments or standards already use the prefix, in which case they may be admitted as grandfathered cases at the discretion of the Designated Expert 🎀

Instead, registering SIP header fields in Informational RFCs, or in documents outside the IETF, is now permitted under the Designated Expert criteria (per [RFC5226]) 🦋 Using any header field name prefix to mark SIP header fields of limited applicability ("P-" or "X-" or whatever) is discouraged going forward 🙅‍♀️ Experts are advised to check documents for overlap with existing chartered work in the RAI Area, and they're also instructed to make sure these 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 just give extra info about a request or response are fine, and they're expected to have few, if any, implications for interoperability and backwards compatibility 🌈 Similarly, header fields that provide data for applications at the ends of SIP's rendezvous function, instead of changing how the rendezvous function behaves, are likely giving information in this sense ✨ If the header fields redefine or contradict normative behavior defined in Standards Track SIP specifications, that counts as significantly different behavior 😳 Ultimately, whether differences in behavior are significant is a judgment call that the expert reviewer has to make 👑
  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 Track document 💀 Also, if the intended application scenario makes certain assumptions about security, the security considerations only need to meet that intended scenario, not the general Internet case 🙈 But either way, security issues still need to be discussed for arbitrary usage scenarios, including the general Internet case 🫶

Note that dropping the "P-" header field process doesn't change how SIP methods, URI parameters, response codes, or option tags get registered 🍓 Those processes are totally unaffected, bestie 💜

4.1. SIP Event Packages ✨

okay so [RFC3265] splits SIP event packages into two kinds: normal event packages and event template-packages 🧩. Event template-packages can only be created and registered by publishing a Standards Track RFC from an IETF Working Group, no shortcuts 💅. Also, the guidance in [RFC3265] says the IANA registration policy for normal event packages is "First Come First Serve," but this document swaps that out for the following, bestie 🫶

Individuals might want to publish SIP event packages that they think fall outside the scope of any chartered work currently in RAI 🦋. Individual proposals to register a SIP event package MUST first be published as Internet-Drafts so they can be reviewed by the DISPATCH Working Group, or by 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 kick off discussion 💌. Then the DISPATCH Working Group decides whether 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.

"RFC Required" paired with "Designated Expert" (both as defined in RFC 5226) is the procedure for registering event packages developed outside the scope of an IETF working group 🎀. It follows these 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 email the IESG with this determination. The expert reviewer can cite one or more of the guidelines that have not been followed, in their 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.
  3. Documents that specify Informational header fields pass through an Expert Review system.

6. Security Considerations 💀

Okay, this section is serious, bestie 😭. Complex, indeterminate, and hard-to-define protocol behavior, depending on the interaction of many optional extensions, is a fine breeding ground for security flaws. Literally a recipe for disaster.

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 🔥. No pressure, but this is the whole vibe.

7. IANA Considerations 📋

[RFC3261] 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 know 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 of the Designated Expert). Short forms of header fields MUST only be assigned to Standards Track header fields 🎀.

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 gives 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 only provided 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 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 who 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.

[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
📦 where this page comes from