SIP Resource Lists: Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)
Subscribe to a whole list of SIP resources in one request by putting the list in the request body.
Camarillo, G., Roach, A.B., and O. Levin, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", RFC 5367, DOI 10.17487/RFC5367, October 2008, <https://www.rfc-editor.org/info/rfc5367>.
@misc{rfc5367,
series = {Request for Comments},
number = 5367,
howpublished = {RFC 5367},
publisher = {RFC Editor},
doi = {10.17487/RFC5367},
url = {https://www.rfc-editor.org/info/rfc5367},
author = {G. Camarillo and A.B. Roach and O. Levin},
title = {{Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)}},
pagetotal = 9,
year = 2008,
month = oct,
} RFC text
Contents
Network Working Group G. Camarillo
Request for Comments: 5367 Ericsson
Updates: 3265 A.B. Roach
Category: Standards Track Tekelec
O. Levin
Microsoft Corporation
October 2008
Subscriptions to Request-Contained Resource Lists
in the Session Initiation Protocol (SIP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies a way to create subscription to a list of
resources in SIP. This is achieved by including the list of
resources in the body of a SUBSCRIBE request. Instead of having a
subscriber send a SUBSCRIBE request for each resource individually,
the subscriber defines the resource list, subscribes to it, and gets
notifications about changes in the resources' states using a single
SUBSCRIBE dialog.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................2
3. User Agent Client Procedures ....................................2
3.1. Response Handling ..........................................2
3.2. Subsequent SUBSCRIBE Requests ..............................3
4. URI-List Document Format ........................................3
5. Resource List Server Behavior ...................................4
5.1. Subsequent SUBSCRIBE Requests ..............................4
6. Providing a URI to Manipulate a Resource List ...................4
7. Example .........................................................5
8. Security Considerations .........................................6
9. IANA Considerations .............................................6
9.1. List-Management Purpose Parameter Value ....................6
9.2. recipient-list-subscribe Option-Tag ........................7
10. Acknowledgments ................................................7
11. Normative References ...........................................7
1. Introduction
[RFC4662] specifies how to establish subscriptions to a homogeneous
resource list in SIP (which is specified in [RFC3261]) and defines
the procedures for getting notifications about changes in the state
of the associated resources. Yet, list creation is outside the scope
of [RFC4662].
This document specifies a way to create a list with a set of
resources and subscribe to it using a single SIP request. This is
achieved by including the list of resources (as defined in [RFC5363])
in the body of the SUBSCRIBE request.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. User Agent Client Procedures
A UAC (User Agent Client) that wants to create a resource list and
subscribe to it using the mechanism described in this document
constructs a SUBSCRIBE request with at least one body, whose
disposition is type "recipient-list" as defined in [RFC5363], that
contains the URI list. Additionally, the UAC MUST include the
'recipient-list-subscribe' option-tag (which is registered with the
IANA in Section 9) in a Require header field. The UAC MUST build the
rest of the SUBSCRIBE request following the rules in [RFC3265].
The UAC MUST support the "rlmi+xml" format defined in [RFC4662] and
signal this by including "rlmi+xml" in the Accept header. The UAC
MAY support additional formats and include them in the Accept header
field of the SUBSCRIBE request.
3.1. Response Handling
The status code in the response to the SUBSCRIBE request does not
provide any information about whether or not the resource list server
was able to successfully subscribe to the URIs in the URI list. The
UAC obtains this information in the notifications sent by the server.
3.2. Subsequent SUBSCRIBE Requests
The previous sections have specified how to include a URI list in an
initial SUBSCRIBE request to a resource list server in order to
subscribe to the state of a set of resources. Once the subscription
has been created and a dialog between the UAC and the resource list
server has been established, the UAC can send subsequent SUBSCRIBE
requests to, for example, extend the duration of the subscription.
At this point, there are no semantics associated with resource-list
bodies in subsequent SUBSCRIBE requests (although future extensions
can define them). Therefore, UACs SHOULD NOT include resource-list
bodies in subsequent SUBSCRIBE requests to a resource list server.
Note that a difference between an initial SUBSCRIBE request and
subsequent ones is that while the initial request is sent to the
public URI of the resource list, subsequent ones are sent to the
URI provided by the server when the dialog is established.
Therefore, from the UAC's point of view, the resource identified
by the former URI supports recipient-list bodies, while the
resource identified by the latter does not support them.
4. URI-List Document Format
[RFC5363] mandates that each URI-list services specification, such as
the subscription service defined here, specifies the default format
for the recipient-list bodies used within the particular service.
The default format for the recipient-list bodies for the subscription
service defined in this document is the resource list format defined
in [RFC4826]. UAs (User Agents) generating recipient-list bodies
MUST support this format and MAY support other formats. Resource
list servers able to handle recipient-list bodies MUST support this
format and MAY support other formats.
The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) resource list document provides features, such as hierarchical
lists and the ability to include entries by reference relative to the
XCAP root URI, that are not needed by the subscription service
defined here, which only needs to transfer a flat list of URIs
between a UA and the resource list server. Therefore, when using the
default resource list document, UAs SHOULD use flat lists (i.e., no
hierarchical lists) and SHOULD NOT use <entry-ref> elements. A
resource list server receiving a URI list with more information than
what has just been described MAY discard all the extra information.
Figure 1 shows an example of a flat list that follows the resource
list document.
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com" />
<entry uri="sip:joe@example.org" />
<entry uri="sip:ted@example.net" />
</list>
</resource-lists>
Figure 1: URI list
5. Resource List Server Behavior
Resource list servers that are able to receive and process SUBSCRIBE
requests with a recipient-list body SHOULD include a 'recipient-list-
subscribe' option-tag in a Supported header field when responding to
OPTIONS requests.
On reception of a SUBSCRIBE request with a URI list, a resource list
server that chooses to accept the "rlmi+xml" format MUST comply with
[RFC4662] for creating the subscription and reporting the changes in
the resources within the created dialog.
5.1. Subsequent SUBSCRIBE Requests
At this point, there are no semantics associated with resource-list
bodies in subsequent SUBSCRIBE requests (although future extensions
may define them). Therefore, a resource list server receiving a
subsequent SUBSCRIBE request with a resource-list body, following
standard SIP procedures, rejects it with a 415 (Unsupported Media
Type) response.
6. Providing a URI to Manipulate a Resource List
A UAC can manipulate a resource list at a resource list server. The
resource list server MAY provide a URI to manipulate the resource
list associated with a subscription using the Call-Info header field
in the NOTIFY request that establishes the subscription. The
"purpose" parameter of the Call-Info header field MUST have a value
of 'list-management', which we register with the IANA in Section 9.
The following is an example of such a header field.
Call-Info: <http://xcap.example.com/your-list.xml>
;purpose=list-management
The lifetime of a resource list to be manipulated by the URI provided
by the server is bundled to the lifetime of the subscription. That
is, the resource list SHOULD be destroyed when the subscription
expires or is otherwise terminated.
Section 7.1 of [RFC3265] does not list the Call-Info header field in
the table of header fields that NOTIFY requests can carry. This
document updates that table so that the Call-Info header field can be
optionally included in NOTIFY requests.
7. Example
The following is an example of a SUBSCRIBE request, which carries a
URI list in its body, sent by a UAC to a resource list server.
SUBSCRIBE sip:rls@example.com SIP/2.0
Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: RLS <sip:rls@example.com>
From: <sip:adam@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 1 SUBSCRIBE
Contact: <sip:terminal.example.com>
Event: presence
Expires: 7200
Require: recipient-list-subscribe
Supported: eventlist
Accept: application/cpim-pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: multipart/encrypted
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-Length: 337
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com" />
<entry uri="sip:joe@example.org" />
<entry uri="sip:ted@example.net" />
</list>
</resource-lists>
Figure 2: SUBSCRIBE request
8. Security Considerations
The Security Considerations section of [RFC4662] discusses security
issues related to resource list servers. Resource list servers
accepting request-contained URI lists MUST also follow the security
guidelines given in [RFC4662].
"Framework and Security Considerations for Session Initiation
Protocol (SIP) URI-List Services" [RFC5363] discusses issues related
to SIP URI-list services. Given that a resource list server sending
SUBSCRIBE requests to a set of users acts as a URI-list service,
implementations of resource list servers that handle request-
contained URI lists MUST follow the security-related rules in
[RFC5363]. These rules include opt-in lists and mandatory
authentication and authorization of clients.
9. IANA Considerations
The following sections describe the IANA registration of the 'list-
management' value for the "purpose" parameter of the Call-Info header
field and the 'recipient-list-subscribe' SIP option-tag.
9.1. List-Management Purpose Parameter Value
This document defines the 'list-management' value for the "purpose"
parameter of the Call-Info header field. A reference to this RFC (in
double brackets) has been added to the existing "purpose" Call-Info
parameter entry in the SIP Parameters registry, which currently looks
as follows:
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Call-Info purpose Yes [RFC3261]
9.2. recipient-list-subscribe Option-Tag
This document defines the SIP option tag "recipient-list-subscribe".
The following row has been added to the "Option Tags" section of the
SIP Parameter Registry:
+--------------------------+----------------------------+-----------+
| Name | Description | Reference |
+--------------------------+----------------------------+-----------+
| recipient-list-subscribe | This option tag is used to | [RFC5367] |
| | ensure that a server can | |
| | process the recipient-list | |
| | body used in a SUBSCRIBE | |
| | request. | |
+-------------------------------------------------------+-----------+
10. Acknowledgments
Cullen Jennings and Jonathan Rosenberg provided useful comments on
this document.
11. 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.B., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC4662] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) URI-
List Services", RFC 5363, October 2008.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Adam Roach
Tekelec
17210 Campbell Rd Ste 250
Dallas, TX 75252
USA
EMail: Adam.Roach@tekelec.com
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: oritl@microsoft.com
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.
AI ELI5
On this page
§1One Request for a Whole List
RFC 4662 explains how to subscribe to a homogeneous list of resources in SIP and how to get notifications when those resources change. It does not say how the list gets created.
RFC 5367 fills that gap. A client creates a list and subscribes to it with a single SIP request, by placing the list of resources (as defined in RFC 5363) in the body of a SUBSCRIBE request. Without this, the subscriber would send one SUBSCRIBE per resource.
Instead of asking about each friend one at a time, you give a single list and ask to be told when anything changes for anyone on it.
§3What the Client Does
A user agent client (UAC) builds a SUBSCRIBE request with at least one body whose disposition is type recipient-list, as defined in RFC 5363, containing the URI list. It MUST also put the recipient-list-subscribe option-tag in a Require header field, and build the rest of the request following RFC 3265.
The UAC MUST support the rlmi+xml format from RFC 4662 and signal it by listing rlmi+xml in the Accept header. It MAY support and list other formats.
The status code in the response says nothing about whether the server managed to subscribe to the URIs on the list. The client learns that from the notifications the server sends.
Once the dialog exists, the client can send subsequent SUBSCRIBE requests, for example to extend the subscription. Resource-list bodies have no meaning there, so UACs SHOULD NOT include them. The initial request goes to the public URI of the resource list, while later ones go to the URI the server provided when the dialog was established.
You hand over your list and say you need special list service. The first answer only says 'got it'. The details about each person on the list arrive later in updates.
§4The URI-List Document
RFC 5363 requires each URI-list service to name a default format for its list bodies. Here the default is the resource list format from RFC 4826. Clients that generate list bodies MUST support it, and so MUST resource list servers that handle them. Either side MAY support other formats.
That XCAP document format can express hierarchical lists and entries included by reference (<entry-ref>). This service only needs a flat list of URIs, so UAs SHOULD use flat lists and SHOULD NOT use <entry-ref> elements. A server that receives more than that MAY discard the extra information.
The RFC's example list contains three <entry> elements, each with a uri attribute such as sip:bill@example.com, inside a single <list>.
The list is just a plain shopping list of addresses. No fancy folders inside folders, and no pointers to other lists.
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com" />
<entry uri="sip:joe@example.org" />
<entry uri="sip:ted@example.net" />
</list>
</resource-lists>§5What the Resource List Server Does
A resource list server that can process a SUBSCRIBE with a recipient-list body SHOULD include the recipient-list-subscribe option-tag in a Supported header field when it answers OPTIONS requests. This lets clients discover the capability.
If the server chooses to accept the rlmi+xml format, it MUST comply with RFC 4662 for creating the subscription and for reporting changes to the resources inside the created dialog.
If a subsequent SUBSCRIBE carries a resource-list body, the server follows standard SIP procedures and rejects it with a 415 (Unsupported Media Type) response.
Managing the list
The server MAY give the client a URI for manipulating the list, using a Call-Info header field in the NOTIFY that establishes the subscription, with the purpose parameter set to list-management. The list lives only as long as the subscription: it SHOULD be destroyed when the subscription expires or ends. The RFC also updates the table in Section 7.1 of RFC 3265 so that Call-Info may optionally appear in NOTIFY requests.
The waiter can say 'I can take list orders', and he looks after everything on your list. He may also give you a card to change the list. When your visit ends, the list is thrown away.
§8Security and IANA
Servers that accept request-contained URI lists MUST follow the security guidance in RFC 4662. Because a resource list server that sends SUBSCRIBE requests to a set of users acts as a URI-list service, it MUST also follow the security rules in RFC 5363. Those rules include opt-in lists and mandatory authentication and authorization of clients.
IANA registered the list-management value for the purpose parameter of Call-Info, and the recipient-list-subscribe SIP option-tag. The option-tag is used to ensure that a server can process the recipient-list body used in a SUBSCRIBE request.
Because the server will contact other people for you, it must check who you are and make sure those people agreed to be on lists.