SIPPING Working Group J. Hautakorpi, Ed. Internet-Draft G. Camarillo Expires: December 1, 2006 Ericsson May 30, 2006 A Method for URI-List Servers to Refuse the Handling of a URI-List draft-hautakorpi-sipping-uri-list-handling-refused-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 December 1, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This documents defines a new response code, namely 495 (URI-List Handling Refused), for the Session Initiation Protocol (SIP). This new response code can used by URI-list servers that do not want to handle an incoming URI-list (e.g., due to local policy). For example, a URI-list server may not want to handle a URI-list when an incoming SIP request carries a URI-list inside a URI-list. The URI- list server may not want to handle that particular embedded URI-list. Hautakorpi & Camarillo Expires December 1, 2006 [Page 1] Internet-Draft URI-List Handling Refused May 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Syntax of 495 URI-List Handling Refused . . . . . . . . . . . 4 4. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Hautakorpi & Camarillo Expires December 1, 2006 [Page 2] Internet-Draft URI-List Handling Refused May 2006 1. Introduction This document defines a new response code for Session Initiation Protocol (SIP) [2]. This new response code is 495 (URI-List Handling Refused) and can be used by the servers providing SIP Uniform Resource List (URI)-list services [3] that do not want to handle a incoming request. For example, a URI-list server might not want to handle an incoming SIP request carrying a URI-list inside a URI-list. Responses using the 495 (URI-List Handling Refused) response code can carry a URI-List-Entry header field, which is also specified in this document. +---------+ SIP request +----------+ | |------------------------------>| | | | [URI-list in a URI-list] | URI-list | | UAC | | server | | | 495 URI-List Handling Refused | | | |<------------------------------| | +---------+ +----------+ Figure 1: General overview Figure 1 illustrates the usage of the 495 (URI-List Handling Refused) response code. When a URI-list server receives a SIP request (e.g., INVITE), it can return a 495 (URI-List Handling Refused) response back to the UA, if it does not want to fan out the received request. The reason for not processing an incoming request might be, for example, due to local policies. Proxies do not have to perform any special processing for 495 responses, they just forward them to the User Agent Client (UAC) as usual. When an UAC receives a 495 response, it knows that the URI-list server has not sent any outbound request. The 495 URI-List Handling Refused response code is useful in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system [7]. In a given PoC session, one of the PoC servers act as the controlling PoC server while the rest act as participating PoC servers. The only server allowed to handle URI-lists for the session is the controlling PoC server. PoC servers can use the 495 response code to inform the controlling PoC server that they cannot handle a particular URI-list. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as Hautakorpi & Camarillo Expires December 1, 2006 [Page 3] Internet-Draft URI-List Handling Refused May 2006 described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Syntax of 495 URI-List Handling Refused Responses using the 495 (URI-List Handling Refused) response code SHOULD contain one or more URI-List-Entry entries. The URI-List- Entry header field contains one or more URIs, which map to URI-lists. The URI-List-Entry header field has two purposes. The first purpose is to inform the UAC which URIs are actually URI-lists that cannot be handled. The second purpose is to optionally give information about the members of the associated URI-list. The Augmented Backus-Naur Form (ABNF) [4] syntax of URI-List-Entry header field is the following: URI-List-Entry = "URI-List-Entry" HCOLON uri-list-entry-parm *(COMMA uri-list-entry-parm) uri-list-entry-parm = ( name-addr / addr-spec ) [ SEMI "members" EQUAL "<" cid-url ">" ] [ *( SEMI generic-param ) ] The HCOLON, SEMI, EQUAL, and generic-param are defined in [2]. The cid-url is defined in [5]. The 495 (URI-List Handling Refused) response MAY contain body parts which have URI-lists. Those body parts are referenced from the URI- List-Entry entries through their Content-IDs [5]. If there is a Content-ID defined in the URI-List-Entry, then one of the body parts MUST have an equivalent Content-ID. The syntax of a URI-list is service specific. This kind of message structure enables UACs to determine which SIP URI relates to which URI-list, if the URI-list server is willing to disclose that information. 4. Example Scenario In the following example scenario a UAC sends an INVITE request to a URI-list server. The URI-list server refuses to process the INVITE request and replies with 495 (URI-List Handling Refused). Hautakorpi & Camarillo Expires December 1, 2006 [Page 4] Internet-Draft URI-List Handling Refused May 2006 Alice URI-list server | | | INVITE | |-------------------------------->| | | | 495 URI-List Handling Refused | |<--------------------------------| | | Figure 2: Example flow chart Alice is trying to establish a conference with the INVITE request. The content of INVITE request shown in Figure 2 is the following (Via header fields are not shown for simplicity): INVITE sip:urilist-a@example.com SIP/2.0 Max-Forwards: 70 From: Alice ;tag=4fxaed73sl To: URI-list server A Call-ID: 7xTn9vxNit65XU7p4@example.com CSeq: 1 INVITE Contact: Require: recipient-list-invite Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 538 --boundary1 Content-Type: application/sdp (SDP not shown) --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list --boundary1-- The sip:friends-list@example.com and sip:colleagues-list@example.com in the above example SIP request are actually references to URI-lists Hautakorpi & Camarillo Expires December 1, 2006 [Page 5] Internet-Draft URI-List Handling Refused May 2006 on the URI-list server. In this example message the URI-lists are in XML resource list format [6]. The content of 495 reply in Figure 2 is the following (Via header fields are not shown for simplicity): SIP/2.0 495 URI-List Handling Refused From: Alice ;tag=4fxaed73sl To: URI-list server A ;tag=814254 Call-ID: 7xTn9vxNit65XU7p4@example.com CSeq: 1 INVITE URI-List-Entry: sip:friends-list@example.com; members= URI-List-Entry: sip:colleagues-list@example.com; members= Conten-Type: multipart/mixed;boundary="boundary1" Content-Length: 745 --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: uri-list Content-ID: --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: uri-list Content-ID: --boundary1-- From the above message an UAC can determine that friend-list@example.com and colleagues-list@example.com are Hautakorpi & Camarillo Expires December 1, 2006 [Page 6] Internet-Draft URI-List Handling Refused May 2006 references to URI-lists, and their members are enumerated in the first and second body part respectively. 5. Security Considerations Because 495 (URI-List Handling Refused) is just an additional response code to SIP [2], all the general security consideration of SIP also apply to it. Implementors and administrators should also be aware of two special security consideration related to 495 (URI-List Handling Refused): 495 response is eavesdropped: 495 response code may contain information about the members of a given URI-list (e.g., 'buddylist'). Eavesdroppers can acquire this information if the 495 response is not encrypted. Therefore it is RECOMMENDED that either hop-by-hop or end-to-end encryption is used. URI-lists disclosed to rogue entity: A rogue entity may be able to acquire information about the members of a given URI-list (e.g., 'buddylist'), if the URI-list server sends information about those URI-lists also to unauthorized users. Therefore it is RECOMMENDED that URI-list server discloses the content of URI-list only to authorized UACs. 6. IANA Considerations The IANA is requested to make three additions to the Session Initiation Protocol (SIP) Parameters registry. The first addition is to add the following header field to the already existing Header Fields sub-registry Header Name compact Reference ----------------- ------- --------- URI-List-Entry [RFCxxxx] The second addition is to add the following header field parameter to the already existing Header Field Parameters and Parameter Values sub-registry. Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- --------- URI-List-Entry members No [RFCxxxx] The third addition is to add the following response code to the already existing Methods and Response-Codes sub-registry. Request Failure 4xx Hautakorpi & Camarillo Expires December 1, 2006 [Page 7] Internet-Draft URI-List Handling Refused May 2006 495 URI-List Handling Refused [RFCxxxx] Note for the RFC Editor: The three occurrences of 'RFCxxxx' in the above should be a reference to the coming RFC number of this draft. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", draft-ietf-sipping-uri-services-05 (work in progress), January 2006. [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [5] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. 7.2. Informative References [6] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", draft-ietf-simple-xcap-list-usage-05 (work in progress), February 2005. [7] "OMA PoC System Description: Draft Versio 2.0", April 2006. Hautakorpi & Camarillo Expires December 1, 2006 [Page 8] Internet-Draft URI-List Handling Refused May 2006 Authors' Addresses Jani Hautakorpi (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Jani.Hautakorpi@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Hautakorpi & Camarillo Expires December 1, 2006 [Page 9] Internet-Draft URI-List Handling Refused May 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. Hautakorpi & Camarillo Expires December 1, 2006 [Page 10]