wdiff rfc5727.alt-original rfc5727.txt

Network Working Group J. Peterson
Internet-Draft
Request for Comments: 5727 NeuStar, Inc.
Obsoletes: 3427 (if approved) C. Jennings
Updates: 3265,3969 3265, 3969 Cisco Systems
(if approved)
Category: Standards Track R. Sparks
Intended status: BCP
Tekelec
Expires: April 26,
January 2010 October 23, 2009

Change Process for the Session Initiation Protocol (SIP)
and the Real-
time Real-time Applications and Infrastructure Area
draft-peterson-rai-rfc3427bis-04

Abstract

This memo documents a process intended to organize the future
development of the Session Initiation Protocol (SIP) and related work
in the Real-Time 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 that are, respectively, responsible for the maintenance
of the core SIP specifications and the development of new efforts to
extend and apply work in this space. This document obsoletes
RFC3427. RFC
3427.

Status of this This Memo

This Internet-Draft document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is submitted unlimited.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in full conformance with effect on the
provisions date of BCP 78
publication of this document. Please review these documents
carefully, as they describe your rights and BCP 79. restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 26, 2010.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Table of Contents

1. Terminology History and Development . . . . . . . . . . . . . . . . . . . 3
1.1. The IETF SIPCORE Working Group . . . . . . 4
2. History and Development . . . . . . . . 3
1.2. The IETF DISPATCH Working Group . . . . . . . . . . . 5
2.1. The IETF SIPCORE Working Group . . 4
2. Terminology . . . . . . . . . . . . 5
2.2. The IETF DISPATCH Working Group . . . . . . . . . . . . . 6 5
3. Introducing New Work to RAI . . . . . . . . . . . . . . . . . 8 5
4. Extensibility and Architecture . . . . . . . . . . . . . . . . 10 7
4.1. SIP Event Packages . . . . . . . . . . . . . . . . . . . . 11 8
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10
7.1. Clarification of RFC3969 . RFC 3969 . . . . . . . . . . . . . . . . 16 11
8. Overview of changes Changes to RFC3427 . RFC 3427 . . . . . . . . . . . . . . . 18 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21

1. Terminology

In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD",
and "SHOULD NOT", are to be interpreted as described in [RFC2119].
This document additionally uses [RFC5226] language to describe IANA
registrations.

2. . . . . . 13

1. History and Development

The Session Initiation Protocol (SIP) [RFC3261] has grown well beyond
its origins in Internet-based multimedia sessions, sessions and now enjoys
widespread popularity in Voice over IP 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

In order to defend SIP against changes that might reduce
interoperability, the working group chairs and Area Directors
responsible for its management authored the SIP change process
[RFC3427]. SIP change That document defined the role of the SIP and SIPPING
working groups
Working Groups (WGs) in shepherding ongoing work on the SIP standard.
It also defined ways that external working groups or bodies could can
define extensions intended for limited usage, especially through the
"P-" header field mechanism.

Over time, however, the management structure of RFC3427 RFC 3427 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
RFC3325 [RFC3325].

Consequently, this document obsoletes RFC3427 RFC 3427 and describes a new
structure for the management of deliverables in the Real-time
Applications and Infrastructure Area.

2.1.

1.1. The IETF SIPCORE Working Group

Historically, the IETF SIP Working Group (sip) was chartered to be
the "owner" of the SIP protocol [RFC3261] 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 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 were compelling reasons to do so.

The SIPCORE working group Working Group replaces the function of the SIP working
group Working
Group in the original RFC3427 [RFC3427] account. Documents that must be
handled by the SIPCORE working group Working Group include all documents which that
update or obsolete RFC3261 RFCs 3261 through RFC3265 3265 or their successors. All
SIP extensions considered in SIPCORE must be standards track. Standards Track. They
may be based upon requirements developed externally in other IETF
working groups.

Typical IETF working groups do not live forever; however, 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
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
proposed, the RAI Area Directors will use the non-working group
standards track non-working-group
Standards Track document process (described in Section 6.1.2 of RFC
2026 [RFC2026]) using the SIPCORE mailing list and designated experts Designated Experts
from the SIP community for review.

It is appropriate for any IETF working group to develop SIP event
packages [RFC3265], but the working group must have charter approval
to do so. The IETF will also require RFC5226 [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 Section 4.1.

2.2.

1.2. The IETF DISPATCH Working Group

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, large or from individuals who are reporting the
requirements as determined by another standards body.

The DISPATCH working group Working Group replaces the function of the SIPPING WG,
although with several important changes to its functionality, 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 exploratory group [RFC5111] 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 that 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:
that determine
that:

1. these requirements justify a change to the core SIP
specifications (RFC3261 (RFCs 3261 through RFC3265) 3265) and thus any resulting
work must transpire in SIPCORE, that the SIPCORE;

2. these requirements do not change the SIP core specifications but
require a new effort in the RAI area Area (be that a working group, a
BoF, or what have you), that the you);

3. these requirements fall within the scope of existing chartered
work in the RAI Area, Area; or
that

4. 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 that 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.

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 may, at the discretion of its chairs and
Area Directors Directors, adopt milestones, milestones in accordance with standard working
group milestone adoption 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.

2. Terminology

In this document, the key words "MAY", "MUST", "MUST NOT", "SHOULD",
and "SHOULD NOT", are to be interpreted as described in [RFC2119].
This document additionally uses [RFC5226] language to describe IANA
registrations.

3. Introducing New Work to RAI

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.

The DISPATCH working group 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 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 charter, or similar
milestone that provides enough information to make a decision, but
must not include protocol development. The DISPATCH working group Working Group
should consider whether the requirements can be merged with other
requirements from other applications, and refine the problem
statement accordingly.

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 Working Group has
completed its deliverable and the new effort becomes autonomous.

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.

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.

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) (bliss), and Session Peering for
Multimedia Interconnect (speermint).

The RAI ADs may, on an exceptional, case by case case-by-case basis, support a
process in which the requirements analysis is implicit and a RAI area Area
working group handling extensions to SIP requests the addition of a
charter item for an extension without a full DISPATCH process as
described.

4. Extensibility and Architecture

In an idealized protocol model, extensible design would be self-
contained, and it would be inherent that new extensions and new
header fields would naturally have an architectural coherence with
the original protocol.

However, this idealized vision has not been attained in the world of
standards track
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.

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, Standards Track, but might
be understood for that role after some running code, code or are private or
proprietary in nature, 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, fields for "preliminary", "private", or "proprietary".

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.

Accordingly, this specification deprecates the previous RFC3427 [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-" "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).

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) [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:

1. The proposed header field MUST be of a purely informational
nature,
nature and MUST NOT significantly change the behavior of SIP
entities which that support it. Header fields which that 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 that provide data
consumed by applications at the ends of SIP's rendez-vous rendezvous
function, rather than changing the behavior of the rendez-vous rendezvous
function, are likely to be providing information in this sense.
If the header fields redefine or contradict normative behavior
defined in standards track 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.

2. The proposed header field MUST NOT undermine SIP security in any
sense. The Internet Draft Internet-Draft proposing the new header field MUST
address security issues in detail 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).

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.

4.1. SIP Event Packages

SIP events [RFC3265] defines two different types of event packages:
normal event packages, 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 [RFC3265] 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
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 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,
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 that 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.

"RFC Required" in conjunction with "Designated Expert" (both as
defined in RFC5226) RFC 5226) is the procedure for registration of event
packages developed outside the scope of an IETF working group,
according to the following guidelines:

1. A Designated Expert (as defined in RFC5226) RFC 5226) 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.

2. The proposed extension MUST NOT define an event template-package.

3. The function of the proposed package MUST NOT overlap with
current or planned chartered packages.

4. The event package MUST NOT redefine or contradict the normative
behavior of SIP events [RFC3265], SIP [RFC3261], or related
standards track
Standards Track extensions. (See Section 4) 4.)
5. The proposed package MUST NOT undermine SIP security in any
sense. The Internet Draft 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, RFC and registered with IANA. The
package MUST document all the package considerations required in
Section 5 of SIP events [RFC3265].

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

5. Summary

1. Documents that update or obsolete RFC RFCs 3261 through 3265 must
advance through the SIPCORE WG.

2. Standard SIP extensions which that do not update RFC RFCs 3261 through
3265, including event packages, may advance through chartered
activity in any RAI Area WG, WG or with (with the agreement of the RAI ADs
ADs) any IETF working group that constitutes an appropriate
venue.

3. Documents that specify Informational header fields pass through
an Expert Review system.

6. Security Considerations

Complex and indeterminate

Complex, indeterminate, and hard-to-define protocol behavior,
depending on the interaction of many optional extensions, is a fine
breeding ground for security flaws.

All Internet-Drafts that present new requirements for SIP must
include a discussion of the security requirements and implications
inherent in the proposal. All RFCs that modify or extend SIP must
show that they have adequate security, must consider the security
implications of feature interactions, and most of all must not worsen
SIP's existing security considerations.

7. IANA Considerations

RFC 3261 [RFC3261] 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, RFC 3261, method names, option tags 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 RFC3968 [RFC3968].

Previously in RFC3427, RFC 3427, all new SIP header field registrations
required a Standards Action (per RFC5226) RFC 5226) 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 Section 4.

Each RFC shall include an IANA Considerations section which that directs
IANA to create appropriate registrations. Registration shall be done
at the time the IESG announces its approval of the draft containing
the registration requests.

Standard 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 a 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 Standards Track header fields.

Similarly, RFC 3265 [RFC3265] directs the IANA to establish a registry for SIP
event packages and SIP event template packages. template-packages. For event template template-
packages, registrations must follow the RFC5226 [RFC5226] processes for
Standards Action within an IETF working group. For normal event
packages, as stated previously previously, registrations minimally require RFC5226
[RFC5226] "RFC Required" with "Designated Expert". In either case,
the IESG announcement of RFC approval authorizes IANA to make the
registration.

7.1. Clarification of RFC3969

RFC3969 RFC 3969

[RFC3969] stipulates that the (original) RFC2434 [RFC2434] rule of
"Specification Required" applies to registrations of new SIP URI
parameters; however however, Section 3 of that same document mandates that a
standards action
Standards Action is required to register new parameters with the
IANA. This contradiction arose from a misunderstanding of the nature
of the RFC2434 [RFC2434] categories; the intention was for the IANA
Considerations to mandate that Standards Action is required.

8. Overview of changes Changes to RFC3427 RFC 3427

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.

This document:

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.

2. Deprecates the process for "P-" header field registration, and
changes the requirements for registration of SIP header fields of
a purely informational nature.

3. Updates IANA registry requirements, reflecting the publication of
RFC 5226, clarifying the policies in RFC 3969, and clarifying
that the original RFC 3237 updated the policies in RFC 3265.

9. Acknowledgments

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, code and from 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 Housley,
and Dean Willis. The thorough review from Stephen Hanna of the
Security Directorate proved enormously valuable. The authors also
appreciaed
appreciated IESG feedback from Alexey Melnikov, Adrian Farrel, Dan
Romascanu
Romascanu, and Magnus Westerlund.

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; well, including and especially Jonathan Rosenberg,
Henning Schulzrinne Schulzrinne, and William Marshall.

10. References

10.1. Normative References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.

[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
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
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.

10.2. Informative References

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.

[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.

[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
and B. Rosen, "Change Process for the Session Initiation
Protocol (SIP)", BCP 67, RFC 3427, December 2002.

[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004.

[RFC5111] Aboba, B. and L. Dondeti, "Experiment in Exploratory Group
Formation within the Internet Engineering Task Force
(IETF)", RFC 5111, January 2008.

Authors' Addresses

Jon Peterson
NeuStar, Inc.

Email:

EMail: jon.peterson@neustar.biz

Cullen Jennings
Cisco Systems

Email:

EMail: fluffy@cisco.com

Robert Sparks
Tekelec

Email:

EMail: rjsparks@nostrum.com