Transport Area A. Mankin
Internet-Draft USC/ISI
Expires: February 19, 2003 S. Bradner
Harvard University
R. Mahy
Cisco
D. Willis
dynamicsoft
J. Ott
IPDialog
B. Rosen
Marconi
August 27, 2002
Change Process for the Session Initiation Protocol (SIP)
draft-tsvarea-sipchange-03.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 19, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The IETF's Session Initiation Protocol (SIP, RFC 3261), was
originally developed for initiation of multimedia sessions. Internet
Mankin, et al. Expires February 19, 2003 [Page 1]
Internet-Draft SIP Change Process August 2002
multimedia, voice over IP, IP telephony, and SIP, have become quite
popular, both inside IETF and in consideration by other standards
groups, and the applications of SIP have grown. The task for IETF
management of SIP has been to steer SIP to its core strengths,
applications that it does best. One result of popularity has been a
continual flood of suggestions for SIP modifications and extensions.
This memo describes how the Transport Area directors along with the
SIP and SIPPING working group chairs have decided to deal with such
suggestions. The effects of adding new features, often in a case
where a point solution is sought, can be to damage security or to
greatly increase complexity. Therefore this memo documents a process
intended to apply architectural discipline to the future development
of SIP.
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
2.1 The IETF SIP Working Group
The IETF Session Initiation Protocol (sip) Working Group has been
chartered to be the "owner" of the SIP protocol [3], while the
working group continues. 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.
It 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 reponse 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, from requirements provided by the
SIPPING Working Group.
IETF working groups do not live forever and the process after some
future closing of the SIP Working Group will be as follows: as is
typical of any concluded group, the mailing list of the group should
continue. Until a SIP follow-on or similar new working were to be
formed, the Transport Area Directors of the future time will use the
RFC 2026 IETF Standards Process [2] (section 6.1.2) non-working group
standards track document process using the SIP and SIPPING mailing-
lists (typically IETF keeps concluded working group mailing lists as
resources), and using designated experts from the SIP community for
Mankin, et al. Expires February 19, 2003 [Page 2]
Internet-Draft SIP Change Process August 2002
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 IETF is hoped to be low.
SIP event packages [5] are appropriate to develop in the Working
Groups that use them, but they will need charter approval to create a
SIP event package as a working group effort. The IETF will also
require (Individual) RFC publication for 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
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, that the requirements should be
combined with other requirements to solve a more general problem, or
to 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.
Mankin, et al. Expires February 19, 2003 [Page 3]
Internet-Draft SIP Change Process August 2002
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 ID 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 the
requirements. After this 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 or related 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, 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. This Internet-Draft
would be passed on to the SIP working group for consideration (if
warranted). There is no requirement on the SIP working group that
the proposed solution from this additional ID be adopted.
The SIPPING working group may also evaluate such proposals for
extensions if the requirements are judged to be appropriate to SIP,
but the requirements 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 addition of a charter item for an extension without a full
SIPPING process as described. This will be the exception.
Mankin, et al. Expires February 19, 2003 [Page 4]
Internet-Draft SIP Change Process August 2002
With respect to standardization, this process means that SIP
extensions come only from the IETF, as 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 and must not add features that do not have general
use beyond the specific case - they also 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 of writing, 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 tracks 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 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.
Mankin, et al. Expires February 19, 2003 [Page 5]
Internet-Draft SIP Change Process August 2002
4.1 Indicating a "P-" Header:
Use of an "X-" prefix on textual identfiers has been widely used to
indicate experimental extensions in other protocols, and this
approach is applied in modified form here by use of a "P-" header
extension. However, there are a number of stronger constraints about
P- than about "X-" including documentation that get Expert and IESG
review, with 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 purely an 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
standards track SIP specification, 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
Mankin, et al. Expires February 19, 2003 [Page 6]
Internet-Draft SIP Change Process August 2002
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
specififcations. 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, and 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
SIP events defines two different types of event pacakges: 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.
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
Mankin, et al. Expires February 19, 2003 [Page 7]
Internet-Draft SIP Change Process August 2002
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
charted 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 RFC2434 [4]) MUST review the
proposal for applicability to SIP and conformance to 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 haven't 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 [5], 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 [5]
7. If necessary as 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
Mankin, et al. Expires February 19, 2003 [Page 8]
Internet-Draft SIP Change Process August 2002
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
RFC 3261 [3] directs the Internet Assigned Numbers Authority 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 a draft for 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 of the announcement of IESG 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!). So please do not when
you see: P-IANA-Greeting, accept the registration of IANA-Greetinga
as well. 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 [5] directs the Internet Assigned Numbers
Authority 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.
Mankin, et al. Expires February 19, 2003 [Page 9]
Internet-Draft SIP Change Process August 2002
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. 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.
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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
Authors' Addresses
Allison Mankin
USC/ISI
EMail: mankin@isi.edu
Scott Bradner
Harvard University
EMail: sob@harvard.edu
Rohan Mahy
Cisco
EMail: rohan@cisco.com
Mankin, et al. Expires February 19, 2003 [Page 10]
Internet-Draft SIP Change Process August 2002
Dean Willis
dynamicsoft
EMail: dean.willis@softarmor.com
Brian Rosen
Marconi
EMail: brian.rosen@marconi.com
Joerg Ott
IPDialog
EMail: jo@ipdialog.com
Mankin, et al. Expires February 19, 2003 [Page 11]
Internet-Draft SIP Change Process August 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
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 RFC Editor function is currently provided by the
Internet Society.
Mankin, et al. Expires February 19, 2003 [Page 12]