Session Initiation Protocol (SIP) Extension for Event State Publication
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (26)
Entity-tags in PUBLISH use a token syntax (not HTTP/1.1 quoted-string), disallow multiple entity-tags in a precondition, and disallow the '*' wildcard, because PUBLISH is conceptually an HTTP PUT for which only a subset of HTTP cache-validation features is appropriate. Distinct header field names (SIP-ETag, SIP-If-Match vs. ETag, If-Match) make the differences from HTTP explicit.
PUBLISH creates soft state with a negotiated lifetime, analogous to REGISTER, so that the ESC can detect stale publications and clean them up automatically. Hard state (provisioned out-of-band) can coexist with soft state, enabling a fallback presence when all EPAs have gone silent.
A PUBLISH request MAY be sent within an existing dialog, but unless the other endpoint is also an ESC it will likely reject the request. Sending PUBLISH in-dialog is not prohibited but will typically not produce the expected behavior.
For presence event state segmentation, the EPA MUST keep tuple 'id' attributes consistent across publications within the same entity-tag context. A missing 'id' signals tuple removal; a new 'id' signals addition. The ESC interprets each tuple relative to the entity-tag of the arriving request.
A PUBLISH request that removes event state MUST have an Expires value of '0' and a SIP-If-Match header field, and MUST NOT contain a body.
An EPA MUST include a single Event header field in every PUBLISH request to indicate the event package for which event state is being published.
An initial PUBLISH request MUST NOT contain a SIP-If-Match header field, and MUST contain a body with the published event state.
EPAs MUST NOT send a new PUBLISH request (not a retransmission) for the same Request-URI until they have received a final response or the previous request has timed out.
ESCs and EPAs MUST implement Digest authentication for PUBLISH requests as defined in RFC 3261, including replay protection.
For integrity and confidentiality protection, ESCs MUST implement TLS, MUST support both mutual and one-way authentication, and MUST support the SIPS URI scheme. EPAs SHOULD be capable of initiating TLS and SHOULD support SIPS.
If an EPA receives a 412 (Conditional Request Failed) response, it MUST NOT reattempt that PUBLISH, MUST discard the associated entity-tag, and SHOULD perform an initial publication instead.
PUBLISH requests that refresh event state MUST NOT have a body. A refresh only extends the expiration time and does not alter the event state.
The 200 OK response to a successful PUBLISH MUST contain an Expires header field indicating the chosen expiration interval and MUST contain a SIP-ETag header field with the entity-tag identifying the publication.
The ESC MUST generate a new entity-tag for each successful publication, and the generated entity-tag MUST be unique from all other entity-tags currently assigned for that Request-URI and MUST differ from any previously assigned entity-tag for that Request-URI.
The ESC MUST ignore the Record-Route and Contact header fields in PUBLISH requests, and MUST NOT include a Record-Route header field in any PUBLISH response.
The ESC MUST process PUBLISH requests with the same Request-URI in the order received, and MUST process each request atomically — either completely or not at all.
The 412 (Conditional Request Failed) response code is added to SIP to indicate that the precondition given in a PUBLISH request (via SIP-If-Match) has failed, meaning no matching entity-tag was found at the ESC.
The PUBLISH method is a new SIP method for publishing event state. It allows a user agent (EPA) to create, modify, and remove event soft state in an Event State Compositor (ESC), similar to how REGISTER creates state in a registrar. PUBLISH does not establish a dialog.
The SIP-ETag header field carries an entity-tag assigned by the ESC to identify a specific publication. It is returned in the 2xx response to every successful PUBLISH request and must be unique among all currently active entity-tags for that Request-URI.
The SIP-If-Match header field carries an entity-tag in PUBLISH requests to condition the operation on a specific previously published event state. It is used for refresh, modify, and remove operations; initial publications must not include it.
This document registers three items in the IANA SIP parameters registry: the PUBLISH method name, the 412 (Conditional Request Failed) response code, and two new header field names SIP-ETag and SIP-If-Match (both with no compact form).
ESCs SHOULD authenticate EPAs and apply authorization policies to all PUBLISH requests, since published event state may be sensitive. Implementations MUST support Digest authentication with replay protection as defined in RFC 3261.
Man-in-the-middle attacks on PUBLISH can install, modify, or remove event state. Integrity protection SHOULD cover the To, From, Event, SIP-If-Match, Route, and Expires headers and the body. If integrity protection is end-to-end, the ESC MUST NOT modify the event state before exposing it to subscribers.
PUBLISH-based DoS attacks can create resource exhaustion at the ESC. Mitigations include requiring authentication, throttling incoming publications, using minimum Expires values to reduce refresh rate, and debounce logic to limit downstream NOTIFY traffic.
Event soft state at the ESC transitions through: created (on initial PUBLISH with body, no SIP-If-Match), refreshed (PUBLISH with SIP-If-Match, no body, Expires > 0), modified (PUBLISH with SIP-If-Match, body, Expires > 0), and removed (PUBLISH with SIP-If-Match, no body, Expires = 0 or expiry elapsed). A 412 response signals the state is no longer valid.
The entity-tag syntax is defined as a token (not a quoted-string as in HTTP/1.1). SIP-ETag = 'SIP-ETag' HCOLON entity-tag; SIP-If-Match = 'SIP-If-Match' HCOLON entity-tag; entity-tag = token. No weak entity-tag prefix or wildcard '*' is defined.