Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)
updates
- rfc-3265 — Session Initiation Protocol (SIP)-Specific Event Notification
Extracted elements (24)
No semantics are defined for resource-list bodies in subsequent SUBSCRIBE requests because the dialog URI (used for subsequent requests) identifies a resource that does not support recipient-list bodies, as opposed to the public URI used for initial requests.
The XCAP resource list document format was chosen as the default because it already existed, but only flat lists are recommended since hierarchical lists and <entry-ref> elements are unnecessary for simply transferring a flat URI list between a UA and resource list server.
Initial SUBSCRIBE requests are sent to the public URI of the resource list, while subsequent ones are sent to the dialog URI provided by the server; from the UAC's view, only the former supports recipient-list bodies.
The SUBSCRIBE response status code does not indicate whether the resource list server successfully subscribed to the URIs in the URI list; the UAC obtains this information only through subsequent NOTIFY messages.
This document updates RFC 3265 to allow the Call-Info header field to be optionally included in NOTIFY requests, as RFC 3265's table of permitted NOTIFY headers did not previously list it.
A resource list server accepting the 'rlmi+xml' format MUST comply with RFC 4662 for creating the subscription and reporting changes in resources within the created dialog.
A resource list server receiving a subsequent SUBSCRIBE request with a resource-list body rejects it with a 415 (Unsupported Media Type) response, following standard SIP procedures.
A UAC constructing a SUBSCRIBE request with a recipient-list body MUST include the 'recipient-list-subscribe' option-tag in a Require header field.
Implementations of resource list servers handling request-contained URI lists MUST follow the security-related rules in RFC 5363, including opt-in lists and mandatory authentication and authorization of clients.
Resource list servers able to handle recipient-list bodies MUST support the RFC 4826 resource list format and MAY support other formats.
Resource list servers accepting request-contained URI lists MUST follow the security guidelines given in RFC 4662.
The 'purpose' parameter of the Call-Info header field in a NOTIFY request providing a URI for resource list manipulation MUST have a value of 'list-management'.
The resource list SHOULD be destroyed when the subscription expires or is otherwise terminated, as its lifetime is bundled to the subscription lifetime.
The UAC MUST support the 'rlmi+xml' format defined in RFC 4662 and signal this by including 'rlmi+xml' in the Accept header of the SUBSCRIBE request.
UACs SHOULD NOT include resource-list bodies in subsequent SUBSCRIBE requests to a resource list server, as no semantics are currently associated with such bodies in subsequent requests.
UAs generating recipient-list bodies MUST support the resource list format defined in RFC 4826 and MAY support other formats.
When using the default resource list document, UAs SHOULD use flat lists (no hierarchical lists) and SHOULD NOT use <entry-ref> elements.
A SUBSCRIBE request carries a URI list in its body with Content-Disposition set to 'recipient-list' and Content-Type set to the appropriate list format (e.g., application/resource-lists+xml), enabling single-request subscription to multiple resources.
Resource list servers SHOULD include a 'recipient-list-subscribe' option-tag in a Supported header field when responding to OPTIONS requests, advertising their capability to process SUBSCRIBE requests with a recipient-list body.
The resource list server MAY provide a URI for manipulating the associated resource list via a Call-Info header field in the NOTIFY request that establishes the subscription, using purpose='list-management'.
This document registers the 'list-management' value for the 'purpose' parameter of the Call-Info header field in the SIP Parameters registry.
This document registers the 'recipient-list-subscribe' option-tag in the SIP Option Tags registry; it is used to ensure a server can process a recipient-list body in a SUBSCRIBE request.
Resource list servers accepting request-contained URI lists must follow RFC 4662 security guidelines and RFC 5363 security rules, which include requiring opt-in lists and mandatory authentication and authorization of clients to prevent unauthorized subscription amplification.
The default URI-list body format is the RFC 4826 resource list XML document, using the namespace 'urn:ietf:params:xml:ns:resource-lists', with flat <list> and <entry uri='...'> elements and Content-Type of application/resource-lists+xml.