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]