A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)
Extracted elements (26)
Forked SUBSCRIBE requests are permitted for watcher information to accommodate deployments where subscription state is distributed across multiple servers (e.g., for load balancing). Each server independently accepts the watcherinfo subscription, and the subscriber aggregates state across all resulting dialogs. This allows a broad range of aggregation solutions without mandating a specific one.
State agents are the preferred solution to the distributed-server problem for watcher information. Each state agent maintains complete watcherinfo state for a set of resources; incoming watcherinfo subscriptions are routed to the appropriate agent, resulting in a single dialog and eliminating the need for subscriber-side aggregation across multiple dialogs.
The giveup event is generated in pending or waiting states to reclaim server resources held for unauthorized subscriptions. The giveup timer value must balance user experience (long enough for a user to log in days later) against DoS risk from resource exhaustion by attackers creating many pending subscriptions.
The waiting state is introduced so that a resource owner can log in at any time and discover subscriptions that arrived and expired while they were offline, enabling a deferred authorization decision. Without it, pending subscriptions that expired would be silently discarded, forcing repeated re-subscription with no record.
All watcherinfo subscribers and notifiers MUST support the application/watcherinfo+xml format (RFC 3858) and MUST list its MIME type in any Accept header field present in the SUBSCRIBE request.
All watcherinfo subscribers MUST be prepared to install multiple subscriptions as a result of receiving multiple NOTIFY messages in response to a single SUBSCRIBE, as may occur when a forking proxy distributes the request to multiple servers.
All watcherinfo subscriptions SHOULD be authenticated and then authorized before approval. Authentication MAY be performed using SIP digest, S/MIME, TLS, or other transport-specific mechanisms.
All watchers MUST support HTTP Digest authentication (as required by RFC 3261), enabling notifiers to authenticate watcherinfo subscribers and prevent spoofed subscriptions from exposing sensitive watcher information.
Clients SHOULD use an Expires header field to specify their preferred watcherinfo subscription duration rather than relying on the arbitrary one-hour default.
For congestion control, it is RECOMMENDED that a server not generate watcherinfo notifications for a single watcherinfo subscriber at a rate faster than once every 5 seconds.
It is RECOMMENDED that user A be allowed to subscribe to their own watcher information for any package, including recursively (e.g., foo.winfo.winfo for any foo).
It is RECOMMENDED that watcherinfo subscriptions for package foo for user A be allowed from user B only if B is an authorized subscriber to A within package foo, and that such notifications contain only the state of B's own subscription.
Servers SHOULD add policies prohibiting a particular subscriber from having more than some number of pending or waiting subscriptions, to limit resource consumption from unauthorized subscription state used in DoS attacks.
To avoid infinite recursion of authorization policy, it is RECOMMENDED that only user A be allowed to subscribe to foo.winfo.winfo for user A, and that servers do not authorize subscriptions to foo.winfo.winfo.winfo or deeper by default.
Watcherinfo notifications generated by the server MUST be in one of the formats specified in the Accept header field of the SUBSCRIBE request. If no Accept header field was present, notifications MUST use application/watcherinfo+xml.
Watcherinfo notifications SHOULD NOT be sent for transient subscription states. For example, a fetch by an authorized watcher that creates the FSM and moves it immediately from init→active→terminated should generate no notifications.
Watcherinfo notifications triggered by a fetch operation (SUBSCRIBE with Expires of 0) SHOULD result in the full state of all authorized watchers being present in the NOTIFY.
When a watcherinfo subscriber is also a direct subscriber to foo for the same resource, foo.winfo notifications SHOULD NOT report state changes that would not be reported in the Subscription-State header field on foo notifications.
A SUBSCRIBE for watcher information MAY contain a body for filtering purposes. Without a body, the default policy applies: notifications are generated on every state change, SUBSCRIBE-triggered notifications carry full state, and change-triggered notifications carry only the changed watcher's state.
No package-specific Event header field parameters are defined for the winfo event template-package.
The default subscription duration for a watcherinfo subscription is one hour. Watcherinfo subscriptions typically span the lifetime of the subscriptions being watched, ranging from minutes to days.
The watcher information template-package is named "winfo". Watcher information for any event package foo is denoted "foo.winfo". Recursive template-packaging is explicitly allowed, making "foo.winfo.winfo" a valid package name.
This specification registers an event template-package in the IANA SIP Event Package registry: Package Name "winfo", Template Package: yes, Published Specification: RFC 3857.
Watcher information reveals sensitive social-graph data (friends, family, business relations). To prevent eavesdropping, watcherinfo notifiers MUST support TLS and sips as if they were a proxy (per RFC 3261 Section 26.3.1), and subscribers MAY use the sips URI scheme. SIP S/MIME encryption MAY be used end-to-end for SUBSCRIBE and NOTIFY.
Watcherinfo subscriptions are vulnerable to DoS amplification: an attacker generating N unauthenticated subscriptions to a popular resource causes up to N^2 data to be sent to the resource owner's watcherinfo subscriber, since each of N NOTIFY messages can report on up to N watchers. Servers MUST NOT create subscription state for unauthenticated SUBSCRIBE requests and MUST NOT generate watcherinfo notifications for them.
The subscription FSM has five states: init (transient entry), pending (awaiting authorization), active (notifications flowing), waiting (expired pending subscription retained for later authorization), and terminated (destroyed). Triggers include: subscribe+policy=accept→active, subscribe+no-policy→pending, subscribe+policy=reject→terminated, approved→active, timeout→waiting (from pending), giveup→terminated, noresource/rejected/deactivated/probation→terminated.