The Session Initiation Protocol (SIP) Pending Additions Event Package
Extracted elements (26)
No forking of subscriptions to pending additions information is needed because resource-list state is normally handled by a single server with repository access, making a single subscription element sufficient.
Partial notifications using 'application/resource-lists-diff+xml' were introduced because generating full resource-list notifications for small state changes is inefficient in bandwidth-constrained environments. The diff format reports only what has changed since the last notification.
A subscriber MUST NOT create multiple dialogs as a result of a single subscription request to the Pending Additions event package, since resource-list state is typically resident in a single location.
All subscribers and notifiers MUST support the 'application/resource-lists+xml' data format (RFC 4826) and its extension to carry consent-related state information. If the SUBSCRIBE request's Accept header field is present, it MUST include 'application/resource-lists+xml'.
All subscribers and notifiers SHOULD support the 'application/resource-lists-diff+xml' format for partial notifications.
All subscriptions SHOULD be authenticated and then authorized before approval, as the state of resources to be added to a relay's translation logic can reveal sensitive information.
Consent-status documents MUST be well-formed XML, MUST be based on XML 1.0, and MUST be encoded using UTF-8.
If a subscriber encounters a processing error while processing an 'application/resource-lists-diff+xml' document, the subscriber SHOULD renew its subscription and may fall back to normal operations by excluding the diff format from the new SUBSCRIBE.
It is RECOMMENDED that the server does not generate notifications for a single subscriber at a rate faster than once every 5 seconds, for congestion control reasons.
Once a subscription is accepted and installed, the server MUST deliver full state in its first notification using the 'application/resource-lists+xml' content type.
The <consent-status> element MUST be positioned as an instance of the <any> element within the <entry> element when included in NOTIFY bodies.
The server MUST construct partial notifications using <add> elements for added information, <remove> elements for removed information, and <replace> elements for changed information.
The server MUST NOT send a new NOTIFY request with a partial notification until it has received a final response from the subscriber for the previous one or the previous NOTIFY request has timed out.
When a subscriber receives the first notification containing full state, the subscriber MUST store the received full document as its local copy. On receiving a partial notification, it MUST apply the changes to its local copy.
Five consent-status states are defined: Pending (relay will ask for permission), Waiting (permission requested, no answer yet), Error (permission request delivery failed), Denied (resource denied permission), and Granted (resource granted permission).
The <consent-status> element provides consent-related information about a resource to be added to a relay's translation logic. It is an XML element in the namespace 'urn:ietf:params:xml:ns:consent-status' and takes one of five values: pending, waiting, error, denied, or granted.
The default expiration time for a Pending Additions event package subscription is one hour (3600 seconds).
The Pending Additions event package is named 'consent-pending-additions' and is carried in the Event and Allow-Events SIP headers as defined in RFC 3265.
When a resource moves to the error, denied, or granted states and a NOTIFY request is sent, the resource is removed from further notifications.
This document registers the 'consent-pending-additions' SIP event package per RFC 3265 procedures.
This document registers the MIME type 'application/resource-lists-diff+xml' with file extension .rld, used to support partial notifications in subscriptions to resource lists.
This document registers the URN sub-namespace 'urn:ietf:params:xml:ns:consent-status' and the XML schema 'urn:ietf:params:xml:schema:consent-status' per RFC 3688 procedures.
This document registers the XML schema 'urn:ietf:params:xml:schema:resource-lists-diff' (ID: resource-lists-diff) as an extension to the resource-list schema from RFC 4826.
Attackers may attempt to modify the contents of notifications sent by a relay to its subscribers. Consequently, it is RECOMMENDED that relays use strong means for information integrity protection.
Subscriptions to the Pending Additions event package can reveal sensitive information. Relays SHOULD use strong authentication (e.g., SIP Digest as per RFC 3261) and information integrity/confidentiality mechanisms. End-to-end encryption via S/MIME is RECOMMENDED; if unavailable, hop-by-hop TLS with SIPS URIs SHOULD be used.
NOTIFY bodies carry 'application/resource-lists+xml' documents for full state or 'application/resource-lists-diff+xml' documents for partial updates. The diff format wraps XML patch operations (<add>, <remove>, <replace>) in a <resource-lists-diff> root element.