Network Working Group Scott Bradner
Internet-Draft Harvard University
Rohan Mahy
Cisco
Allison Mankin
USC/ISI
Joerg Ott
IPDialog
Brian Rosen
Marconi
Dean Willis
dynamicsoft
February 2002
SIP Change Process
1. Status of this Memo
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC 2026.
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
Copyright (C) The Internet Society (2002). All Rights Reserved.
2. Abstract
The IETF's Session Initiation Protocol (SIP) [RFC2543] is becoming
popular for a growing number of applications. One result of this
popularity is a continuous 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.
Transport ADs and SIP* Chairs [Page 1]
Internet-Draft SIP Change Process February 2002
3. The IETF SIP Working Group
The IETF Session Initiation Protocol (sip) Working Group is chartered
to be the "owner" of the SIP protocol. 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 6.1, all SIP extensions must be standards track and must be
developed in the IETF, from requirements provided by the SIPPING
Working Group.
SIP event packages [events] 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 6.3.
4. 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 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 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
detailing cars using the new SIP BRUSH method. SIPPING should act as
a filter, accepting only requirements which are applicable to SIP.
When the SIPPING working group decides on a set of requirements, it
forwards them to the SIP working group. The SIPPING Working Group may
Transport ADs and SIP* Chairs [Page 2]
Internet-Draft SIP Change Process February 2002
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 6.3.
5. 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 merge 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 6.1 within a specific scope of applicability.
Transport ADs and SIP* Chairs [Page 3]
Internet-Draft SIP Change Process February 2002
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.
With respect to standardization, this process means that SIP
extensions (with the exception of P- headers as described in Section
6.1) come only from the SIP Working Group, and only from the IETF, as
the body that created SIP. The IETF will not publish a SIP extension
RFC outside of the process 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).
6. 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, interopability 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.
We encourage other protocol working groups with highly extensible
protocols to review whether they need more coordination of extensions
(including restricting them to IETF) as in the SIP case.
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
Transport ADs and SIP* Chairs [Page 4]
Internet-Draft SIP Change Process February 2002
"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.
6.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.
Informational SIP Headers can be registered as "P-" headers if
all of the following conditions are met:
1. A designated expert [RFC2434] MUST review the proposal for
applicability to SIP and conformance to these guidelines. The
Expert Reviewer will send email to the IESG on this determina-
tion. The expert reviewer can cite one or more of the guide-
lines 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 addi-
tional information pertinent to a request or a response are
acceptable. If the headers redefine or contradict normative
behavior defined in bis or other standards track documents
then the behavior is significantly different.
Transport ADs and SIP* Chairs [Page 5]
Internet-Draft SIP Change Process February 2002
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 sce-
nario makes certain assumptions regarding security, the secu-
rity 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 sce-
narios (including the general Internet case).
6. The proposed header MUST be clearly documented in an
(Individual or Working Group) Informational RFC, and regis-
tered 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 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.
6.2. Preventing Identity Conflicts Between P-Extensions:
In order to prevent identity conflicts between P-extensions, this
document provides an IANA process (See: "IANA Considerations"
below) to allow for the registration of private or experimental
extension headers. All implemented extension headers SHOULD meet
the P-Header requirements in 6.1, and any extension 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.
6.3. SIP Event Packages
SIP events defines two different types of event pacakges: normal
event packages, and event template-packages. Event template-
Transport ADs and SIP* Chairs [Page 6]
Internet-Draft SIP Change Process February 2002
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. Indi-
vidual 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 seman-
tics, 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 suffi-
ciently 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 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 [RFC2434] MUST review the proposal for
applicability to SIP and conformance to these guidelines. The
Expert Reviewer will send email to the IESG on this determina-
tion. The expert reviewer can cite one or more of the guide-
lines 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 nor-
mative behavior of [events], [SIP], or related standards track
extensions.
Transport ADs and SIP* Chairs [Page 7]
Internet-Draft SIP Change Process February 2002
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 [events]
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.
7. 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 implica-
tions 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.
8. IANA Considerations
RFC XXXX [bis] 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 (the IESG
announcement of approval authorizes IANA to make the registra-
tion). For P-headers this requirement is relaxed to allow regis-
tration when any RFC is approved by the IESG (non-standards
track).
Each RFC shall include an IANA Considerations section which
Transport ADs and SIP* Chairs [Page 8]
Internet-Draft SIP Change Process February 2002
directs IANA to create appropriate registrations. Standard head-
ers and messages MUST NOT begin with the leading characters "P-".
"P-" header names MUST being with the leading characters "P-".
No "P-" header which conflicts with (would, without the "P-" pre-
fix 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-" pre-
fix. These "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.
9. References
[RFC 2543] "SIP: Session Initiation Protocol.", M. Handley, H.
Schulzrinne, E. Schooler, J. Rosenberg, RFC 2543, March 1999
[bis] "SIP: Session Initiation Protocol.", J. Rosenberg, et al,
Work in progress.
[events] "Event Notification in SIP", A. Roach, Internet Draft,
Feb 2002. Work in progress.
10. Author's Addresses
Scott Bradner
Email: sob@harvard.edu
Rohan Mahy
Email: rohan@cisco.com
Allison Mankin
Email: mankin@isi.edu
Joerg Ott
Email: jo@ipdialog.com
Brian Rosen
Email: brian.rosen@marconi.com
Dean Willis
Email: dean.willis@softarmor.com
10. Acknowledgements
Transport ADs and SIP* Chairs [Page 9]
Internet-Draft SIP Change Process February 2002
The Transport ADs thank our IESG and IAB colleagues
(especially Randy Bush, Harald Alvestrand and John Klensin)
for valuable
discussions of extensibility issues in a wide range of protocols,
including those that our area brings forward and others, and
many members of the SIP community at IETF for dialogue on these
issues for SIP.
10. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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 Stan-
dards 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 ENGI-
NEERING 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 PUR-
POSE.
Transport ADs and SIP* Chairs [Page 10]