One document matched: draft-peterson-rai-rfc3427bis-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3261 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc3265 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml'>
<!ENTITY rfc3325 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml'>
<!ENTITY rfc3427 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3427.xml'>
<!ENTITY rfc3968 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3968.xml'>
<!ENTITY rfc3969 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3969.xml'>
<!ENTITY rfc5111 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5111.xml'>
<!ENTITY rfc5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
]>
<rfc category="bcp" ipr="pre5378Trust200902" obsoletes="3427" updates="3265,3969" docName="draft-peterson-rai-rfc3427bis-04">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="SIP change">
Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area</title>
<author initials='J.' surname="Peterson" fullname='Jon Peterson'>
<organization>NeuStar, Inc.</organization>
<address>
<email>jon.peterson@neustar.biz</email>
</address>
</author>
<author initials='C.' surname="Jennings" fullname='Cullen Jennings'>
<organization>Cisco Systems</organization>
<address>
<email>fluffy@cisco.com</email>
</address>
</author>
<author initials='R.' surname="Sparks" fullname='Robert Sparks'>
<organization>Tekelec</organization>
<address>
<email>rjsparks@nostrum.com</email>
</address>
</author>
<date/>
<abstract><t>
This memo documents a process intended to organize the future 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, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP.
This document therefore defines the functions of two long-lived working groups in the RAI Area which are, respectively, responsible for the maintenance of the core SIP specifications and development of new efforts to extend and apply work in this space. This document obsoletes RFC3427.
</t></abstract>
</front>
<middle>
<section title="Terminology">
<t>
In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD",
and "SHOULD NOT", are to be interpreted as described in
<xref target="RFC2119"/>. This document additionally uses <xref target="RFC5226"/> language to describe IANA
registrations.
</t>
</section>
<section anchor="history" title="History and Development">
<t>
The <xref target="RFC3261">Session Initiation Protocol (SIP)</xref> has grown well beyond its origins in
Internet-based
multimedia sessions, and now enjoys widespread popularity in Voice over IP or IP telephony applications, both inside IETF and within other standards groups. One result of this popularity has
been a continual flood of proposals for SIP modifications and
extensions. The challenge for IETF management of SIP has been to preserve baseline interoperability across its many implementations
</t><t>
In order to defend SIP against changes that might reduce interoperability, the working group chairs and Area Directors responsible for its management authored the <xref target="RFC3427">SIP change process</xref>. SIP change defined the role of the SIP and SIPPING working groups in shepherding ongoing work on the SIP standard. It also defined ways that external working groups or bodies could define extensions intended for limited usage, especially through the "P-" header field mechanism.
</t><t>
Over time, however, the management structure of RFC3427 has demonstrated some limitations. The first and most significant of these concerns "P-" header fields. While "P-" header fields require expert review and IESG shepherding, in practice IETF oversight of these header fields is quite limited, and the value added by the IETF supervising their development remains unclear. More importantly, the presence of a "P-" in front of a header field name does nothing to prevent a popular header field from seeing deployment outside of the original "limited usage" it envisioned; a prominent example of this today is the P-Asserted-Identity (PAID) header field, described in <xref target="RFC3325">RFC3325</xref>.
</t><t>
Consequently, this document obsoletes RFC3427 and describes a new structure for the management of deliverables in the Real-time Applications and Infrastructure Area.
</t>
<section anchor="sipwg" title="The IETF SIPCORE Working Group">
<t>
Historically, the IETF SIP Working Group (sip) was chartered to be the "owner"
of the <xref target="RFC3261">SIP protocol</xref> for the duration of the working group. All
changes or extensions to SIP were first required to exist as SIP Working Group
documents. The SIP working group was charged with being the guardian
of the SIP protocol for the Internet, and therefore was mandated only
to extend or change the SIP protocol when there are compelling reasons
to do so.
</t><t>
The SIPCORE working group replaces the function of the SIP working group in the original RFC3427 account.
Documents that must be handled by the SIPCORE working group include all documents which update or obsolete RFC3261 through RFC3265 or their successors. All SIP extensions considered in SIPCORE must be standards track. They may be based upon requirements developed externally in other IETF working groups.
</t><t>
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 core SIP development will continue. In the event that the SIPCORE working
group has closed and no suitable replacement or follow-on working
group is active (and this specification also has not been superseded), then when modifications to the core SIP protocol are proposed the RAI Area Directors will use the non-working
group standards track document process (described in Section 6.1.2 of
<xref target="RFC2026">RFC 2026</xref>) using the SIPCORE
mailing list and designated experts from the SIP community for
review.
</t><t>
It is appropriate for any IETF working group to develop <xref target="RFC3265">SIP event packages</xref>, but the working group must have charter approval to do so. The
IETF will also require RFC5226 IETF Review for the registration of
event packages developed outside the scope of an IETF working group.
Instructions for event package registrations are provided in
<xref target="event"/>.
</t>
</section>
<section anchor="sipping" title="The IETF DISPATCH Working Group">
<t>
Historically, the IETF Session Initiation Protocol Proposal Investigation (sipping)
Working Group was chartered to be a filter in front of the SIP Working
Group. This working group investigated requirements for
applications of SIP, some of which led to requests for
extensions to SIP. These requirements may come from the community at
large, or from individuals who are reporting the requirements as
determined by another standards body.
</t><t>
The DISPATCH working group replaces the function of the SIPPING WG, although with several important changes to its functionality, the most notable being that its scope expands beyond just SIP to the entire work of the RAI Area. Like SIPPING, DISPATCH considers new proposals for work in the RAI Area, but rather than taking on specification deliverables as charter items itself, DISPATCH identifies the proper venue for work. If no such venue yet exists in the RAI Area, DISPATCH will develop charters and consensus for a BoF, working group, or <xref target="RFC5111">exploratory group</xref> as appropriate. Unlike the previous change structure, a DISPATCH review of any proposed change to core SIP is not required before it progresses to SIPCORE; however, any new proposed work which does not clearly fall within the charter of an existing RAI Area effort should be examined by DISPATCH.
</t><t>
In reaction to a proposal, the DISPATCH Working Group may determine: that these requirements justify a change to the core SIP specifications (RFC3261 through RFC3265) and thus any resulting work must transpire in SIPCORE, that the requirements do not change the 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 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 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. DISPATCH should act as a filter,
accepting only proposals which play to the strengths of SIP, not those that confuse its applicability or ultimately reduce its usefulness as a means for immediate personal communications on the Internet.
</t><t>
In practice, it is expected that the DISPATCH WG behaves as a RAI "Open Area" working group, similar to those employed in other areas of the IETF. While it does not have the traditional deliverables of a working group, DISPATCH may at the discretion of its chairs and Area Directors adopt milestones, in accordance with standard working group milestone adoption procedures, such as the production of charter text for a BoF or working group, a "-00" problem statement document that explicates a proposed work effort, or a document explaining why a particular direction for standards development was not pursued.
</t>
</section>
</section>
<section anchor="change" title="Introducing New Work to RAI">
<t>
When proposals arise for modifications or extensions to SIP outside the scope of existing chartered RAI Area work, they must be written up as a problem statement
(preferably as an Internet-Draft) explaining the problem they are trying to
solve, why SIP is the applicable protocol, and why the existing SIP
protocol will not work. The problem statement must include a detailed
set of requirements (distinct from solutions) that SIP would need to
meet to solve the particular problem. The problem statement must also
describe in detail any security issues that arise from meeting those
requirements. After the problem statement is published, the authors
should send a note to the DISPATCH Working Group mailing list to start
discussion on the problem.
</t><t>
The DISPATCH working group chairs, in conjunction with the RAI Area
Directors, will determine if the particular problems raised in the
requirements problem statement are indeed outside the charter of existing efforts, and if so, if they warrant a DISPATCH milestone for the definition of a new effort; this DISPATCH deliverable may take the form of a problem statement Internet-Draft, charter or similar milestone that provides
enough information to make a decision, but must not include protocol development. The DISPATCH working
group should consider whether the requirements can be merged with
other requirements from other applications, and refine the problem statement
accordingly.
</t><t>
Once a new effort has been defined in DISPATCH and there is working group consensus that it should go forward, if the new effort will take the form of a working group or BoF, then the ADs
will present the proposed new effort charter to the IESG
and IAB, in accordance with the usual chartering process. If the new effort involves the rechartering of an existing working group, then similarly the existing working group rechartering functions will be performed by the appropriate WG chairs and ADs.
If the IESG (with IAB advice) approves of the new charter or BoF, the
DISPATCH working group has completed its deliverable and the new effort becomes autonomous.
</t><t>
Anyone proposing requirements for new work is welcome to jointly develop, in a separate Internet-Draft, a mechanism that would meet the requirements. No working group is required to adopt the
proposed solution from this additional Internet-Draft.
</t><t>
Work overseen by the SIPCORE Working Group is required to protect the architectural
integrity of SIP and must not add features that do not have general
use beyond the specific case. Also, SIPCORE must not add features just
to make a particular function more efficient at the expense of
simplicity or robustness.
</t><t>
Some working groups generate requirements for SIP
solutions and/or extensions. At the time this document was
written, some groups with such chartered deliverables include SIP for Instant Messaging and Presence
Leveraging Extensions (simple), Basic Level of Interoperability for
SIP Services (bliss) and Session Peering for Multimedia Interconnect
(speermint).
</t><t>
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 working group handling extensions to SIP
requests the addition of a charter item for an extension without a
full DISPATCH process as described.
</t>
</section>
<section anchor="extend" title="Extensibility and Architecture">
<t>
In an idealized protocol model, extensible design would be self-
contained, and it would be inherent that new extensions and new
header fields would naturally have an architectural coherence with the
original protocol.
</t><t>
However, this idealized vision has not been attained in the world of
standards track protocols. While interoperability implications can
be addressed by capabilities negotiation rules, the effects of adding
features that overlap, or that deal with a point solution and are
not general, are much harder to control with rules. Therefore, the RAI Area
calls for architectural guardianship and application of Occam's Razor
by the SIPCORE and DISPATCH Working Groups.
</t><t>
In keeping with the IETF tradition of "running code and rough
consensus", it is valid to allow for the development of SIP
extensions that are either not ready for standards track, but might
be understood for that role after some running code, or are private
or proprietary in nature, because a characteristic motivating them is
usage that is known not to fit the Internet architecture for SIP. In the past, header fields associated with those extensions were called "P-" header fields, for "preliminary", "private", or
"proprietary".
</t><t>
However, the "P-" header field process has not served the purpose for which it was designed - namely, to restrict to closed environments the usage of mechanisms the IETF would not (yet) endorse for general usage. In fact, some "P-" header fields have enjoyed widespread implementation; because of the "P-" prefix, however, there seems to be no plausible migration path to designate these as general-usage header fields without trying to force implausible changes on large installed bases.
</t><t>
Accordingly, this specification deprecates the previous RFC3427 guidance on the creation of "P-" header fields. Existing "P-" header fields are to be handled by user agents and proxy servers as the "P-" header field specifications describe; the deprecation of the change process mechanism entails no change in protocol behavior. New proposals to document SIP header fields of an experimental or private nature, however, shall not use the 'P-" prefix (unless existing deployments or standards use the prefix already, in which case they may be admitted as grandfathered cases at the discretion of the Designated Expert).
</t><t>
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 chartered work in the RAI Area, and are furthermore instructed to ensure the following two criteria are met:
</t><t><list style="numbers"><t>
The proposed header field MUST be of a purely informational nature, and
MUST NOT significantly change the behavior of SIP entities which
support it. Header fields which merely provide additional information
pertinent to a request or a response are acceptable; these header fields are thus expected to have few, if any, implications for interoperability and backwards compatibility. Similarly, header fields which provide data consumed by applications at the ends of SIP's rendez-vous function, rather than changing the behavior of the rendez-vous 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
significantly different behavior. Ultimately, the significance of differences in behavior is a judgment call that must be made by the expert reviewer.
</t><t>
The proposed header field MUST NOT undermine SIP security in any sense.
The Internet Draft proposing the new header field 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).
</t></list></t><t>
Note that the deprecation of the "P-" header field process does not alter processes for the registration of SIP methods, URI parameters, response codes, or option tags.
</t>
<section anchor="event" title="SIP Event Packages">
<t>
SIP events <xref target="RFC3265"/> defines two different types of event packages: normal
event packages, and event template-packages. Event template-packages
can only be created and registered by the publication of a Standards
Track RFC (from an IETF Working Group). Note that the guidance in RFC3265
states that the IANA registration policy for normal event packages is
"First Come First Serve"; this document replaces that policy with the
following:
</t><t>
Individuals may wish to publish SIP Event packages that they believe fall outside the scope of any chartered work currently in RAI. Individual
proposals for registration of a SIP event package MUST first be
published as Internet-drafts for review by the DISPATCH Working Group,
or the working group, mailing list, or expert designated by the RAI
Area Directors if the DISPATCH Working Group has closed. Proposals
should include a strong motivational section, a thorough description
of the proposed syntax and semantics, event package considerations,
security considerations, and examples of usage. Authors should
submit their proposals as individual Internet- Drafts, and post
an announcement to the working group mailing list to begin
discussion. The DISPATCH Working Group will determine if a proposed
package is a) an appropriate usage of SIP which should be spun into a new effort, b) applicable to SIP but
not sufficiently interesting, general, or in-scope to adopt as a
working group effort, c) contrary to similar work chartered in an existing effort, or d) recommended to be adopted as or merged with chartered
work elsewhere in RAI.
</t><t>
"RFC Required" in conjunction with "Designated Expert" (both as defined in RFC5226) is the procedure for registration of event
packages developed outside the scope of an IETF working group,
according to the following guidelines:
<list style="numbers"><t>
A Designated Expert (as defined in RFC5226) must review
the proposal for applicability to SIP and conformance with these
guidelines. The Designated Expert will send email to the IESG on
this determination. The expert reviewer can cite one or more of
the guidelines that have not been followed in his/her opinion.
</t><t>
The proposed extension MUST NOT define an event template-package.
</t><t>
The function of the proposed package MUST NOT overlap with
current or planned chartered packages.
</t><t>
The event package MUST NOT redefine or contradict the normative
behavior of SIP events <xref target="RFC3265"/>, SIP <xref target="RFC3261"/>, or related standards track
extensions. (See <xref target="extend"/>)
</t><t>
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).
</t><t>
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 <xref target="RFC3265"/>.
</t><t>
If determined by the Designated Expert or the chairs or ADs of
the DISPATCH 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.
</t></list></t>
</section>
</section>
<section title="Summary">
<t>
<list style="numbers"><t>
Documents that update or obsolete RFC 3261 through 3265 must advance through the SIPCORE WG.
</t><t>
Standard SIP extensions which do not update RFC 3261 through 3265, including event packages, may advance through chartered
activity in any RAI Area WG, or with the agreement of the RAI ADs any IETF working group that
constitutes an appropriate venue.
</t><t>
Documents that specify Informational header fields pass through an Expert Review system.
</t></list></t>
</section>
<section title="Security Considerations">
<t>
Complex and indeterminate and hard-to-define protocol behavior,
depending on the interaction of many optional extensions, is a fine breeding
ground for security flaws.
</t><t>
All Internet-Drafts that present new requirements for SIP must
include a discussion of the security requirements and implications
inherent in the proposal. All RFCs that modify or extend SIP must
show that they have adequate security, must consider the security implications of feature interactions, and most of all must not worsen SIP's
existing security considerations.
</t>
</section>
<section title="IANA Considerations">
<t>
<xref target="RFC3261">RFC 3261</xref> directs the Internet Assigned Numbers Authority (IANA)
to establish a registry for SIP method names, a registry for SIP
option tags, and a registry for SIP response codes, and to amend the
practices used for the existing registry for SIP header fields.
Reiterating the guidance of RFC3261, method names, option tags and
SIP response codes require a Standards Action for inclusion in the
IANA registry. Authors of specifications should also be aware that the SIP parameter registry is further elaborated in <xref target="RFC3968">RFC3968</xref>.
</t><t>
Previously in RFC3427, all new SIP header field registrations required a Standards Action (per RFC5226) with the exception of "P-" header fields; now, Informational registration of non-"P-" header fields is permitted if approved by a Designated Expert, as described in <xref target="extend"/>.
</t><t>
Each RFC shall include an IANA Considerations section which directs
IANA to create appropriate registrations. Registration shall be done
at the time the IESG announces its approval of the draft containing
the registration requests.
</t><t>
Standard header fields and messages MUST NOT begin with the leading
characters "P-". Existing "P-" header field registrations are considered grandfathered, but new registrations of Informational header fields should not begin with the leading characters "P-" (unless the "P-" would preserve compatibility with an pre-existing unregistered usage of the header field, at the discretion the Designated Expert). Short forms of header fields MUST only be assigned to standards track
header fields.
</t><t>
Similarly, <xref target="RFC3265">RFC 3265</xref> directs the IANA to establish a registry for
SIP event packages and SIP event template packages. For event
template packages, registrations must follow the RFC5226 processes
for Standards Action within an IETF working group. For normal event packages, as stated
previously registrations minimally require RFC5226 "RFC Required" with "Designated Expert". In either
case, the IESG announcement of RFC approval authorizes IANA to make the
registration.
</t>
<section anchor="clarify" title="Clarification of RFC3969">
<t>
<xref target="RFC3969">RFC3969</xref> stipulates that the (original) RFC2434 rule of
"Specification Required" applies to registrations of new SIP URI
parameters; however Section 3 of that same document mandates that a
standards action is required to register new parameters with the
IANA. This contradiction arose from a misunderstanding of the nature
of the RFC2434 categories; the intention was for the IANA
Considerations to mandate that Standards Action is required.
</t>
</section>
</section>
<section title="Overview of changes to RFC3427">
<t>
This section provides a high-level overview of the changes between this document
and RFC 3427. It is not a substitute for the document as a whole - the details
are necessarily not represented.
</t><t>
This document:
<list style="numbers"><t>
Changes the description of the SIP and SIPPING WG functions to the
SIPCORE and DISPATCH WG functions using the context of the RAI Area.
</t><t>
Deprecates the process for "P-" header field registration, and changes the
requirements for registration of SIP header fields of a purely informational nature.
</t><t>
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.
</t></list></t>
</section>
<section anchor="ack" title="Acknowledgments">
<t>
The credit for the notion that SIP required careful management belongs to the original authors: Allison
Mankin, Scott Bradner, Rohan Mahy, Dean Willis, Joerg Ott, and Brian
Rosen. The current editors have provided only an update
to reflect lessons learned from running the code, the changing situation of the IETF and the IANA
registration procedures. Gonzalo Camarillo was instrumental to the development of the concept of SIPCORE and DISPATCH. Useful comments were provided by Jonathan Rosenberg, Mary Barnes, Dan York, John 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.
</t><t>
The original authors thanked their IESG and IAB colleagues
(especially Randy Bush, Harald Alvestrand, John Klensin, Leslie
Daigle, Patrik Faltstrom, and Ned Freed) for valuable discussions of
extensibility issues in a wide range of protocols, including those
that our area brings forward and others. Thanks to the many members
of the SIP community engaged in interesting dialogue about this
document as well; including and especially Jonathan Rosenberg,
Henning Schulzrinne and William Marshall.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2026;
&rfc2119;
&rfc3261;
&rfc3265;
&rfc3969;
&rfc5226;
</references>
<references title='Informative References'>
&rfc3427;
&rfc3325;
&rfc3968;
&rfc5111;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 00:10:15 |