A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists
Extracted elements (25)
List notifications necessarily contain RLMI documents for two reasons: they identify the resource to which event state corresponds (since many state syntaxes like PIDF may not fully identify or may identify the resource differently), and they disambiguate multiple instances of a single resource arising from forking.
The RLS may buffer and batch notifications of resource changes rather than forwarding each change individually. This rate-limiting role is one of the key differentiators between RLS implementations and a primary motivation for the resource list subscription mechanism.
If a subscriber sends a SUBSCRIBE to a list resource URI without including 'Supported: eventlist', the notifier will typically return a 421 (Extension Required). Unlike the general RFC 3261 advice to avoid 421, here it is appropriate because the URI fundamentally represents a list resource and the subscription cannot proceed without the extension.
A compliant implementation MUST support the multipart/related and application/rlmi+xml MIME types. These types MUST be included in an Accept header sent in a SUBSCRIBE message, in addition to any other types supported by the client.
A subscriber to a list MUST NOT install multiple subscriptions when the initial request is forked. Forking makes little sense with event list subscriptions since the whole idea is centralization of the notification source.
If the 'state' attribute of an <instance> element indicates 'terminated', then a 'reason' attribute MUST also be present with values and meanings as defined for the 'reason' parameter on the 'Subscription-State' header field in RFC 3265.
Immediate notifications triggered as a result of subsequent SUBSCRIBE messages SHOULD include an RLMI document in which the full state is indicated, allowing the subscriber to refresh their state and recover from lost notifications.
Including 'eventlist' in a 'Require' header field in a SUBSCRIBE request is NOT RECOMMENDED as it serves no purpose except to break interoperability. Implementations SHOULD NOT include 'Supported: eventlist' in any requests except SUBSCRIBE.
RLSes MUST NOT send NOTIFY messages that do not contain RLMI for a subscription if they have previously sent NOTIFY messages in that subscription containing RLMI. Similarly, RLSes MUST NOT send NOTIFY messages that do contain RLMI if they have previously sent NOTIFY messages in that subscription without RLMI. The nature of a subscription (single resource vs. list) cannot change during its lifetime.
The 'cid' attribute MUST be present in an <instance> element if the 'state' attribute is 'active'. It identifies the section within the multipart/related body containing the actual resource state, and MUST refer only to top-level parts of the multipart/related document for which the RLMI document is the root.
The first NOTIFY sent in a subscription MUST contain full state (fullState='true'), as must the first NOTIFY sent after receipt of a SUBSCRIBE request for the subscription.
The 'version' attribute of the <list> element MUST be 0 for the first NOTIFY message sent within a subscription, and MUST increase by exactly one for each subsequent NOTIFY sent within that subscription.
A list subscription must be homogeneous with respect to the underlying event package — a single list subscription applies only one event package to all resources in the resource list. List subscriptions support arbitrary nesting, where elements within the list may be atomic resources or sub-lists themselves.
NOTIFY bodies for resource list subscriptions use the multipart/related MIME type. The root section is an application/rlmi+xml document containing meta-information about each resource in the list; remaining sections contain the actual state information for each resource.
The Resource List Server (RLS) accepts subscriptions to resource lists and sends notifications to update subscribers of the state of the resources in a resource list. It acts as a notifier for list subscriptions and as a subscriber for back-end subscriptions to individual resources.
IANA registered a new MIME type 'application/rlmi+xml' for Resource List Meta-Information. It supports an optional 'charset' parameter; UTF-8 encoding is strongly encouraged. This type is used to convey meta-information for the state of lists of resources within a SIP subscription.
IANA registered a new SIP option tag 'eventlist' in the registry established by RFC 3261 Section 27.1. This tag indicates support for the extension allowing subscriptions to lists of resources.
IANA registered a new URN sub-namespace 'urn:ietf:params:xml:ns:rlmi' for XML elements defined by RFC 4662 to describe subscription aggregation information within a single SIP subscription, used in the application/rlmi+xml body type.
Any RLS that uses SIP back-end subscriptions MUST be able to act as an authentication service as defined in RFC 4474, provided local administrative policy allows it. When the RLS and subscriber are in different domains, the RLS generally cannot vouch for the user's identity, and SHOULD subscribe to resources using its own identity, obtaining only publicly available resource information.
Implementations MUST NOT present the result of one back-end subscription to more than one user unless the RLS has adequate access to the complete authorization policy AND has determined that sharing does not violate that policy. Even when possible, this mode of operation is NOT RECOMMENDED, as resources may render different or conflicting states depending on the subscribing user's identity.
Implementors of RLSes that create back-end subscriptions MUST implement safeguards to prevent circular list nesting from creating an infinite loop of subscriptions. Applying filters to back-end subscriptions is one effective mitigation approach.
RLSes SHOULD pass along support for 'multipart/signed' and 'application/pkcs7-mime' content types to SIP back-end subscriptions if the subscriber includes them in the initial SUBSCRIBE. Failing to do so may cause resources to refuse to divulge state or subscribers to discard valid state. RLSes should not modify MIME bodies received from back-end subscriptions.
A subscriber maintains a resource-list table indexed by resource URI. On full-state NOTIFY (fullState='true'): verify version is greater than local, flush table, repopulate from document. On partial-state NOTIFY (fullState='false'): if version is exactly one higher, increment and update rows; if more than one higher, set to new version and generate a refresh SUBSCRIBE; if less than or equal, discard.
Each <resource> element in RLMI has a required 'uri' attribute (xs:anyURI) identifying the resource, and contains zero or more <name> and <instance> child elements. Each <instance> has required 'id' (opaque string, unique within the resource) and 'state' (enumerated: 'active', 'pending', or 'terminated') attributes, and optional 'reason' and 'cid' attributes.
The RLMI (Resource List Meta-Information) XML document uses namespace 'urn:ietf:params:xml:ns:rlmi' and contains a <list> root element with mandatory attributes 'uri' (xs:anyURI), 'version' (xs:unsignedInt), and 'fullState' (xs:boolean), plus optional 'cid' (xs:string). It contains zero or more <name> and <resource> child elements.