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 <sip:alice@example.com>;tag=4fxaed73sl
To: URI-list server A <sip:urilist-a@example.com>
Call-ID: 7xTn9vxNit65XU7p4@example.com
CSeq: 1 INVITE
Contact: <sip:alice@machine1.example.com>
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
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="sip:bob@example.com"/>
<entry uri="sip:friends-list@example.com"/>
<entry uri="sip:colleagues-list@example.com"/>
</list>
</resource-lists>
--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 <sip:alice@example.com>;tag=4fxaed73sl
To: URI-list server A <sip:urilist-a@example.com>;tag=814254
Call-ID: 7xTn9vxNit65XU7p4@example.com
CSeq: 1 INVITE
URI-List-Entry: sip:friends-list@example.com;
members=<cid:an3bt8jf03@example.com>
URI-List-Entry: sip:colleagues-list@example.com;
members=<cid:bn35n8jf04@example.com>
Conten-Type: multipart/mixed;boundary="boundary1"
Content-Length: 745
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: uri-list
Content-ID: <an3bt8jf03@example.com>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="sip:bill@example.com"/>
<entry uri="sip:randy@example.net"/>
<entry uri="sip:eddy@example.com"/>
</list>
</resource-lists>
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: uri-list
Content-ID: <bn35n8jf04@example.com>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="sip:joe@example.org"/>
<entry uri="sip:carol@example.net"/>
</list>
</resource-lists>
--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]
