RFC3427 - Change Process for the Session Initiation Protocol (SIP)

Network Working Group A. Mankin

Request for Comments: 3427 Bell Labs, LUCent Corporation

BCP: 67 S. Bradner

Category: Best Current Practice Harvard University

R. Mahy

Cisco

D. Willis

dynamicsoft

J. Ott

ipDialog / Uni Bremen TZI

B. Rosen

Marconi

December 2002

Change Process for the Session Initiation Protocol (SIP)

Status of this Memo

This document specifies an Internet Best Current Practices for the

Internet Community, and requests discussion and suggestions for

improvements. Distribution of this memo is unlimited.

Abstract

This memo documents a process intended to apply architectural

discipline to the future development of the Session Initiation

Protocol (SIP). There have been concerns with regards to new SIP

proposals. Specifically, that the addition of new SIP features can

be damaging towards security and/or greatly increase the complexity

of the protocol. The Transport Area Directors, along with the SIP

and Session Initiation Proposal Investigation (SIPPING) working group

chairs, have provided 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].

2. History and Development

The IETF's Session Initiation Protocol (SIP) [3] was originally

developed for initiation of multimedia sessions. Internet

multimedia, voice over IP, IP telephony, and SIP have become quite

popular, both inside IETF and with other standards groups, and the

applications of SIP have grown. One result of this popularity has

been a continual flood of suggestions for SIP modifications and

extensions. The task for IETF management of SIP has been to keep the

protocol development focused on SIP's core strengths and the

applications it does best.

2.1 The IETF SIP Working Group

The IETF SIP Working Group has been chartered to be the "owner" of

the SIP protocol [3], as long as the working group exists. All

changes or extensions to SIP must first exist as SIP Working Group

documents. The SIP Working group is charged with being the guardian

of the SIP protocol for the Internet, and therefore should only

extend or change the SIP protocol when there are compelling reasons

to do so.

Documents that must be handled by the SIP working group include new

SIP methods, new SIP option tags, new response codes, and new

standards track SIP headers. With the exception of "P-" headers

described in Section 4.1, all SIP extensions must be standards track

and must be developed in the IETF based upon requirements provided by

the SIPPING Working Group.

IETF working groups do not live forever; typically, mailing lists

continue after the working group is concluded. If the SIP Working

Group has closed and no suitable replacement or follow-on working

group is active, the Transport Area directors will the use the non-

working group standards track document process (described in section

6.1.2 of RFC2026--IETF Standards Process [2]) using the SIP and

SIPPING mailing lists and designated eXPerts from the SIP community

for advice. The IETF will remain the home of extensions of SIP and

the requirement of standards track action will remain as defined in

the rest of this document. The rate of growth of extensions of any

protocol in the IETF is hoped to be low.

It is appropriate for any working group to develop SIP event packages

[4], but the working group must have charter approval to do so. The

IETF will also require (Individual) RFCpublication for the

registration of event packages developed outside the scope of an IETF

working group. Requirements for publishing event packages are

described in detail in Section 4.3.

2.2 The IETF SIPPING Working Group

The IETF Session Initiation Protocol Proposal Investigation (sipping)

Working Group is chartered to be a filter in front of the SIP Working

Group. This working group will investigate requirements for

applications of SIP, some of which may lead 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 SIPPING Working Group will

also not live forever, with similar consideration to the sections

above.

The SIPPING Working Group may determine: that these requirements can

be satisfied by SIP without modifications, that the requirements are

not sufficiently general to warrant a change to SIP, that the

requirements justify a change to SIP, or that the requirements should

be combined with other requirements to solve a more general problem

or solve the same problem in a more flexible way.

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. SIPPING should act as a filter,

accepting only requirements which play to the best strengths of SIP,

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 which do not require

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 that the existing SIP protocol is applicable to

their application, yet not sufficient for their task must write an

individual Internet-Draft explaining the problem they are trying to

solve, why SIP is the applicable protocol, and why the existing SIP

protocol will not work. The Internet-Draft must include a detailed

set of requirements (distinct from solutions) that SIP would need to

meet to solve the particular problem. The Internet-Draft must also

describe in detail any security issues that arise from meeting those

requirements. After the Internet-Draft is published, the authors

should send a note to the SIPPING Working Group mailing list to start

discussion on the Internet-Draft.

The SIPPING working group chairs, in conjunction with the Transport

Area Directors, will determine if the particular problems raised in

the requirements Internet-Draft warrants 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

other requirements from other applications, and refine the ID

accordingly.

If the chairs and the ADs both feel that the particular new problems

should be added to the SIPPING Working Group charter, then the ADs

will present the proposed SIPPING charter modifications to the IESG

and IAB, in accordance with the usual process for charter expansion.

If the IESG (with IAB advice) approves of 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. The 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 such proposals for

extensions if the requirements are judged to be appropriate to SIP,

but are not sufficiently general for standards track activity. The

SIPPING working group will attempt to determine if 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 in

which the requirements analysis is implicit and the SIP working group

requests the addition of a charter item for an extension without a

full SIPPING process as described. This will be the exception.

With respect to standardization, this process means that SIP

extensions come only from the IETF, the body that created SIP. The

IETF will not publish a SIP extension RFCoutside of the processes

described here.

The SIP 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, they must not add features just

to make a particular function more efficient at the expense of

simplicity or robustness.

Some working groups besides SIPPING generate requirements for SIP

solutions and/or extensions as well. At the time this document was

written, these 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 idealized protocol model, extensible design would be self-

contained, and it would be inherent that new extensions and new

headers 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

Transport Area calls for architectural guardianship and application

of Occam's Razor by the SIP Working Group.

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. We

call these "P-" headers, for "preliminary", "private", or

"proprietary".

There are two key issues to consider with respect to keeping 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:

Use of an "X-" prefix on textual identifiers has been widely used to

indicate experimental extensions in other protocols. This approach

is applied in modified form here by use of a "P-" header extension.

However, there are a number of stronger constraints for "P-" headers,

including documentation that get Expert and IESG review, and other

SIP protocol criteria described below.

Informational SIP Headers can be registered as "P-" headers if all of

the following conditions are met:

1. A designated expert (as defined in RFC2434 [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 RFCMUST 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 RFCissued 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:

In order to prevent identity conflicts between P-headers, this

document provides an IANA process (See: "IANA Considerations" below)

to register the P-headers. The handling of unknown P-headers is to

ignore them, however, section 4.1 is to be taken seriously, and users

of P-headers will have best results with adherence. 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 RFCand 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 may also wish to publish SIP Event packages. 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) RFCpublication 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 RFC2434 [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.

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.

6. IANA Considerations

RFC3261 [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 RFCshall 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, RFC3265 [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, RFC2119, March 1997.

[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP

9, RFC2026, October 1996.

[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,

Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:

Session Initiation Protocol", RFC3261, June 2002.

[4] Roach, A., "Session Initiation Protocol (SIP) - Specific Event

Notification", RFC3265, 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

10. Full Copyright Statement

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis 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.

Acknowledgement

Funding for the RFCEditor function is currently provided by the

Internet Society.