Summary

  • RFC 5367 lets a SIP user agent create a subscription to a flat list of resources by placing the list in the initial SUBSCRIBE request, requiring recipient-list-subscribe, and accepting rlmi+xml notifications within one dialog.
  • The response to that initial request does not prove successful subscription to each URI. Notifications provide the constituent evidence. Once the dialog exists, later SUBSCRIBE requests target a URI supplied by the server, list bodies have no defined semantics, and a server rejects one with 415.
  • Governance must therefore bind authority to phase and resource: creation input, canonical list, client authorization, recipient opt-in, dialog, continuation target, notification state, list-management capability, expiration and verified destruction are different receipts. A reusable document or URI must not become durable power by accident.

The same body crossed into a different phase

At creation time, the resource list is indispensable. The user agent wants one subscription covering a set of resources instead of a separate SIP dialog for each. It builds a SUBSCRIBE request with at least one body whose disposition is recipient-list, uses the flat-list format associated with RFC 4826, and places the resource-list server in the Request-URI.

It also puts recipient-list-subscribe in Require. That option tag makes capability failure explicit: the server must understand the request-contained-list extension before accepting the operation. The client declares support for rlmi+xml in Accept because the list event framework uses that format to report the state of constituent resources.

After a dialog is established, a later SUBSCRIBE can renew or otherwise maintain it. But RFC 5367 assigns no semantics to a resource-list body in that later request. A client should not include one. A server that receives one rejects the request with 415 Unsupported Media Type under ordinary SIP handling.

The difference is not that XML suddenly became malformed. The authority of the body expired when the protocol moved from creation to maintenance. The later request addresses a resource identified by the server when the dialog was established, not the same public creation surface the client first used.

The public URI and continuation URI named different capabilities

From the client's point of view, the initial SUBSCRIBE goes to the public URI of the resource list. That resource supports a recipient-list body because list creation is part of its contract.

Subsequent requests go to a URI supplied by the server for the established dialog. RFC 5367 explicitly notes that the former resource supports recipient-list bodies while the latter does not. Two URIs can participate in one human task without exposing the same authority.

This is a useful defense against ambient capability. If every renewal could silently replace the list, possession of dialog state would also become authority to change the subscription's scope. The specification leaves room for a future extension to define such semantics, but does not invent them in the base contract.

An audit record should preserve both targets and the transition between them: initial public URI, authenticated client, accepted list hash, dialog identifiers, server-provided continuation URI and the reason a subsequent request was classified as creation, renewal or unsupported mutation. Storing only the latest Request-URI erases how its authority was obtained.

Acceptance could not speak for every resource

The status code in the response to the initial SUBSCRIBE does not say whether the resource-list server successfully subscribed to every URI in the body. RFC 5367 makes that limitation explicit. The user agent obtains the relevant information from notifications sent by the server.

This separates two cardinalities. One client-to-server transaction establishes or rejects the resource-list operation. Behind it, the server attempts to create and maintain state for multiple resources. A single response cannot contain a future truth about every constituent.

The limitation resembles other asynchronous acceptance boundaries, but its remedy is specific. RFC 4662 defines resource-list event notification and the rlmi+xml representation. The notification can identify resources and carry state appropriate to the event package. The evidence does not come from relabeling the initial response; it comes from a later channel designed for constituent observations.

A dashboard should therefore expose at least dialog acceptance, notification freshness, expected resource count, observed resource positions and bounded unknowns. “Subscription active” without an object can mean that the top-level dialog exists while one listed resource never produced a successful downstream state.

One dialog did not create one constituent truth

The value of the mechanism is aggregation. A subscriber avoids maintaining a separate dialog for every resource. That reduces coordination overhead at the edge and lets the resource-list server manage the work.

Aggregation does not eliminate the underlying plurality. Bill, Joe and Ted can have different subscription states. One may be authorized, another unavailable and a third pending. Notifications need to preserve those differences even though they arrive within one dialog.

The evidence model should assign a stable position to each canonical URI and link notification versions to those positions. Missing positions must remain missing; they must not fall out of the denominator because no positive event arrived. A fresh top-level NOTIFY is not evidence that every resource within it is fresh unless the body contract says so.

Retry also operates at the right level. Recreating the entire dialog to repair one ambiguous constituent can duplicate work or disturb correct state for the others. The service needs enough internal identity to distinguish dialog recovery, resource recovery and notification replay.

Rich list syntax exceeded the service's needs

RFC 4826 supplies a resource-list XML format with features including hierarchy and entries by reference relative to an XCAP root. RFC 5367 chooses that format as the default but needs only a flat list of URIs for this service.

User agents should use flat lists and should not use entry-ref. A server that receives extra information may discard it. This is a semantic narrowing, not merely a parser convenience.

A document can be valid under its general schema while carrying structure the subscription service does not promise to honor. If a client signs or reviews a hierarchy but the server flattens, ignores or removes parts, the executed set may differ from the user's mental model without any XML validation error.

Receipts should record the original document, the supported profile, discarded constructs, canonical flat set and any duplicate handling inherited from the URI-list framework. The relevant hash for execution is not necessarily the hash of the rich source document; it is the hash of the interpreted set under a named profile.

This is another phase-bound limit. The shared format permits reuse across applications. The service contract decides which subset has authority here.

List management was a separate capability

The resource-list server may provide a URI that allows the client to manipulate the list associated with the subscription. It does so in a Call-Info header carried by the NOTIFY that establishes the subscription, with purpose=list-management.

That URI is not the notification itself, not the continuation URI by implication, and not evidence that a modification occurred. It is a capability reference to a management surface. Access control, method semantics and mutation receipts still belong to the service behind it.

Applications should keep these identities distinct. The public creation URI accepts a request-contained list. The dialog URI maintains the established subscription. The list-management URI, if supplied, offers a way to manipulate the associated list. Treating them as aliases encourages an authorization check made for one surface to leak into another.

The management link also deserves careful display. A UI that retains it after the subscription ends can invite users or automation to act on a resource whose legitimate lifetime has expired. A successful HTTP or XCAP response from that address would be a new observation, not proof that the old SIP subscription still owns the object.

The list's lifetime followed the subscription

RFC 5367 says the lifetime of a manipulable resource list is bundled to the lifetime of the subscription. The list should be destroyed when the subscription expires or is otherwise terminated.

This creates a clear normative intention and a separate verification problem. An Expires value reaching zero proves the protocol timer state observed at one point. A termination notification proves another state. Neither is, by itself, a storage-deletion receipt.

Implementations may hold caches, replicated copies, audit records or delayed jobs. The word “destroyed” needs an operational contract: which primary object, which replicas, which derived indexes, what retention exceptions, and what observable completion event. The RFC does not supply a universal storage architecture, so operators must not claim more than they can verify.

At the same time, uncertainty about physical deletion must not erase the specification's authority boundary. The list was not meant to become a permanent address book. A system that deliberately promotes it to a reusable corporate list has made a new product decision requiring new consent, ownership and retention rules.

Authentication did not replace recipient opt-in

RFC 5367 inherits the security guidance of RFC 4662 and the URI-list service framework of RFC 5363. Resource-list servers must authenticate and authorize clients, and URI-list security includes opt-in protection for affected targets.

A valid subscriber identity answers who invoked the service. It does not prove that every target agreed to the subscription, that the event package may expose the target's state, or that the client may later widen the list.

The pre-send or pre-subscription gate must bind the authenticated principal, service, event package, canonical resource, purpose, duration and applicable target permission. A generic “user may subscribe” role is too broad if it lets one account transform arbitrary URI lists into ongoing observation.

The evidence should also preserve negative decisions. A missing resource in notifications could mean refusal, failure, filtering or no attempt. Without the authorization record, the operator cannot distinguish intentional protection from broken delivery.

Registration named capabilities, not completed work

RFC 5367 registered recipient-list-subscribe and the list-management purpose value with IANA. Those names make capability negotiation and parsing interoperable.

An option tag in Supported or Require proves vocabulary and a claim of handling. It does not prove successful constituent subscriptions, current list contents, notification completeness, management authorization or destruction after expiry. Likewise, a Call-Info purpose value explains why a URI was supplied; it does not prove that the URI is still valid or safe for a particular caller.

RFC 5367 was published in October 2008 on the Standards Track and updated RFC 3265 by allowing Call-Info in NOTIFY. RFC 3265 was later obsoleted by RFC 6665. Current implementations should read the event-framework lineage accurately rather than treating the older base document as the final operational word.

Standards succession does not erase the analytical boundary in RFC 5367. Creation input, dialog maintenance, notification evidence and list lifetime remain different claims even when later documents refine the underlying event machinery.

Eleven receipts kept a temporary list temporary

A defensible implementation can separate at least eleven receipts:

  1. The client was authenticated and authorized for the resource-list subscription service.
  2. The initial request targeted the public creation URI and required the correct option tag.
  3. The exact input document was parsed under a named flat-list profile.
  4. The canonical resource set and applicable opt-in decisions were complete before downstream work.
  5. The server accepted or rejected creation of the top-level dialog.
  6. The server supplied a continuation URI bound to that dialog.
  7. Notifications reported a state, freshness and identity for every constituent they claimed to cover.
  8. A renewal maintained the dialog without silently redefining the list.
  9. Any list-management URI was issued to the right principal with an explicit scope.
  10. Expiration or termination ended the subscription's authority.
  11. Independent storage evidence established destruction or a declared retention exception.

No receipt can borrow the conclusion of the next. A 2xx is not per-resource success. A NOTIFY is not necessarily a complete current set. A management URI is not a mutation. Expiry is not observed erasure.

Lu Heng's Minimum Initial Specification note supplies a disclosed lens: standardize the smallest shared contract, then leave future decisions to actors with local information. RFC 5367 follows that restraint when it refuses to invent semantics for list bodies in subsequent SUBSCRIBE requests.

His Reality Layers note supplies the other lens. A list document, option tag, response code, notification and timer are symbolic records at different layers. None should be promoted into a stronger operational reality without the receipt that connects them. The protocol facts remain grounded in the RFCs and IANA registry; the notes frame their governance consequences.