RFC 3427

Change Process for the Session Initiation Protocol (SIP)

📅 published December 2002, from ietf

RFC 3427: Change Process for the Session Initiation Protocol (SIP) 💖

Okay bestie, let's get into RFC 3427 🦋 This is a Best Current Practice (it's BCP 67, categorised as Best Current Practice), dated December 2002, from the Network Working Group. It's all about how SIP (the Session Initiation Protocol, the thing that sets up calls and sessions) is allowed to change, so it doesn't get messy 💅

The authors are A. Mankin (Bell Labs, Lucent Corporation), S. Bradner (Harvard University), R. Mahy (Cisco), D. Willis (dynamicsoft), J. Ott (ipDialog / Uni Bremen TZI), and B. Rosen (Marconi). The title block doesn't list anything this RFC obsoletes or updates 🌸

Status of this Memo ✨

This document is an Internet Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements. Distribution of this memo is unlimited 🫶

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🌈

Okay so this memo writes down a process meant to bring architectural discipline to the future development of SIP 🧚 People were worried about new SIP proposals, because adding new SIP features could be damaging for security and/or make the protocol way more complex. Ngl, that's a valid fear 💀 The Transport Area directors, plus the chairs of the SIP and Session Initiation Proposal Investigation (SIPPING) working groups, have offered suggestions for SIP modifications and extensions.

1. Terminology 🍓

In this document, the key words "MAY", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" are to be interpreted as described in Keywords [1]. Those five words are the only ones in caps that carry requirement weight here, so pay attention to them 👑

2. History and Development 🌸

SIP [3] was originally built for starting multimedia sessions, and it was the IETF's baby first 🍼 Internet multimedia, voice over IP, IP telephony, and SIP got super popular, both inside the IETF and with other standards groups, and suddenly everyone wanted to use SIP for everything. The result? A nonstop flood of suggestions for SIP changes and extensions 😭 So the job of IETF management has been keeping SIP's development focused on its core strengths and the stuff it does best ✨

2.1 The IETF SIP Working Group 💅

The IETF SIP Working Group got chartered to be the "owner" of the SIP protocol [3], for as long as the working group exists. Every change or extension to SIP has to show up as a SIP Working Group document first. The SIP Working Group is the guardian of SIP for the Internet, so it should only extend or change SIP when there are compelling reasons to do so 🔥

Some things the SIP working group must handle: new SIP methods, new SIP option tags, new response codes, and new standards track SIP headers. The one exception is the "P-" headers described in Section 4.1. Everything else must be standards track, and it has to be developed in the IETF based on requirements provided by the SIPPING Working Group 💖

Working groups don't live forever, though. Usually the mailing lists stick around after a working group wraps up. If the SIP Working Group has closed and there's no suitable replacement or follow-on working group active, the Transport Area directors will then use the non-working group standards track document process (described in section 6.1.2 of RFC 2026--IETF Standards Process [2]). They'll use the SIP and SIPPING mailing lists, plus designated experts from the SIP community, for advice. The IETF stays the home of SIP extensions, and the standards track requirement stays as defined in the rest of this document. The growth rate of extensions to any protocol in the IETF is hoped to be low, which is a very mood 🌙

Any working group is allowed to develop SIP event packages [4], but it has to have charter approval first 🎀 The IETF will also require (Individual) RFC publication for registering event packages that were developed outside the scope of an IETF working group. The requirements for publishing event packages are described in detail in Section 4.3 🦋

2.2 The IETF SIPPING Working Group 🧚

The Session Initiation Proposal Investigation (sipping) Working Group got chartered to be a filter in front of the SIP Working Group. It investigates requirements for applications of SIP, and some of those might lead to requests for SIP extensions. The requirements can come from the community at large, or from individuals reporting requirements determined by another standards body. The SIPPING Working Group won't live forever either, so the same considerations from the sections above apply to it 🌸

The SIPPING Working Group may decide that a requirement can be satisfied by SIP without modifications. It may decide the requirement isn't general enough to warrant a SIP change. It may decide the requirement justifies a change to SIP. Or it may decide the requirement should be combined with other requirements to solve a more general problem, or to solve the same problem in a more flexible way 🌈

Real talk: SIP gets so much attention that some application designers want to use it just because it's there, like for controlling household appliances 🙈 That's where SIPPING comes in as the filter. It should only accept requirements that play to SIP's best strengths, such as realtime presence ✨

When the SIPPING working group decides on a set of requirements, it forwards them to the SIP working group. The SIPPING Working Group may also document usage or applications of SIP that don't need any protocol extensions 💜

The SIPPING working group also acts as a filter for proposed event packages, as described in Section 4.3 👑

3. SIP Change Process 💅

Anyone who thinks the existing SIP protocol is applicable to their application, but not sufficient for their task, must write an individual Internet-Draft. It has to explain the problem they're trying to solve, why SIP is the applicable protocol, and why the existing SIP protocol won't work 🫶 The Internet-Draft must include a detailed set of requirements (kept distinct from solutions) that SIP would need to meet to solve that particular problem. It must also describe in detail any security issues that come up from meeting those requirements 🔥 Once the Internet-Draft is published, the authors should send a note to the SIPPING Working Group mailing list to start discussion on it 🌸

The SIPPING working group chairs, together with the Transport Area Directors, decide whether the particular problems raised in the requirements Internet-Draft warrant being added to the SIPPING charter, based on the mailing list discussion. The SIPPING working group should consider whether the requirements can be merged with requirements from other applications, and refine the ID accordingly 🧚

If the chairs and the ADs both feel the new problems should be added to the SIPPING Working Group charter, then the ADs present the proposed SIPPING charter changes to the IESG and IAB, following the usual process for charter expansion. If the IESG (with IAB advice) approves the charter changes, the SIPPING working group can then work on the problems described in the Internet-Draft 🎀

In a separate Internet-Draft, the authors may describe a set of changes to SIP that would meet the requirements. That Internet-Draft would then be passed to the SIP working group for consideration (if warranted). The SIP working group is not required to adopt the proposed solution from this additional Internet-Draft 🦋

The SIPPING working group may also evaluate proposals for extensions if the requirements are judged appropriate to SIP, but not general enough for standards track activity. In that case, the SIPPING working group will try to determine whether the new proposal meets the requirements for publication as a "P-" header, as described in Section 4.1, within a specific scope of applicability 🌈

The Transport ADs may, on a case-by-case basis, support a process where the requirements analysis is implicit, and the SIP working group requests a charter item for an extension without a full SIPPING process like the one described above. This will be the exception, not the rule 🙈

Standardisation-wise, this process means SIP extensions come only from the IETF, the body that created SIP. The IETF will not publish a SIP extension RFC outside of the processes described here 👑

The SIP Working Group is required to protect the architectural integrity of SIP. It must not add features that don't have general use beyond the specific case. And it must not add features just to make a particular function more efficient at the expense of simplicity or robustness 💖

Some working groups besides SIPPING also generate requirements for SIP solutions and/or extensions. At the time this document was written, those include SIP for Instant Messaging and Presence Leveraging Extensions (simple), Service in the PSTN/IN Requesting InTernet Service (spirits), and Telephone Number Mapping (enum) ✨

4. Extensibility and Architecture 🧚

In an idealised protocol model, extensible design would be self-contained, and new extensions and new headers would naturally have an architectural coherence with the original protocol. It's giving perfect world 🌙

Unfortunately, that idealised vision hasn't been reached in the world of standards track protocols 😭 Interoperability implications can be addressed by capabilities negotiation rules. But the effects of adding features that overlap, or that deal with a point solution and aren't general, are much harder to control with rules. So the Transport Area calls for architectural guardianship and the application of Occam's Razor by the SIP Working Group 🔥

Keeping with the IETF tradition of "running code and rough consensus", it's valid to allow SIP extensions that either aren't ready for standards track yet (but might be understood for that role after some running code), or that are private or proprietary in nature. That second kind exists because a characteristic motivating them is usage known not to fit the Internet architecture for SIP. These are called "P-" headers, for "preliminary", "private", or "proprietary" 🌸

There are two key issues to keep the "P-" header extension space "safe" 🫶
  1. Clearly indicating the unarchitected or not-yet understood nature of the extension.
  2. Preventing identity conflicts between extensions.

4.1 Indicating a "P-" Header 🎀

okay so a lot of protocols use an "X-" prefix to mark experimental stuff 🧪 SIP takes that idea and glams it up with a "P-" header instead 💅 but the rules for "P-" headers are way stricter, like they need expert review AND IESG review, plus a bunch of SIP criteria we're about to go through. no shortcuts, bestie 🫶

Informational SIP Headers can be registered as "P-" headers if all of the following conditions are met:

  1. A designated expert (as defined in RFC 2434 [4]) MUST review the proposal for applicability to SIP and conformance to these guidelines. The Expert Reviewer will send email to the Transport Area Directors on this determination. The expert reviewer can cite one or more of the guidelines that haven't been followed in his/her opinion. 🔍
  2. The proposed extension MUST NOT define SIP option tags, response codes, or methods. 🚫
  3. The function of the proposed header MUST NOT overlap with current or planned chartered extensions. 🙅‍♀️
  4. The proposed header MUST be of a purely informational nature, and MUST NOT significantly change the behavior of SIP entities which support it. Headers which merely provide additional information pertinent to a request or a response are acceptable. If the headers redefine or contradict normative behavior defined in standards track SIP specifications, that is what is meant by significantly different behavior. 💭
  5. The proposed header MUST NOT undermine SIP security in any sense. The Internet Draft proposing the new header MUST address security issues in detail as if it were a Standards Track document. Note that, if the intended application scenario makes certain assumptions regarding security, the security considerations only need to meet the intended application scenario rather than the general Internet case. In any case, security issues need to be discussed for arbitrary usage scenarios (including the general Internet case). 🔐
  6. The proposed header MUST be clearly documented in an (Individual or Working Group) Informational RFC, and registered with IANA. 📄
  7. An applicability statement in the Informational RFC MUST clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP in the Internet. 🧭

Any implementation of a "P-" header (meaning "not specified by a standards-track RFC issued through the SIP Working Group") MUST include a "P-" prefix on the header, as in P-Headername. Note that "P-" extensions are not IETF standards of any kind, and MUST NOT be required by any production deployment considered compliant to IETF specifications. Specifically, implementations are only SIP compliant if a) they fall back to baseline behavior when they ignore all P- headers, and b) when using P- headers they do not contradict any normative behavior. 💖

4.2 Preventing Identity Conflicts Between P-Extensions 🔒

so to stop two P-headers from having the same identity (total mess 😭), this document sets up an IANA process (See: "IANA Considerations" below) to register the P-headers. if you run into an unknown P-header, you just ignore it. BUT section 4.1 is to be taken seriously, and people using P-headers get the best results by sticking to it 🫶

All implemented P-headers SHOULD meet the P-Header requirements in 4.1. Any P-header used outside of a very restricted research or teaching environment (such as a student lab on implementing extensions) MUST meet those requirements and MUST be documented in an RFC and be IANA registered. IANA registration is permitted when the IESG approves the internet-draft. ✨

4.3 SIP Event Packages 🦋

events [4] defines two different types of event packages: normal event packages, and event template-packages. Event template-packages can only be created and registered by the publication of a Standards Track RFC (from an IETF Working Group). Normal event packages can be created and registered by the publication of any Working Group RFC (Informational, Standards Track, Experimental), provided that the RFC is a chartered working group item. 🌸

Individuals can also publish SIP Event packages, which is super cute 🥹 Individual proposals for registration of a SIP event package MUST first be published as Internet-drafts for review by the SIPPING Working Group, or the working group, mailing list, or expert designated by the Transport Area Directors if the SIPPING Working Group has closed. Proposals should include a strong motivational section, a thorough description of the proposed syntax and semantics, event package considerations, security considerations, and examples of usage. The author should submit his or her proposal as an individual Internet-Draft, and post an announcement to the working group mailing list to begin discussion. The SIPPING Working Group will determine if the proposed package is a) an inappropriate usage of SIP, b) applicable to SIP but not sufficiently interesting, general, or in-scope to adopt as a working group effort, c) contrary to similar work planned in the Working Group, or d) should be adopted as or merged with chartered work. 🧐

The IETF requires (Individual) RFC publication for registration of event packages developed outside the scope of an IETF working group, according to the following guidelines:

  1. A designated expert (as defined in RFC 2434 [4]) MUST review the proposal for applicability to SIP and conformance with these guidelines. The Expert Reviewer will send email to the IESG on this determination. The expert reviewer can cite one or more of the guidelines that have not been followed in his/her opinion. 🔍
  2. The proposed extension MUST NOT define an event template-package. 🚫
  3. The function of the proposed package MUST NOT overlap with current or planned chartered packages. 🙅‍♀️
  4. The event package MUST NOT redefine or contradict the normative behavior of SIP events [4], SIP [3], or related standards track extensions. 📏
  5. The proposed package MUST NOT undermine SIP security in any sense. The Internet Draft proposing the new package MUST address security issues in detail as if it were a Standards Track document. Security issues need to be discussed for arbitrary usage scenarios (including the general Internet case). 🔐
  6. The proposed package MUST be clearly documented in an (Individual) Informational RFC, and registered with IANA. The package MUST document all the package considerations required in Section 5 of SIP events [4]. 📄
  7. If determined by the expert reviewer or the chairs or ADs of the SIPPING WG, an applicability statement in the Informational RFC MUST clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP in the Internet. 🧭

5. Security Considerations 🚨

Complexity and indeterminate or hard to define protocol behavior, depending on which of many extensions operate, is a fine breeding ground for security flaws. 😭 honestly this is the scariest sentence in the whole doc 💀

All Internet-Drafts that present new requirements for SIP must include a discussion of the security requirements and implications inherent in the proposal. All RFCs that modify or extend SIP must show that they have adequate security and do not worsen SIP's existing security considerations. no shade, but security is non-negotiable 🔥

6. IANA Considerations 📋

RFC 3261 [3] directs the Internet Assigned Numbers Authority (IANA) to establish a registry for SIP method names, a registry for SIP option tags, and a registry for SIP response codes, and to amend the practices used for the existing registry for SIP headers. 🗂️

With the exception of P-headers, entries go into these registries only by approval of an Internet-Draft as a standards track RFC. Each RFC shall include an IANA Considerations section which directs IANA to create appropriate registrations. Registration shall be done at the time the IESG announces its approval of the draft containing the registration requests. ✅

Standard headers and messages MUST NOT begin with the leading characters "P-". 🚫

"P-" header names MUST begin with the leading characters "P-". No "P-" header which conflicts with (would, without the "P-" prefix have the same name as) an existing standards track header is allowed. Each registration of a "P-" header will also reserve the name of the header as it would appear without the "P-" prefix. However, the reserved name without the "P-" will not explicitly appear in the registry. It will only appear if there is a later standards track document (which is unlikely in most cases!). Please do not accept the registration of IANA-Greeting when you see: P-IANA-Greeting. P-header's "reserved standard names" MUST NOT be used in a SIP implementation prior to standardization of the header. 🕵️‍♀️

Short forms of headers MUST only be assigned to standards track headers. In other words, P-headers MUST NOT have short forms. ✂️

Similarly, RFC 3265 [4] directs the IANA to establish a registry for SIP event packages and SIP event template packages. For event template packages, entries go into this registry only by approval of a draft for standards track RFC. For ordinary event packages, entries go into this registry only by approval of a draft for RFC (of any type). In either case, the IESG announcement of approval authorizes IANA to make the registration. 📣

7. Acknowledgements 🫶

The Transport ADs thank our IESG and IAB colleagues (especially Randy Bush, Harald Alvestrand, John Klensin, Leslie Daigle, Patrik Faltstrom, and Ned Freed) for valuable discussions of extensibility issues in a wide range of protocols, including those that our area brings forward and others. Thanks to the many members of the SIP community engaged in interesting dialogue about this document as well; Jonathan Rosenberg and Jon Peterson gave us useful reviews. Thanks also to Henning Schulzrinne and William Marshall. 💜

8. Normative References 📚

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[4] Roach, A., "Session Initiation Protocol (SIP) - Specific Event Notification", RFC 3265, June 2002.

9. Authors' Addresses 🌸

Allison Mankin
Bell Labs, Lucent Corporation

EMail: mankin@psg.com


Scott Bradner
Harvard University

EMail: sob@harvard.edu


Rohan Mahy
Cisco

EMail: rohan@cisco.com


Dean Willis
dynamicsoft

EMail: dean.willis@softarmor.com


Brian Rosen
Marconi

EMail: brian.rosen@marconi.com


Joerg Ott
ipDialog / Uni Bremen TZI

EMail: jo@ipdialog.com

okay bestie, time for the legal bit ⚖️ this is the copyright section and it's giving "read the fine print" energy 🙈

Copyright (C) The Internet Society (2002). All Rights Reserved.

So the Internet Society holds the copyright, and here's what you're allowed to do. You can copy this document and share it with others. You can also make derivative works that comment on it, explain it, or help people implement it, and you can publish and distribute those too, in whole or in part, with no restrictions of any kind 🎀. The one catch is that the copyright notice and this paragraph have to be included on every copy and every derivative work 🫶.

The document itself, though, can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. One is for developing Internet standards, and in that case the copyright procedures in the Internet Standards process must be followed 🔥. The other is translating it into languages other than English 🌈.

These permissions are perpetual, and the Internet Society or its successors or assigns will never revoke them 🦋 that's a lot of commitment, ngl 💜.

Last but not least, the disclaimer. This document and the information in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀 yes, it's all caps for a reason, bestie.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society ✨ so the people making sure these documents get published are supported by the same org that holds the copyright. big thank you to them 🫶💖

📦 where this page comes from