< draft-peterson-rai-rfc3427bis-03.txt   draft-peterson-rai-rfc3427bis-04.txt >
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Obsoletes: 3427 (if approved) C. Jennings Obsoletes: 3427 (if approved) C. Jennings
Intended status: BCP Cisco Systems Updates: 3265,3969 Cisco Systems
Expires: March 18, 2010 R. Sparks (if approved) R. Sparks
Tekelec Intended status: BCP Tekelec
September 14, 2009 Expires: April 26, 2010 October 23, 2009
Change Process for the Session Initiation Protocol (SIP) Change Process for the Session Initiation Protocol (SIP) and the Real-
draft-peterson-rai-rfc3427bis-03 time Applications and Infrastructure Area
draft-peterson-rai-rfc3427bis-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 45 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 18, 2010. This Internet-Draft will expire on April 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This memo documents a process intended to organize the future This memo documents a process intended to organize the future
development of the Session Initiation Protocol (SIP). As the development of the Session Initiation Protocol (SIP) and related work
in the Real-Time Applications and Infrastructure (RAI) Area. As the
environments in which SIP is deployed grow more numerous and diverse, environments in which SIP is deployed grow more numerous and diverse,
modifying or extending SIP in certain ways may threaten the modifying or extending SIP in certain ways may threaten the
interoperability and security of the protocol; however, the IETF interoperability and security of the protocol; however, the IETF
process must also cater to the realities of existing deployments and process must also cater to the realities of existing deployments and
serve the needs of the implementers working with SIP. This document serve the needs of the implementers working with SIP. This document
therefore defines the functions of two long-lived working groups in therefore defines the functions of two long-lived working groups in
the RAI Area which are, respectively, responsible for the maintenance the RAI Area which are, respectively, responsible for the maintenance
of the core SIP specifications and development of new efforts to of the core SIP specifications and development of new efforts to
extend and apply SIP. This document obsoletes RFC3427. extend and apply work in this space. This document obsoletes
RFC3427.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. History and Development . . . . . . . . . . . . . . . . . . . 5 2. History and Development . . . . . . . . . . . . . . . . . . . 5
2.1. The IETF SIPCORE Working Group . . . . . . . . . . . . . . 5 2.1. The IETF SIPCORE Working Group . . . . . . . . . . . . . . 5
2.2. The IETF DISPATCH Working Group . . . . . . . . . . . . . 6 2.2. The IETF DISPATCH Working Group . . . . . . . . . . . . . 6
3. Introducing New Work to RAI . . . . . . . . . . . . . . . . . 8 3. Introducing New Work to RAI . . . . . . . . . . . . . . . . . 8
4. Extensibility and Architecture . . . . . . . . . . . . . . . . 10 4. Extensibility and Architecture . . . . . . . . . . . . . . . . 10
4.1. SIP Event Packages . . . . . . . . . . . . . . . . . . . . 11 4.1. SIP Event Packages . . . . . . . . . . . . . . . . . . . . 11
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. Clarification of RFC3969 . . . . . . . . . . . . . . . . . 16 7.1. Clarification of RFC3969 . . . . . . . . . . . . . . . . . 16
8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Overview of changes to RFC3427 . . . . . . . . . . . . . . . . 18
8.1. Changes from RFC3427bis-00 . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Changes from RFC3427 . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Terminology 1. Terminology
In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD",
and "SHOULD NOT", are to be interpreted as described in [RFC2119]. and "SHOULD NOT", are to be interpreted as described in [RFC2119].
This document additionally uses [RFC5226] language to describe IANA This document additionally uses [RFC5226] language to describe IANA
registrations. registrations.
2. History and Development 2. History and Development
The Session Initiation Protocol (SIP) [RFC3261] has grown well beyond The Session Initiation Protocol (SIP) [RFC3261] has grown well beyond
its origins in Internet-based multimedia sessions, and now enjoys its origins in Internet-based multimedia sessions, and now enjoys
widespread popularity in Voice over IP or IP telephony applications, widespread popularity in Voice over IP or IP telephony applications,
both inside IETF and within other standards groups. One result of both inside IETF and within other standards groups. One result of
this popularity has been a continual flood of proposals for SIP this popularity has been a continual flood of proposals for SIP
modifications and extensions. The challenge for IETF management of modifications and extensions. The challenge for IETF management of
SIP has to preserve baseline interoperability across its many SIP has been to preserve baseline interoperability across its many
implementations implementations
In order to defend SIP against changes that might reduce In order to defend SIP against changes that might reduce
interoperability, the working group chairs and Area Directors interoperability, the working group chairs and Area Directors
responsible for its management authored the SIP change process responsible for its management authored the SIP change process
[RFC3427]. SIP change defined the role of the SIP and SIPPING [RFC3427]. SIP change defined the role of the SIP and SIPPING
working groups in shepherding ongoing work on the SIP standard. It working groups in shepherding ongoing work on the SIP standard. It
also defined ways that external working groups or bodies could define also defined ways that external working groups or bodies could define
extensions intended for limited usage, especially through the "P-" extensions intended for limited usage, especially through the "P-"
header mechanism. header field mechanism.
Over time, however, the management structure of RFC3427 has Over time, however, the management structure of RFC3427 has
demonstrated some limitations. The first and most significant of demonstrated some limitations. The first and most significant of
these concerns "P-" headers. While "P-" headers require expert these concerns "P-" header fields. While "P-" header fields require
review and IESG shepherding, in practice IETF oversight of these expert review and IESG shepherding, in practice IETF oversight of
headers is quite limited, and the value added by the IETF supervising these header fields is quite limited, and the value added by the IETF
their development remains unclear. More importantly, the presence of supervising their development remains unclear. More importantly, the
a "P-" in front of a header name does nothing to prevent a popular presence of a "P-" in front of a header field name does nothing to
header from seeing deployment outside of the original "limited usage" prevent a popular header field from seeing deployment outside of the
it envisioned; a prominent example of this today is the P-Asserted- original "limited usage" it envisioned; a prominent example of this
Identity (PAID) header, described in RFC3325 [RFC3325]. today is the P-Asserted-Identity (PAID) header field, described in
RFC3325 [RFC3325].
Consequently, this document obsoletes RFC3427 and describes a new Consequently, this document obsoletes RFC3427 and describes a new
structure for the management of IETF deliverables. structure for the management of deliverables in the Real-time
Applications and Infrastructure Area.
2.1. The IETF SIPCORE Working Group 2.1. The IETF SIPCORE Working Group
Historically, the IETF SIP Working Group (sip) was chartered to be Historically, the IETF SIP Working Group (sip) was chartered to be
the "owner" of the SIP protocol [RFC3261] for the duration of the the "owner" of the SIP protocol [RFC3261] for the duration of the
life of the working group exists. All changes or extensions to SIP working group. All changes or extensions to SIP were first required
were first required to exist as SIP Working Group documents. The SIP to exist as SIP Working Group documents. The SIP working group was
working group was charged with being the guardian of the SIP protocol charged with being the guardian of the SIP protocol for the Internet,
for the Internet, and therefore was mandated only to extend or change and therefore was mandated only to extend or change the SIP protocol
the SIP protocol when there are compelling reasons to do so. when there are compelling reasons to do so.
The SIPCORE working group replaces the function of the SIP working The SIPCORE working group replaces the function of the SIP working
group in the original RFC3427 account. Documents that must be group in the original RFC3427 account. Documents that must be
handled by the SIPCORE working group include all updates or obsoletes handled by the SIPCORE working group include all documents which
of RFC3261 through RFC3265. All SIP extensions considered in SIPCORE update or obsolete RFC3261 through RFC3265 or their successors. All
must be standards track. They may be based upon requirements SIP extensions considered in SIPCORE must be standards track. They
developed externally in other IETF working groups. may be based upon requirements developed externally in other IETF
working groups.
Typical IETF working groups do not live forever; SIPCORE's charter is Typical IETF working groups do not live forever; SIPCORE's charter is
however open-ended in order to allow it to remain the place where however open-ended in order to allow it to remain the place where
core SIP development will continue. In the event that the SIPCORE core SIP development will continue. In the event that the SIPCORE
working group has closed and no suitable replacement or follow-on working group has closed and no suitable replacement or follow-on
working group is active (and this specification also has not been working group is active (and this specification also has not been
superseded), then when modifications to the core SIP protocol are superseded), then when modifications to the core SIP protocol are
proposed the RAI Area Directors will the use the non-working group proposed the RAI Area Directors will use the non-working group
standards track document process (described in Section 6.1.2 of RFC standards track document process (described in Section 6.1.2 of RFC
2026 [RFC2026]) using the SIPCORE mailing list and designated experts 2026 [RFC2026]) using the SIPCORE mailing list and designated experts
from the SIP community for review. The IETF will remain the home of from the SIP community for review.
extensions of SIP and 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 It is appropriate for any IETF working group to develop SIP event
[RFC3265], but the working group must have charter approval to do so. packages [RFC3265], but the working group must have charter approval
The IETF will also require RFC5226 IETF Review for the registration to do so. The IETF will also require RFC5226 IETF Review for the
of event packages developed outside the scope of an IETF working registration of event packages developed outside the scope of an IETF
group. Instructions for event package registrations are provided in working group. Instructions for event package registrations are
Section 4.1. provided in Section 4.1.
2.2. The IETF DISPATCH Working Group 2.2. The IETF DISPATCH Working Group
Historically, the IETF Session Initiation Protocol Proposal Historically, the IETF Session Initiation Protocol Proposal
Investigation (sipping) Working Group was chartered to be a filter in Investigation (sipping) Working Group was chartered to be a filter in
front of the SIP Working Group. This working group investigated front of the SIP Working Group. This working group investigated
requirements for applications of SIP, some of which led to requests requirements for applications of SIP, some of which led to requests
for extensions to SIP. These requirements may come from the for extensions to SIP. These requirements may come from the
community at large, or from individuals who are reporting the community at large, or from individuals who are reporting the
requirements as determined by another standards body. requirements as determined by another standards body.
The DISPATCH working group replaces the function of the SIPPING WG, The DISPATCH working group replaces the function of the SIPPING WG,
although with several important changes to its functionality. Like although with several important changes to its functionality, the
SIPPING, DISPATCH considers new proposals for work in the RAI Area, most notable being that its scope expands beyond just SIP to the
but rather than taking on specification deliverables as charter items entire work of the RAI Area. Like SIPPING, DISPATCH considers new
itself, DISPATCH identifies the proper venue for work. If no such proposals for work in the RAI Area, but rather than taking on
venue yet exists in the RAI Area, DISPATCH will develop charters and specification deliverables as charter items itself, DISPATCH
consensus for a BoF, working group, or exploratory group [RFC5111] as identifies the proper venue for work. If no such venue yet exists in
appropriate. Unlike the previous change structure, a DISPATCH review the RAI Area, DISPATCH will develop charters and consensus for a BoF,
of any proposed change to core SIP is not required before it working group, or exploratory group [RFC5111] as appropriate. Unlike
progresses to SIPCORE; however, any new proposed work which does not the previous change structure, a DISPATCH review of any proposed
clearly fall within the charter of an existing RAI Area effort should change to core SIP is not required before it progresses to SIPCORE;
be examined by DISPATCH. however, any new proposed work which does not clearly fall within the
charter of an existing RAI Area effort should be examined by
DISPATCH.
In reaction to a proposal, the DISPATCH Working Group may determine: In reaction to a proposal, the DISPATCH Working Group may determine:
that these requirements justify a change to the core SIP that these requirements justify a change to the core SIP
specifications (RFC3261 through RFC3265) and thus any resulting work specifications (RFC3261 through RFC3265) and thus any resulting work
must transpire in SIPCORE, that the requirements do not change the must transpire in SIPCORE, that the requirements do not change the
SIP core specifications but require a new effort in the RAI area (be SIP core specifications but require a new effort in the RAI area (be
that a working group, a BoF, or what have you), that the requirements that a working group, a BoF, or what have you), that the requirements
fall within the scope of existing chartered work in the RAI Area, or fall within the scope of existing chartered work in the RAI Area, or
that the proposal should not be acted upon at this time. Because the that the proposal should not be acted upon at this time. Because the
SIP protocol gets so much attention, some application designers may SIP protocol gets so much attention, some application designers may
want to use it just because it is there, such as for controlling want to use it just because it is there, such as for controlling
household appliances. DISPATCH should act as a filter, accepting household appliances. DISPATCH should act as a filter, accepting
only proposals which play to the strengths of SIP, not those that only proposals which play to the strengths of SIP, not those that
confuse its applicability or ultimately reduce its usefulness as a confuse its applicability or ultimately reduce its usefulness as a
means for immediate personal communications on the Internet. means for immediate personal communications on the Internet.
In practice, it is expected that the DISPATCH WG behaves as a RAI In practice, it is expected that the DISPATCH WG behaves as a RAI
"Open Area" working group, similar to those employed in other areas "Open Area" working group, similar to those employed in other areas
of the IETF. While it does not have the traditional deliverables of of the IETF. While it does not have the traditional deliverables of
a working group, DISPATCH may at the discretion of its chairs adopt a working group, DISPATCH may at the discretion of its chairs and
milestones such as the production of charter text for a BoF or Area Directors adopt milestones, in accordance with standard working
working group, a "-00" problem statement document that explicates a group milestone adoption procedures, such as the production of
proposed work effort, or a document explaining why a particular charter text for a BoF or working group, a "-00" problem statement
direction for standards development was not pursued. document that explicates a proposed work effort, or a document
explaining why a particular direction for standards development was
not pursued.
3. Introducing New Work to RAI 3. Introducing New Work to RAI
When proposals arise for modifications or extensions to SIP outside When proposals arise for modifications or extensions to SIP outside
the scope of existing chartered RAI Area work, they must be written the scope of existing chartered RAI Area work, they must be written
up as a problem statement (preferably as an Internet-Draft) up as a problem statement (preferably as an Internet-Draft)
explaining the problem they are trying to solve, why SIP is the explaining the problem they are trying to solve, why SIP is the
applicable protocol, and why the existing SIP protocol will not work. applicable protocol, and why the existing SIP protocol will not work.
The problem statement must include a detailed set of requirements The problem statement must include a detailed set of requirements
(distinct from solutions) that SIP would need to meet to solve the (distinct from solutions) that SIP would need to meet to solve the
skipping to change at page 8, line 32 skipping to change at page 8, line 32
requirements problem statement are indeed outside the charter of requirements problem statement are indeed outside the charter of
existing efforts, and if so, if they warrant a DISPATCH milestone for existing efforts, and if so, if they warrant a DISPATCH milestone for
the definition of a new effort; this DISPATCH deliverable may take the definition of a new effort; this DISPATCH deliverable may take
the form of a problem statement Internet-Draft, charter or similar the form of a problem statement Internet-Draft, charter or similar
milestone that provides enough information to make a decision, but milestone that provides enough information to make a decision, but
must not include protocol development. The DISPATCH working group must not include protocol development. The DISPATCH working group
should consider whether the requirements can be merged with other should consider whether the requirements can be merged with other
requirements from other applications, and refine the problem requirements from other applications, and refine the problem
statement accordingly. statement accordingly.
Once a new effort has been defined in DISPATCH and there is consensus Once a new effort has been defined in DISPATCH and there is working
that it should go forward, if the new effort will take the form of a group consensus that it should go forward, if the new effort will
working group or BoF, then the ADs will present the proposed new take the form of a working group or BoF, then the ADs will present
effort charter to the IESG and IAB, in accordance with the usual the proposed new effort charter to the IESG and IAB, in accordance
chartering process. If the new effort involves the rechartering of with the usual chartering process. If the new effort involves the
an existing working group, then similarly the existing working group rechartering of an existing working group, then similarly the
rechartering functions will be performed by the appropriate WG chairs existing working group rechartering functions will be performed by
and ADs. If the IESG (with IAB advice) approves of the new charter the appropriate WG chairs and ADs. If the IESG (with IAB advice)
or BoF, the DISPATCH working group has completed its deliverable and approves of the new charter or BoF, the DISPATCH working group has
the new effort becomes autonomous. completed its deliverable and the new effort becomes autonomous.
Anyone proposing requirements for new work is welcome to jointly Anyone proposing requirements for new work is welcome to jointly
develop, in a separate Internet-Draft, a mechanism that would meet develop, in a separate Internet-Draft, a mechanism that would meet
the requirements. No working group is required to adopt the proposed the requirements. No working group is required to adopt the proposed
solution from this additional Internet-Draft. solution from this additional Internet-Draft.
Work overseen by the SIPCORE Working Group is required to protect the Work overseen by the SIPCORE Working Group is required to protect the
architectural integrity of SIP and must not add features that do not architectural integrity of SIP and must not add features that do not
have general use beyond the specific case. Also, SIPCORE must not have general use beyond the specific case. Also, SIPCORE must not
add features just to make a particular function more efficient at the add features just to make a particular function more efficient at the
expense of simplicity or robustness. The DISPATCH working group may expense of simplicity or robustness.
also evaluate and approve proposals for extensions if the
requirements are judged to be appropriate to SIP, but are not
sufficiently general for standards track activity.
Some working groups generate requirements for SIP solutions and/or Some working groups generate requirements for SIP solutions and/or
extensions. At the time this document was written, some groups with extensions. At the time this document was written, some groups with
such chartered deliverables include SIP for Instant Messaging and such chartered deliverables include SIP for Instant Messaging and
Presence Leveraging Extensions (simple), Basic Level of Presence Leveraging Extensions (simple), Basic Level of
Interoperability for SIP Services (bliss) and Session Peering for Interoperability for SIP Services (bliss) and Session Peering for
Multimedia Interconnect (speermint). Multimedia Interconnect (speermint).
The RAI ADs may, on an exceptional, case by case basis, support a The RAI ADs may, on an exceptional, case by case basis, support a
process in which the requirements analysis is implicit and a RAI area process in which the requirements analysis is implicit and a RAI area
working group handling extensions to SIP requests the addition of a working group handling extensions to SIP requests the addition of a
charter item for an extension without a full DISPATCH process as charter item for an extension without a full DISPATCH process as
described. described.
4. Extensibility and Architecture 4. Extensibility and Architecture
In an idealized protocol model, extensible design would be self- In an idealized protocol model, extensible design would be self-
contained, and it would be inherent that new extensions and new contained, and it would be inherent that new extensions and new
headers would naturally have an architectural coherence with the header fields would naturally have an architectural coherence with
original protocol. the original protocol.
However, this idealized vision has not been attained in the world of However, this idealized vision has not been attained in the world of
standards track protocols. While, interoperability implications can standards track protocols. While interoperability implications can
be addressed by capabilities negotiation rules, the effects of adding be addressed by capabilities negotiation rules, the effects of adding
features that overlap, or that deal with a point solution and are features that overlap, or that deal with a point solution and are not
not, are much harder to control with rules. Therefore, the RAI Area general, are much harder to control with rules. Therefore, the RAI
calls for architectural guardianship and application of Occam's Razor Area calls for architectural guardianship and application of Occam's
by the SIPCORE and DISPATCH Working Groups. Razor by the SIPCORE and DISPATCH Working Groups.
In keeping with the IETF tradition of "running code and rough In keeping with the IETF tradition of "running code and rough
consensus", it is valid to allow for the development of SIP consensus", it is valid to allow for the development of SIP
extensions that are either not ready for standards track, but might extensions that are either not ready for standards track, but might
be understood for that role after some running code, or are private be understood for that role after some running code, or are private
or proprietary in nature, because a characteristic motivating them is or proprietary in nature, because a characteristic motivating them is
usage that is known not to fit the Internet architecture for SIP. In usage that is known not to fit the Internet architecture for SIP. In
the past, headers associated with those extensions were called "P-" the past, header fields associated with those extensions were called
headers, for "preliminary", "private", or "proprietary". "P-" header fields, for "preliminary", "private", or "proprietary".
However, the "P-" header process has not served the purpose for which However, the "P-" header field process has not served the purpose for
it was designed - namely, to restrict to closed environments the which it was designed - namely, to restrict to closed environments
usage of mechanisms the IETF would not (yet) endorse for general the usage of mechanisms the IETF would not (yet) endorse for general
usage. In fact, some "P-" headers have enjoyed widespread usage. In fact, some "P-" header fields have enjoyed widespread
implementation; because of the "P-" prefix, however, there seems to implementation; because of the "P-" prefix, however, there seems to
be no plausible migration path to designate these as general-usage be no plausible migration path to designate these as general-usage
headers without trying to force implausible changes on large header fields without trying to force implausible changes on large
installed bases. installed bases.
Accordingly, this specification deprecates the previous RFC3427 Accordingly, this specification deprecates the previous RFC3427
guidance on the creation of "P-" headers. Existing "P-" headers are guidance on the creation of "P-" header fields. Existing "P-" header
to be handled by user agents and proxy servers as the "P-" header fields are to be handled by user agents and proxy servers as the "P-"
specifications describe; the deprecation of the change process header field specifications describe; the deprecation of the change
mechanism entails no change in protocol behavior. New proposals to process mechanism entails no change in protocol behavior. New
document SIP headers of an experimental or private nature, however, proposals to document SIP header fields of an experimental or private
shall not use the 'P-" prefix (unless existing deployments or nature, however, shall not use the 'P-" prefix (unless existing
standards use the prefix already, in which case they may be admitted deployments or standards use the prefix already, in which case they
as grandfathered cases at the discretion of the Designated Expert). may be admitted as grandfathered cases at the discretion of the
Designated Expert).
Instead, the registration of SIP headers in Informational IETF
specifications, or in documents outside the IETF, is now permitted
under the Designated Expert (per RFC5226) criteria. The future use
of any header field name prefix ("P-" or "X-" or what have you) to
designate SIP headers of limited applicability is discouraged.
Instead, the registration of SIP header fields in Informational RFCs,
or in documents outside the IETF, is now permitted under the
Designated Expert (per RFC5226) criteria. The future use of any
header field field name prefix ("P-" or "X-" or what have you) to
designate SIP header fields of limited applicability is discouraged.
Experts are advised to review documents for overlap with existing Experts are advised to review documents for overlap with existing
chartered work in the RAI Area, and are furthermore instructed to chartered work in the RAI Area, and are furthermore instructed to
ensure the following two criteria are met: ensure the following two criteria are met:
1. The proposed header MUST be of a purely informational nature, and 1. The proposed header field MUST be of a purely informational
MUST NOT significantly change the behavior of SIP entities which nature, and MUST NOT significantly change the behavior of SIP
support it. Headers which merely provide additional information entities which support it. Header fields which merely provide
pertinent to a request or a response are acceptable; these additional information pertinent to a request or a response are
headers are thus expected to have few, if any, implications for acceptable; these header fields are thus expected to have few, if
interoperability and backwards compatibility. Similarly, headers any, implications for interoperability and backwards
which provide data consumed by applications at the ends of SIP's compatibility. Similarly, header fields which provide data
rendez-vous function, rather than changing the behavior of the consumed by applications at the ends of SIP's rendez-vous
rendez-vous function, are likely to be information in this sense. function, rather than changing the behavior of the rendez-vous
If the headers redefine or contradict normative behavior defined function, are likely to be information in this sense. If the
header fields redefine or contradict normative behavior defined
in standards track SIP specifications, that is what is meant by in standards track SIP specifications, that is what is meant by
significantly different behavior. Ultimately, the significance significantly different behavior. Ultimately, the significance
of differences in behavior is a judgment call that must be made of differences in behavior is a judgment call that must be made
by the expert reviewer. by the expert reviewer.
2. The proposed header MUST NOT undermine SIP security in any sense. 2. The proposed header field MUST NOT undermine SIP security in any
The Internet Draft proposing the new header MUST address security sense. The Internet Draft proposing the new header field MUST
issues in detail as if it were a Standards Track document. Note address security issues in detail as if it were a Standards Track
that, if the intended application scenario makes certain document. Note that, if the intended application scenario makes
assumptions regarding security, the security considerations only certain assumptions regarding security, the security
need to meet the intended application scenario rather than the considerations only need to meet the intended application
general Internet case. In any case, security issues need to be scenario rather than the general Internet case. In any case,
discussed for arbitrary usage scenarios (including the general security issues need to be discussed for arbitrary usage
Internet case). scenarios (including the general Internet case).
Note that the deprecation of the "P-" header process does not alter Note that the deprecation of the "P-" header field process does not
processes for the registration of SIP methods, URI parameters, alter processes for the registration of SIP methods, URI parameters,
response codes, or option tags. response codes, or option tags.
4.1. SIP Event Packages 4.1. SIP Event Packages
SIP events [6] defines two different types of event packages: normal SIP events [RFC3265] defines two different types of event packages:
event packages, and event template-packages. Event template-packages normal event packages, and event template-packages. Event template-
can only be created and registered by the publication of a Standards packages can only be created and registered by the publication of a
Track RFC (from an IETF Working Group). Normal event packages can be Standards Track RFC (from an IETF Working Group). Note that the
created and registered by the publication of any Working Group RFC guidance in RFC3265 states that the IANA registration policy for
(Informational, Standards Track, Experimental), provided that the RFC normal event packages is "First Come First Serve"; this document
is a chartered working group item. Note that the guidance in RFC3265 replaces that policy with the following:
states that the IANA registration policy for normal event packages is
"First Come First Serve"; this document replaces that policy with the
following:
Individuals may wish to publish SIP Event packages that they believe Individuals may wish to publish SIP Event packages that they believe
fall outside the scope of any chartered work currently in RAI. fall outside the scope of any chartered work currently in RAI.
Individual proposals for registration of a SIP event package MUST Individual proposals for registration of a SIP event package MUST
first be published as Internet-drafts for review by the DISPATCH first be published as Internet-drafts for review by the DISPATCH
Working Group, or the working group, mailing list, or expert Working Group, or the working group, mailing list, or expert
designated by the RAI Area Directors if the DISPATCH Working Group designated by the RAI Area Directors if the DISPATCH Working Group
has closed. Proposals should include a strong motivational section, has closed. Proposals should include a strong motivational section,
a thorough description of the proposed syntax and semantics, event a thorough description of the proposed syntax and semantics, event
package considerations, security considerations, and examples of package considerations, security considerations, and examples of
usage. Authors should submit their proposals as individual Internet- usage. Authors should submit their proposals as individual Internet-
Drafts, and post an announcement to the working group mailing list to Drafts, and post an announcement to the working group mailing list to
begin discussion. The DISPATCH Working Group will determine if a begin discussion. The DISPATCH Working Group will determine if a
proposed package is a) an appropriate usage of SIP which should be proposed package is a) an appropriate usage of SIP which should be
spun into a new effort, b) applicable to SIP but not sufficiently spun into a new effort, b) applicable to SIP but not sufficiently
interesting, general, or in-scope to adopt as a working group effort, interesting, general, or in-scope to adopt as a working group effort,
c) contrary to similar work chartered in an existing effort, or d) c) contrary to similar work chartered in an existing effort, or d)
should be adopted as or merged with chartered work. recommended to be adopted as or merged with chartered work elsewhere
in RAI.
"RFC Required" (as defined in RFC5226) is the procedure for "RFC Required" in conjunction with "Designated Expert" (both as
registration of event packages developed outside the scope of an IETF defined in RFC5226) is the procedure for registration of event
working group, according to the following guidelines: packages developed outside the scope of an IETF working group,
according to the following guidelines:
1. A Designated Expert (as defined in RFC5226) must review the 1. A Designated Expert (as defined in RFC5226) must review the
proposal for applicability to SIP and conformance with these proposal for applicability to SIP and conformance with these
guidelines. The Designated Expert will send email to the IESG on guidelines. The Designated Expert will send email to the IESG on
this determination. The expert reviewer can cite one or more of this determination. The expert reviewer can cite one or more of
the guidelines that have not been followed in his/her opinion. the guidelines that have not been followed in his/her opinion.
2. The proposed extension MUST NOT define an event template-package. 2. The proposed extension MUST NOT define an event template-package.
3. The function of the proposed package MUST NOT overlap with 3. The function of the proposed package MUST NOT overlap with
current or planned chartered packages. current or planned chartered packages.
4. The event package MUST NOT redefine or contradict the normative 4. The event package MUST NOT redefine or contradict the normative
behavior of SIP events [6], SIP [3], or related standards track behavior of SIP events [RFC3265], SIP [RFC3261], or related
extensions. (See Section 4) standards track extensions. (See Section 4)
5. The proposed package MUST NOT undermine SIP security in any 5. The proposed package MUST NOT undermine SIP security in any
sense. The Internet Draft proposing the new package MUST address sense. The Internet Draft proposing the new package MUST address
security issues in detail as if it were a Standards Track security issues in detail as if it were a Standards Track
document. Security issues need to be discussed for arbitrary document. Security issues need to be discussed for arbitrary
usage scenarios (including the general Internet case). usage scenarios (including the general Internet case).
6. The proposed package MUST be clearly documented in an 6. The proposed package MUST be clearly documented in an
(Individual) Informational RFC, and registered with IANA. The (Individual) Informational RFC, and registered with IANA. The
package MUST document all the package considerations required in package MUST document all the package considerations required in
Section 5 of SIP events [6]. Section 5 of SIP events [RFC3265].
7. If determined by the Designated Expert or the chairs or ADs of 7. If determined by the Designated Expert or the chairs or ADs of
the DISPATCH WG, an applicability statement in the Informational the DISPATCH WG, an applicability statement in the Informational
RFC MUST clearly document the useful scope of the proposal, and RFC MUST clearly document the useful scope of the proposal, and
explain its limitations and why it is not suitable for the explain its limitations and why it is not suitable for the
general use of SIP in the Internet. general use of SIP in the Internet.
5. Summary 5. Summary
1. Documents that update or obsolete RFC 3261 through 3265 must 1. Documents that update or obsolete RFC 3261 through 3265 must
advance through the SIPCORE WG. advance through the SIPCORE WG.
2. Standard SIP extensions which do not update RFC 3261 through 2. Standard SIP extensions which do not update RFC 3261 through
3265, including event packages, may advance through chartered 3265, including event packages, may advance through chartered
activity in any RAI Area WG, or with the agreement of the RAI ADs activity in any RAI Area WG, or with the agreement of the RAI ADs
any IETF working group that constitutes an appropriate venue. any IETF working group that constitutes an appropriate venue.
3. Documents that specify Informational headers pass through an 3. Documents that specify Informational header fields pass through
Expert Review system. an Expert Review system.
6. Security Considerations 6. Security Considerations
Complex and indeterminate and hard-to-define protocol behavior, Complex and indeterminate and hard-to-define protocol behavior,
depending on the interaction of many optional extensions, is a fine depending on the interaction of many optional extensions, is a fine
breeding ground for security flaws. breeding ground for security flaws.
All Internet-Drafts that present new requirements for SIP must All Internet-Drafts that present new requirements for SIP must
include a discussion of the security requirements and implications include a discussion of the security requirements and implications
inherent in the proposal. All RFCs that modify or extend SIP must inherent in the proposal. All RFCs that modify or extend SIP must
show that they have adequate security and do not worsen SIP's show that they have adequate security, must consider the security
existing security considerations. implications of feature interactions, and most of all must not worsen
SIP's existing security considerations.
7. IANA Considerations 7. IANA Considerations
RFC 3261 [3] directs the Internet Assigned Numbers Authority (IANA) RFC 3261 [RFC3261] directs the Internet Assigned Numbers Authority
to establish a registry for SIP method names, a registry for SIP (IANA) to establish a registry for SIP method names, a registry for
option tags, and a registry for SIP response codes, and to amend the SIP option tags, and a registry for SIP response codes, and to amend
practices used for the existing registry for SIP headers. the practices used for the existing registry for SIP header fields.
Reiterating the guidance of RFC3261, method names, option tags and Reiterating the guidance of RFC3261, method names, option tags and
SIP response codes require a Standards Action for inclusion in the SIP response codes require a Standards Action for inclusion in the
IANA registry. Authors of specifications should also be aware that IANA registry. Authors of specifications should also be aware that
the SIP parameter registry is further elaborated in RFC3968 the SIP parameter registry is further elaborated in RFC3968
[RFC3968]. [RFC3968].
Previously in RFC3427, all new SIP header registrations required a Previously in RFC3427, all new SIP header field registrations
Standards Action (per RFC5226) with the exception of "P-" headers; required a Standards Action (per RFC5226) with the exception of "P-"
now, Informational registration of non-"P-" headers is permitted if header fields; now, Informational registration of non-"P-" header
approved by a Designated Expert, as described in Section 4. fields is permitted if approved by a Designated Expert, as described
in Section 4.
Each RFC shall include an IANA Considerations section which directs Each RFC shall include an IANA Considerations section which directs
IANA to create appropriate registrations. Registration shall be done IANA to create appropriate registrations. Registration shall be done
at the time the IESG announces its approval of the draft containing at the time the IESG announces its approval of the draft containing
the registration requests. the registration requests.
Standard headers and messages MUST NOT begin with the leading Standard header fields and messages MUST NOT begin with the leading
characters "P-". Existing "P-" header registrations are considered characters "P-". Existing "P-" header field registrations are
grandfathered, but new registrations of Informational headers should considered grandfathered, but new registrations of Informational
not begin with the leading characters "P-" (unless the "P-" would header fields should not begin with the leading characters "P-"
preserve compatibility with an pre-existing unregistered usage of the (unless the "P-" would preserve compatibility with an pre-existing
header, at the discretion the Designated Expert). Short forms of unregistered usage of the header field, at the discretion the
headers MUST only be assigned to standards track headers. Designated Expert). Short forms of header fields MUST only be
assigned to standards track header fields.
Similarly, RFC 3265 [6] directs the IANA to establish a registry for Similarly, RFC 3265 [RFC3265] directs the IANA to establish a
SIP event packages and SIP event template packages. For event registry for SIP event packages and SIP event template packages. For
template packages, registrations must follow the RFC5226 processes event template packages, registrations must follow the RFC5226
for Standards Action. For ordinary event packages, as stated processes for Standards Action within an IETF working group. For
previously registrations require RFC5226 IETF Review. In either normal event packages, as stated previously registrations minimally
case, the IESG announcement of approval authorizes IANA to make the require RFC5226 "RFC Required" with "Designated Expert". In either
registration. case, the IESG announcement of RFC approval authorizes IANA to make
the registration.
7.1. Clarification of RFC3969 7.1. Clarification of RFC3969
RFC3969 [4] stipulates that the (original) RFC2434 rule of RFC3969 [RFC3969] stipulates that the (original) RFC2434 rule of
"Specification Required" applies to registrations of new SIP URI "Specification Required" applies to registrations of new SIP URI
parameters; however Section 3 of that same document mandates that a parameters; however Section 3 of that same document mandates that a
standards action is required to register new parameters with the standards action is required to register new parameters with the
IANA. This contradiction arose from a misunderstanding of the nature IANA. This contradiction arose from a misunderstanding of the nature
of the RFC2434 categories; the intention was for the IANA of the RFC2434 categories; the intention was for the IANA
Considerations to mandate that Standards Action is required. Considerations to mandate that Standards Action is required.
8. Changelog 8. Overview of changes to RFC3427
8.1. Changes from RFC3427bis-00
Changed description of the SIP and SIPPING WG functions to the
SIPCORE and DISPATCH WG functions.
Deprecated the process for "P-" header registration.
Updated the document to reflect the publication of RFC5226.
Numerous informative changes motivating some of the above.
8.2. Changes from RFC3427
References to the Transport Areas have been changed to point to This section provides a high-level overview of the changes between
the RAI ADs. this document and RFC 3427. It is not a substitute for the document
as a whole - the details are necessarily not represented.
Rewrote IANA registry requirements in terms of RFC2434bis. This document:
Updated list of working groups at the end of Section 3. 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.
Clarified that the original RFC3427 altered the IANA registration 2. Deprecates the process for "P-" header field registration, and
policy of RFC3265. changes the requirements for registration of SIP header fields of
a purely informational nature.
Clarified the IANA registration policy in 3969. 3. Updates IANA registry requirements, reflecting the publication of
RFC 5226, clarifying the policies in RFC 3969, clarifying that
the original RFC 3237 updated the policies in RFC 3265.
9. Acknowledgments 9. Acknowledgments
The credit for the notion that SIP required careful management The credit for the notion that SIP required careful management
belongs to the original authors: Allison Mankin, Scott Bradner, Rohan belongs to the original authors: Allison Mankin, Scott Bradner, Rohan
Mahy, Dean Willis, Joerg Ott, and Brian Rosen. The current editors Mahy, Dean Willis, Joerg Ott, and Brian Rosen. The current editors
have provided only an update to reflect lessons learned from running have provided only an update to reflect lessons learned from running
the code, the changing situation of the IETF and the IANA the code, the changing situation of the IETF and the IANA
registration procedures. Gonzalo Camarillo was instrumental to the registration procedures. Gonzalo Camarillo was instrumental to the
development of the concept of SIPCORE and DISPATCH. Useful comments development of the concept of SIPCORE and DISPATCH. Useful comments
were provided by Jonathan Rosenberg, Mary Barnes, Dan York, John were provided by Jonathan Rosenberg, Mary Barnes, Dan York, John
Elwell, Alan Johnston, Spencer Dawkins, Russ Housley and Dean Willis. Elwell, Alan Johnston, Spencer Dawkins, Alfred Hines, Russ Housley
and Dean Willis. The thorough review from Stephen Hanna of the
Security Directorate proved enormously valuable. The authors also
appreciaed IESG feedback from Alexey Melnikov, Adrian Farrel, Dan
Romascanu and Magnus Westerlund.
The original authors thanked their IESG and IAB colleagues The original authors thanked their IESG and IAB colleagues
(especially Randy Bush, Harald Alvestrand, John Klensin, Leslie (especially Randy Bush, Harald Alvestrand, John Klensin, Leslie
Daigle, Patrik Faltstrom, and Ned Freed) for valuable discussions of Daigle, Patrik Faltstrom, and Ned Freed) for valuable discussions of
extensibility issues in a wide range of protocols, including those extensibility issues in a wide range of protocols, including those
that our area brings forward and others. Thanks to the many members that our area brings forward and others. Thanks to the many members
of the SIP community engaged in interesting dialogue about this of the SIP community engaged in interesting dialogue about this
document as well; including and especially Jonathan Rosenberg, document as well; including and especially Jonathan Rosenberg,
Henning Schulzrinne and William Marshall. Henning Schulzrinne and William Marshall.
skipping to change at page 19, line 23 skipping to change at page 20, line 23
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. 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 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
10.2. Informative References 10.2. Informative References
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
 End of changes. 52 change blocks. 
194 lines changed or deleted 201 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/