Network Working Group K. Drage
Internet-Draft Alcatel-Lucent
Expires: January 8, 2009 July 7, 2008
Suggested process changes for handling new SIP headers and SIP responses
draft-drage-rai-sip-header-process-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 8, 2009.
Drage Expires January 8, 2009 [Page 1]
Internet-Draft SIP header and response process July 2008
Abstract
RFC 3427 currently defines the process for defining and registering
new SIP header fields. This document proposes that prefixs to header
field names should be discontinued, and that an additional category
of experimental header field should be created. This document also
relaxes the requirement that response codes are defined by standards
track RFCs, also allowing them to be defined by experimental RFCs.
Drage Expires January 8, 2009 [Page 2]
Internet-Draft SIP header and response process July 2008
1. Introduction
RFC 3427 [RFC3427] defines the process for defining and registering
new SIP header fields. RFC 3427 identifies two types of header
fields. The first category is that of a "full" header. These are
defined by a standards track RFC by the SIP working group. The
second category is the "preliminary", "private" or "proprietary"
header. These are normally defined by an informational RFC
(frequently AD sponsored), and carry the prefix "P-".
RFC 3427 [RFC3427] is currently being revised due to changes in the
structure of the IETF WG and areas, and the revision exists as
draft-peterson-rai-rfc3427bis [rfc3427bis].
A previous chartered item in the SIP WG pertaining to the definition
of end-to-middle security draft-ietf-sip-e2m-sec [sip-e2m-sec] was
unable to proceed through IESG as the contents were not yet regarded
as fit for standards track, but this document could have
appropriately proceeded as experimental. However the document
defined new headers and new response codes, both of which required a
standards track RFC for conformance with the provisions of RFC 3427
[RFC3427]. At the time there seemed to be widespread agreement that
this was an inappropriate restriction, and draft-ietf-sip-e2m-sec
[sip-e2m-sec] had consensus in the SIP WG to proceed as experimental.
This also raises the issue that once a new header is approved, and
presumably implementations exist to that header, then there might
need to be change of category of that header, e.g. "private" to
standards track or "experimental" to standards track. Currently such
a change would mean that the header name itself would change, and
therefore all current implementations would become invalid. There is
no technical requirement that the header name should have such a
prefix, except to distinguish the header as one of a special class.
All SIP headers still require an IANA registration, and the IANA
registration itself can be used to appropriately distinguish the
class.
This document proposes that the rules regarding header fields and
their registration are amended to allow such cases to be dealt with.
Drage Expires January 8, 2009 [Page 3]
Internet-Draft SIP header and response process July 2008
2. Proposals
2.1. Experimental headers
It is proposed to create a new class of "experimental" header. The
process to be followed for these is identical to those for "full"
headers, with the exception that such headers are defined by an RFC
with the designation of "experimental", see RFC 2026 [RFC2026].
As a result of this proposed change, this essentially covers the
category of "preliminary" covered by the original "P-" header
designation, and therefore these headers should only be described as
"private" or "proprietary".
2.2. Removal of prefixes
In order to allow the flexibility to change the categorisation of
headers, it is proposed to remove the requirement for a prefix.
Therefore new "private" or "proprietary" headers no longer need
comment with "P-" and the new category created above will not have
the prefix "X-".
Determination of which category a header is classed as will be
represented by a new column in the IANA registration.
2.3. Definition of response codes
This document proposes to relax the requirement that response codes
are defined by standards track RFCs; the document proposes that
response codes can also be defined by experimental RFCs.
Drage Expires January 8, 2009 [Page 4]
Internet-Draft SIP header and response process July 2008
3. Detailed changes to "Change process for the Session Initiation
Protocol (SIP)"
Changes in this section are detailed against
draft-peterson-rai-rfc3427bis [rfc3427bis]. Changes to the IANA
registry are defined in the IANA considerations section of this
document.
References throughout the document to "P-" header should be changed
to "private or proprietary header", unless otherwise amended
differently in this section. Any mention of headers at this point
should not include the word "preliminary", as this function is now
taken by the experimental headers
In Section 2.1, 2nd paragraph, modify as follows:
Documents that must be handled by the SIP working group include new
SIP methods, new SIP option tags, new response codes and new
standards track SIP headers. With the exception of "Private" or
"Proprietary" headers described in Section 4.1, "Experimental"
headers described in Section 4.2, and response codes, all SIP
extensions must be standards track and must be developed in the IETF
based upon requirements provided by the SIPPING Working Group.
Response codes must be defined by either a standards track RFC or an
experimental RFC and developed by the SIP Working Group.
In Section 4, 3rd paragraph, extend as follows:
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.
Two mechanisms for such headers are provided: the first is for
"Private", or "Proprietary" headers; the second is for "Experimental"
headers.
In Section 4.1, remove the following text: "Any implementation of a
"P-" header (meaning "not specified by a standards-track RFC issued
through the SIP Working Group") MUST include a "P-" prefix on the
header, as in "P-Headername"."
Create a new Section 4.2 as with the title "Indicating an
Experimental Header" with the following contents:
Experimental SIP Headers can be registered if all of the following
conditions are met:
Drage Expires January 8, 2009 [Page 5]
Internet-Draft SIP header and response process July 2008
1. The document is progressed by the SIP WG and submitted as an
experimental RFC.
2. The proposed extension MUST NOT define SIP option tags, response
codes, or methods.
3. The function of the proposed header MUST NOT overlap with current
or planned chartered extensions.
4. The proposed header MUST NOT undermine SIP security in any sense.
The Internet Draft proposing the new header MUST address security
issues in detail as if it were a Standards Track document. Note
that, if the intended application scenario makes certain
assumptions regarding security, the security considerations only
need to meet the intended application scenario rather than the
general Internet case. In any case, security issues need to be
discussed for arbitrary usage scenarios (including the general
Internet case).
5. The registration process for proposed headers is "RFC Required"
per RFC2434bis.
6. An applicability statement in the Experimental 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.
Renumber existing Section 4.2 as Section 4.3, and existing Section
4.3 as Section 4.4.
Drage Expires January 8, 2009 [Page 6]
Internet-Draft SIP header and response process July 2008
4. Security considerations
There are no security considerations relating to this document.
Drage Expires January 8, 2009 [Page 7]
Internet-Draft SIP header and response process July 2008
5. IANA considerations
Section 6 of draft-peterson-rai-rfc3427bis [rfc3427bis] is revised as
follows:
RFC 3261 [3] 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 headers.
Reiterating the guidance of RFC3261, method names, option tags and
SIP response codes require a Standards Action for inclusion in the
IANA registry, and entries go into these registries only through
RFC2434bis Standards Action, with the following exceptions:
1. Proprietary or private headers, as stated previously
registrations require RFC2434bis IETF Review. The IESG
announcement of approval authorizes IANA to make the
registration.
2. Experimental headers, as stated previously registrations require
creation of an experimental RFC. The IESG announcement of
approval authorizes IANA to make the registration.
3. For response codes, as stated previously registrations require
either an RFC2434bis Standards Action or creation of an
experimental RFC. The IESG announcement of approval authorizes
IANA to make the registration.
This document requires that a new column is added to the SIP Header
Fields registry with the heading of "Type". Entries in this column
can take one of three values: "full", "private", or "experimental".
All existing headers with the first two characters of "P-" should
have an entry "private" included in this column". All other existing
headers should have an entry "full" included in this column. Future
RFCs defining SIP headers MUST include in the IANA considerations
section details of the appropriate entry to place in this column,
i.e. Private or Proprietary headers should include "private in this
column, and "Experimental" headers should include "experimental" in
this column. Headers defined by standards track RFCs should include
"full" in this column.
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.
Standard headers and messages MUST NOT begin with the leading
characters "P-". This is to preclude confusion with previous
Drage Expires January 8, 2009 [Page 8]
Internet-Draft SIP header and response process July 2008
registrations of proprietary or private headers.
Short forms of headers MUST only be assigned to standards track
headers. In other words, private, proprietary or experimental
headers MUST NOT have short forms.
Similarly, RFC 3265 [6] directs the IANA to establish a registry for
SIP event packages and SIP event template packages. For event
template packages, registrations must follow the RFC2434bis processes
for Standards Action. For ordinary event packages, as stated
previously registrations require RFC2434bis IETF Review. In either
case, the IESG announcement of approval authorizes IANA to make the
registration.
Drage Expires January 8, 2009 [Page 9]
Internet-Draft SIP header and response process July 2008
6. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", October 1996.
[RFC3427] Mankin, A., "Change Process for the Session Initiation
Protocol (SIP)", December 2002.
[rfc3427bis]
Peterson, J. and C. Jennings, "Change Process for the
Session Initiation Protocol (SIP). Work in progress",
February 2008.
[sip-e2m-sec]
Ono, K. and S. Tachimoto, "End-to-middle Security in the
Session Initiation Protocol (SIP). Work in progress",
February 2008.
Drage Expires January 8, 2009 [Page 10]
Internet-Draft SIP header and response process July 2008
Author's Address
Keith Drage
Alcatel-Lucent
Quadrant, StoneHill Green, Westlea
Swindon, Wilts
UK
Email: drage@alcatel-lucent.com
Drage Expires January 8, 2009 [Page 11]
Internet-Draft SIP header and response process July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Drage Expires January 8, 2009 [Page 12]