SIP D. Petrie Internet-Draft SIPez LLC. Expires: April 17, 2007 October 14, 2006 Session Initiation Protocol Response Code for Invalid Event Parameter Values draft-petrie-sip-event-param-err-00.txt 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 April 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a new error response code and header for SIP Events to indicate when an invalid value is provided in a SUBSCRIBE request Event header parameter. These changes update behavior defined in RFC 3265. Petrie Expires April 17, 2007 [Page 1]
Internet-Draft SIP Events Parameter Error October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 3 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Informational References . . . . . . . . . . . . . . . . . 5 4.2. Normative References . . . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Petrie Expires April 17, 2007 [Page 2]
Internet-Draft SIP Events Parameter Error October 2006 1. Introduction SIP Events [RFC3265] defines the SIP Event header to which Event Packages may add new parameters. [RFC3265]does not define a means to indicate that an event parameter has an invalid or unsupported value. This document defines a new SIP [RFC3261] response error code to indicate that an Event header parameter has in invalid value. This document also defines a new SIP header field to contain the parameter(s) and value(s) from the SUBSCRIBE request Event header which were invalid or unsupported. This mechanism is particularly useful for parameters that have a predefined set of values. A differentiation is not made between invalid or unsupported parameter values as the subscriber receiving the error indication will not likely be able to react differently between these two situation. In addition the notifier issuing the error response may not know the difference between an invalid or unsupported parameter value. Note: for definitions of notifier and subscriber see SIP Events [RFC3265]. SIP [RFC3261] strives to be liberal in what it receives [RFC0760] by recommending that header fields and field parameters that are not known or understood be ignored. An approach to error indication for unknown or invalid Event header parameter names was rejected as this violates the liberal in what you receive policy. The rationalle for this is to maintain a higher degree of backward compatablity of new subscriber implementations with older notifiers. Instead the approach of indicating invalid or unsupported Event header parameter values is defined in this document. The error indication defined in this document does not provide a means of indicating that a Event header is invalid for a specific context. For example no mechanism is provided to indicate that a particular Event header parameter value might be valid at a different point in time or with another combination of header or parameter values. This is considered out of scope for this document as it requires definition of a specific context when the parameter value is valid and invalid. This document also does not provide a means of indicating missing Event header parameters as that is also considered out of scope. [Should we add a Missing-Parameters header to contain the names of missing required Event header parameters?] 1.1. Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119[RFC2119]. Petrie Expires April 17, 2007 [Page 3]
Internet-Draft SIP Events Parameter Error October 2006 1.2. Overview This document extends the description of Notifier processing of SUBSCRIBE requests in [RFC3265]. A notifier which receives a SUBSCRIBE request with Event header parameters having invalid or unsupported values that cause a processing failure of the SUBSCRIBE MAY indicate this error by responding the SIP response code of 439. The notifier responding with a 439 error response code MUST include a Invalid-Parameters-Values header containing the Event header parameter(s) and its invalid value(s). Example SUBSCRIBE request Event header: Event: my-event;param1=value1;param2=invalid;param3=invalidAsWell Example SUBSCRIBE 439 response Invalid-Parameters-Values header: Invalid-Parameters-Values: param2=invalid;param3=invalidAsWell The Invalid-Parameters-Values header is valid in a 439 response to a SUBSCRIBE request. The Invalid-Parameters-Values header is ignored as having no meaning in any other SIP message. [Should it be possible to use this header in other error responses such as 420 Bad Extension?] The ABNF for the Invalid-Parameters-Values header is derived from the ABNF defined for the Event header in [RFC3265] as follows: Invalid-Parameters-Values = ( "Invalid-Parameters-Values" ) HCOLON *( SEMI event-param ) 2. IANA Considerations This document registers a new response code 439 in the IANA Session Initiation Protocol (SIP) Parameters (http://www.iana.org/assignments/sip-parameters). (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification). Response Code Reference ------------- --------- 439 Invalid Event Parameter Value [RFCXXXX] Petrie Expires April 17, 2007 [Page 4]
Internet-Draft SIP Events Parameter Error October 2006 This document registers a new Header Field: Invalid-Parameters-Values in the IANA Session Initiation Protocol (SIP) Parameters (http://www.iana.org/assignments/sip-parameters). (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification). Header Name compact Reference ----------------- ------- --------- Invalid-Parameters-Values [RFCXXXX] 3. Security Considerations None. 4. References 4.1. Informational References [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, January 1980. 4.2. Normative References [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. Appendix A. Acknowledgments Thank you to Robert Sparks of Estacado for input on the requirements. Petrie Expires April 17, 2007 [Page 5]
Internet-Draft SIP Events Parameter Error October 2006 Author's Address Daniel Petrie SIPez LLC. 34 Robbins Rd. Arlington, MA 02476 US Phone: +1 617 273 4000 Email: dan.ietf AT SIPez DOT com URI: http://www.SIPez.com/index.html?id=event-err Petrie Expires April 17, 2007 [Page 6]
Internet-Draft SIP Events Parameter Error October 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Petrie Expires April 17, 2007 [Page 7]