RFC 3903

Session Initiation Protocol (SIP) Extension for Event State Publication

📅 published November 2004, from ietf

RFC 3903: Session Initiation Protocol (SIP) Extension for Event State Publication 🎀

Part 1 of 7 💅

Okay so, this is RFC 3903, and it's giving "how to publish your status updates without the whole group chat seeing the drafts" 🫶. It's titled Session Initiation Protocol (SIP) Extension for Event State Publication, it came from the Network Working Group, and A. Niemi, Ed. from Nokia wrote it. It's a Standards Track document, dated October 2004. The header doesn't list anything it obsoletes or updates, so it's a clean new addition 🌸

Status of This Memo

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🧚 If you want to check where the protocol stands right now, look at the current edition of the "Internet Official Protocol Standards" (STD 1). And yes, distribution of this memo is unlimited ✨

Copyright (C) The Internet Society (2004) 💜

Abstract

This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is publishing presence information 🦋

The mechanism here can be extended to publish any event state that has an appropriate event package. It is not meant to be a general-purpose way to transport arbitrary data, since there are better-suited mechanisms for that purpose 🙈

Table of Contents

1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
2.   Definitions and Document Conventions . . . . . . . . . . . .   3
3.   Overall Operation  . . . . . . . . . . . . . . . . . . . . .   4
4.   Constructing PUBLISH Requests  . . . . . . . . . . . . . . .   5
     4.1.  Identification of Published Event State. . . . . . . .   6
     4.2.  Creating Initial Publication . . . . . . . . . . . . .   7
     4.3.  Refreshing Event State . . . . . . . . . . . . . . . .   8
     4.4.  Modifying Event State  . . . . . . . . . . . . . . . .   9
     4.5.  Removing Event State . . . . . . . . . . . . . . . . .   9
5.   Processing PUBLISH Responses . . . . . . . . . . . . . . . .  10
6.   Processing PUBLISH Requests  . . . . . . . . . . . . . . . .  10
7.   Processing OPTIONS Requests  . . . . . . . . . . . . . . . .  13
8.   Use of Entity-tags in PUBLISH  . . . . . . . . . . . . . . .  13
     8.1.  General Notes. . . . . . . . . . . . . . . . . . . . .  13
     8.2.  Client Usage . . . . . . . . . . . . . . . . . . . . .  14
     8.3.  Server Usage . . . . . . . . . . . . . . . . . . . . .  14
9.   Controlling the Rate of Publication  . . . . . . . . . . . .  15
10.  Considerations for Event Packages using PUBLISH  . . . . . .  15
     10.1. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . .  16
     10.2. PUBLISH Response Bodies. . . . . . . . . . . . . . . .  16
     10.3. Multiple Sources for Event State . . . . . . . . . . .  16
     10.4. Event State Segmentation . . . . . . . . . . . . . . .  17
     10.5. Rate of Publication. . . . . . . . . . . . . . . . . .  17
11.  Protocol Element Definitions . . . . . . . . . . . . . . . .  17
     11.1. New Methods. . . . . . . . . . . . . . . . . . . . . .  17
           11.1.1. PUBLISH Method . . . . . . . . . . . . . . . .  17
     11.2. New Response Codes . . . . . . . . . . . . . . . . . .  19
           11.2.1. "412 Conditional Request Failed" Response Code  19
     11.3. New Header Fields  . . . . . . . . . . . . . . . . . .  20
           11.3.1. "SIP-ETag" Header Field  . . . . . . . . . . .  20
           11.3.2. "SIP-If-Match" Header Field  . . . . . . . . .  20
12.  Augmented BNF Definitions  . . . . . . . . . . . . . . . . .  21
13.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  21
     13.1. Methods  . . . . . . . . . . . . . . . . . . . . . . .  21
     13.2. Response Codes . . . . . . . . . . . . . . . . . . . .  21
     13.3. Header Field Names . . . . . . . . . . . . . . . . . .  21
14.  Security Considerations  . . . . . . . . . . . . . . . . . .  22
     14.1. Access Control . . . . . . . . . . . . . . . . . . . .  22
     14.2. Denial of Service Attacks  . . . . . . . . . . . . . .  22
     14.3. Replay Attacks . . . . . . . . . . . . . . . . . . . .  22
     14.4. Man in the Middle Attacks  . . . . . . . . . . . . . .  23
     14.5. Confidentiality  . . . . . . . . . . . . . . . . . . .  23
15.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  24
16.  Contributors . . . . . . . . . . . . . . . . . . . . . . . .  29
17.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  30
18.  References . . . . . . . . . . . . . . . . . . . . . . . . .  30
     18.1. Normative References . . . . . . . . . . . . . . . . .  30
     18.2. Informative References . . . . . . . . . . . . . . . .  31
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . .  31
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .  32

1. Introduction ✨

Okay so this spec gives you a framework for publishing event state from a user agent to an entity that pulls that state together (the compositor) and then distributes it to interested parties through the SIP Events [1] framework 💖

On top of the framework, this spec defines a concrete usage for publishing presence state [2]. Here, a presence user agent [3] publishes to a presence compositor, which is tightly coupled with the presence agent [1] 🫶

The requirements and model for presence publication are documented in [10], and this specification addresses each of those requirements 🌈

Same vibe as before: the mechanism can be extended to publish any event state that has an appropriate event package, as defined in [1]. For example, an application of SIP events for message waiting indications [11] might use PUBLISH to collect the statuses of voice-mail boxes across a set of user agents. The compositor in that kind of app would then collect that state and distribute it to the event package's subscribers 📬

Every application that uses the PUBLISH mechanism to publish event state needs to follow the guidelines in Section 10 🌸 And again, the mechanism is not meant to be a general-purpose way to transport arbitrary data, since there are better-suited mechanisms for that 🙈

2. Definitions and Document Conventions 📖

Along with the definitions from RFC 2778 [3], RFC 3265 [1], and RFC 3261 [4], this document introduces some new concepts 🦋

  • Event State: State information for a resource, associated with an event package and an address-of-record.
  • Event Publication Agent (EPA): The User Agent Client (UAC) that issues PUBLISH requests to publish event state.
  • Event State Compositor (ESC): The User Agent Server (UAS) that processes PUBLISH requests, and is responsible for compositing event state into a complete, composite event state of a resource.
  • Presence Compositor: A type of Event State Compositor that is responsible for compositing presence state for a presentity.
  • Publication: The act of an EPA sending a PUBLISH request to an ESC to publish event state.
  • Event Hard State: The steady-state or default event state of a resource, which the ESC may use in the absence of, or in addition to, soft state publications.
  • Event Soft State: Event state published by an EPA using the PUBLISH mechanism. A protocol element (i.e., an entity-tag) is used to identify a specific soft state entity at the ESC. Soft state has a defined lifetime and will expire after a negotiated amount of time.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [5] and indicate requirement levels for compliant implementations. These are the big-deal words, so they're the ones to watch 👑

Indented passages such as this one are used in this document to provide additional information and clarifying text. They do not contain descriptions of normative protocol behavior. 💅

3. Overall Operation 🧚

This document defines a new SIP method, PUBLISH, for publishing event state. PUBLISH is similar to REGISTER in that it lets a user create, modify, and remove state in another entity, which manages that state on the user's behalf 🎀 Addressing a PUBLISH request is identical to addressing a SUBSCRIBE request. The Request-URI of a PUBLISH request is filled with the address of the resource the user wants to publish event state for 💖

A user can have multiple User Agents or endpoints that publish event state. Each endpoint can publish its own unique state, and the event state compositor uses all of it to generate the composite event state of the resource 🌈 Besides the resource, all published event state is tied to one specific event package. By subscribing to that package, the user can discover the composite event state of all the active publications ✨

A User Agent Client (UAC) that publishes event state is called an Event Publication Agent (EPA). For presence, this is the familiar Presence User Agent (PUA) role defined in [2]. The entity that processes the PUBLISH request is the Event State Compositor (ESC). For presence, this is the familiar Presence Agent (PA) role defined in [2] 🦋

PUBLISH requests create soft state in the ESC. This event soft state has a defined lifetime and will expire after a negotiated amount of time, so the publication has to be refreshed by later PUBLISH requests 🫧 There may also be event hard state provisioned for each resource for a particular event package. That hard state represents the resource state that is there at all times, and it does not expire 👑 The ESC may use event hard state in the absence of, or in addition to, event soft state provided through the PUBLISH mechanism. Setting this event hard state, or configuring the ESC policy for aggregating different event state, is out of scope for this specification 🙈

The body of a PUBLISH request carries the published event state. For every successful PUBLISH request, the ESC assigns an identifier to the publication in the form of an entity-tag. The EPA then uses that identifier in any later PUBLISH request that modifies, refreshes, or removes the event state of that publication 🔥 When event state expires or is explicitly removed, the entity-tag attached to it becomes invalid. A publication with an invalid entity-tag will simply fail, so the EPA has to start fresh and resend its event state without referencing a previous entity-tag 💀

Part 1 of 7 done 🎀

4. Constructing PUBLISH Requests ✨

okay so PUBLISH requests are how you create, modify, and remove event state tied to an address-of-record 💅 and a suitably authorized third party can also publish on behalf of a particular address-of-record 🫶

Except where noted, building a PUBLISH request and how clients behave when sending one is exactly the same as the general UAC behavior in Section 8.1 and Section 17.1 of RFC 3261 [4]. no need to reinvent the wheel bestie 🎀

if you need to, clients can check for PUBLISH support with the OPTIONS request defined in SIP [4]. if PUBLISH shows up in the Allow header field of the OPTIONS response, that means the method is supported 🦋 and the Allow-Events header field tells you which event packages are supported too 🌈

Note that the OPTIONS request can fork, so the response might come back from a User Agent that isn't the ESC 💀 in that case, support for the PUBLISH method might not be accurately shown for that particular Request-URI.

a PUBLISH request does not establish a dialog 🧚 a UAC MAY include a Route header field in a PUBLISH request based on a route set that already exists, as described in Section 8.1 of RFC 3261 [4]. the Record-Route header field means nothing in PUBLISH requests or responses, so it MUST be ignored if it's there 🙈 and the UAC MUST NOT make a new route set based on whether a Record-Route header field shows up (or doesn't) in any response to a PUBLISH request. main character energy for ignoring it 👑

the PUBLISH request MAY have a Contact header field, but putting one in has no meaning in the event publication context, and the ESC will ignore it 🍓 an EPA MAY send a PUBLISH request inside an existing dialog. if it does, the request is handled in the context of whatever media session or sessions go with that dialog ✨

Note that sending a PUBLISH request inside an existing dialog isn't prohibited, but it won't usually get the result you're hoping for 😭 unless the other end of the dialog is also an ESC, it'll probably reject the request.

EPAs MUST NOT send a new PUBLISH request (one that isn't a re-transmission) for the same Request-URI until they've gotten a final response from the ESC for the previous one, or until the previous PUBLISH request has timed out. wait your turn bestie 🫶💅

4.1. Identification of Published Event State

three things identify published event state: the Request-URI, the event type, and (optionally) an entity-tag 🔥

the Request-URI of a PUBLISH request has enough info to route the request to the right entity, following the request routing procedures in RFC 3261 [4] 🦋 it also has enough info to identify the resource whose event state is being published, but it does NOT tell you what type of published event state it is 🙃

so to figure out the type, the EPA MUST include a single Event header field in PUBLISH requests 💖 the value of that header says which event package this request is publishing event state for ✨

for every successful PUBLISH request, the ESC generates an entity-tag and sends it back in the SIP-ETag header field of the 2xx response 🌸

when you're updating event state that was already published, PUBLISH requests MUST contain a single SIP-If-Match header field that identifies the exact event state you're refreshing, modifying, or removing 🎀 that header field MUST contain a single entity-tag that the ESC gave back in the SIP-ETag header field of the response to an earlier publication. no mix-ups allowed 😤

the PUBLISH request MAY contain a body with the event state the client wants to publish 🧁 the content format and semantics depend on the event package named in the Event header field 💜

whether there's a body and whether there's a SIP-If-Match header field decides which operation the request is doing, as shown in Table 1 👑

+-----------+-------+---------------+---------------+
| Operation | Body? | SIP-If-Match? | Expires Value |
+-----------+-------+---------------+---------------+
| Initial   | yes   | no            | > 0           |
| Refresh   | no    | yes           | > 0           |
| Modify    | yes   | yes           | > 0           |
| Remove    | no    | yes           | 0             |
+-----------+-------+---------------+---------------+

           Table 1: Publication Operations

an 'Initial' publication sets the starting event state for a particular EPA 🐣 there can already be event state published by other EPAs for the same address-of-record, and an initial publication doesn't touch that state at all 🤍 a 'Refresh' publication refreshes the lifetime of a previous publication, while a 'Modify' publication changes the event state of a previous publication ✏️ and a 'Remove' publication asks for event state to be removed right away 🗑️ we'll go through each of these in more detail in the next sections, so stay tuned 💅

4.2. Creating Initial Publication

okay so an initial publication is a PUBLISH request that the EPA creates and sends to the ESC 🌷 it sets up soft state for the event package in the Event header field, and it's bound to the address in the Request-URI 🦋

an initial PUBLISH request MUST NOT contain a SIP-If-Match header field 🙅‍♀️ however, if the EPA thinks a locally stored entity-tag is still valid, it SHOULD try to modify that event state first (as described in Section 4.4) instead of sending an initial publication. not the vibe to start over when you don't have to 🥺

an initial PUBLISH request MUST contain a body that holds the published event state 🎁

an initial PUBLISH request MAY contain a single Expires header field 💫 this value is the suggested lifetime of the event state publication ⏰

the ESC may lower the suggested lifetime of the publication, but it will NEVER extend it 😤 if there's no Expires header field, the EPA is basically saying "you pick" 🫠 the Expires header field in a 2xx response to the initial PUBLISH tells the EPA how long the publication will actually stay active ✨ unless it gets refreshed before that lifetime runs out, the publication expires 💀

4.3. Refreshing Event State

an EPA is responsible for refreshing its earlier publications before their expiration interval runs out 🕰️ to refresh one, the EPA MUST create a PUBLISH request that has the entity-tag of the publication being refreshed in a SIP-If-Match header field 🎀

the SIP-If-Match header field with an entity-tag makes the PUBLISH request only refresh that specific event state from an earlier publication 🎯 if the entity-tag matches the event state the ESC has, the refresh works and the EPA gets a 2xx response 🥳

just like the 2xx response to an initial PUBLISH request, the 2xx response to a refresh PUBLISH request has a SIP-ETag header field with an entity-tag 🏷️ the EPA MUST store this entity-tag, replacing any existing entity-tag for the refreshed event state 💖 see Section 8.2 for more on how the EPA handles entity-tags 📚

if there's no matching event state (say the event state being refreshed has already expired), the EPA gets a 412 (Conditional Request Failed) response to the PUBLISH request 😬

a publication refresh MAY contain a single Expires header field 🌈 this value is the suggested lifetime of the event state ⏳

the ESC may lower the suggested lifetime of the publication refresh, but it will never extend it 🙅‍♀️ if there's no Expires header field, the EPA is leaving it up to the ESC to choose 🤷‍♀️ the Expires header field in a 2xx response to the publication refresh tells the EPA how long the publication will actually stay active 🦋

a publication refresh only extends the expiration time of event state that already exists, and it doesn't change that event state in any other way 🫶 so a PUBLISH request that refreshes event state MUST NOT have a body 🚫

4.4. Modifying Event State

modifying event state is pretty similar to creating initial event state 🎨 the difference is that instead of setting up brand new event state at the ESC, you're updating event state that already exists with modified event state ✏️ how the update works depends on what's in the body and on the semantics of that body's format 💜

to modify event state, the EPA MUST construct a PUBLISH request that has the entity-tag of the event state publication being modified in a SIP-If-Match header field 🎀 a PUBLISH request that modifies event state MUST contain a body with the modified event state 🧁

the SIP-If-Match header field makes the PUBLISH request only modify the specific event state from an earlier publication, the one identified by that entity-tag 🎯 if the entity-tag matches the event state the ESC already has, that event state gets replaced by the event state in the PUBLISH request, and the EPA gets a 2xx response 🥳

just like the 2xx response to an initial PUBLISH request, the 2xx response to a modifying PUBLISH request has a SIP-ETag header field with an entity-tag 🏷️ the EPA MUST store this entity-tag, replacing any existing entity-tag for the modified event state 💖 see Section 8.2 for more on how the EPA handles entity-tags 📚

if there's no matching event state at the ESC (say the event state being modified has already expired), the EPA gets a 412 (Conditional Request Failed) response to the PUBLISH request 😭

a modifying PUBLISH request MAY contain a single Expires header field 🌸 this value is the suggested lifetime of the event state publication ⏰

the ESC may lower the suggested lifetime of the publication, but it will never extend it 😤 if there's no Expires header field, the EPA is leaving it up to the ESC to choose 🫠 the Expires header field in a 2xx response to the modifying PUBLISH request tells the EPA how long the publication will actually stay active ✨ unless it gets refreshed before that lifetime runs out, the publication will expire 💀

4.5. Removing Event State

event state from an earlier publication can also be removed on purpose 🗑️

to ask for event state to be removed right away, an EPA MUST create a PUBLISH request with an Expires value of "0", and set the SIP-If-Match header field to contain the entity-tag of the event state publication being removed 🫡

Note that removing event state is basically a publication refresh with an infinitesimal expiration interval 🤯 so the refreshed event state expires right after it gets refreshed. literally a speedrun to the exit 🏃‍♀️💨

similar to an event state refresh, removing event state only affects the expiry of the event state 🎀 so a PUBLISH request that removes event state MUST NOT contain a body 🚫 ✨

5. Processing PUBLISH Responses 💌

okay so when a PUBLISH response comes back, the steps in Section 8.1.2 of RFC 3261 [4] apply. that's the rulebook for responses, so no surprises there 🧚

if an EPA gets a 412 (Conditional Request Failed) response, it MUST NOT reattempt the PUBLISH request. 🙅‍♀️ instead, to publish event state, the EPA SHOULD do an initial publication (aka a PUBLISH with no SIP-If-Match header field, see Section 4.2) 💖 and it MUST also throw away the entity-tag that caused this error. bye bye, bad tag 🗑️

if an EPA gets a 423 (Interval Too Brief) response to a PUBLISH, it MAY retry the publication after bumping the Expires header field so it's equal to or bigger than the expiration interval in the Min-Expires header field of that 423 response. lowkey the server is basically saying "okay sweetie, try a longer one" 🌸

6. Processing PUBLISH Requests 👑

the Event State Compositor (ESC) is a User Agent Server (UAS) that handles PUBLISH requests, answers them, and keeps a list of publications for each address-of-record. ✨ the ESC has to know (through configuration, for example) which addresses it's keeping event state for. it's the main character of this whole section, periodt 💅

a few vibes checks first:

  • the ESC MUST ignore the Record-Route header field if one shows up in a PUBLISH request.
  • the ESC MUST NOT put a Record-Route header field in any response to a PUBLISH request. no cap, never.
  • the ESC MUST ignore the Contact header field if it's in a PUBLISH request.

also, PUBLISH requests with the same Request-URI MUST be processed in the order they arrive 🍓 and PUBLISH requests MUST be processed atomically, which just means a single PUBLISH is either fully processed or not processed at all. no half-finished nonsense 🫶

when the ESC gets a PUBLISH, it follows the general UAS behavior in Section 8.2 of RFC 3261 [4]. on top of that, here are the PUBLISH-specific steps it follows:

  1. Check the Request-URI. the ESC looks at the Request-URI to see if it's aimed at a resource the ESC is responsible for keeping event state for. if it isn't, the ESC MUST return a 404 (Not Found) response and skip the remaining steps. 🙈

the Request-URI could also point to a domain the ESC doesn't look after. in that case, the UAS that got the request can act as a proxy server and forward it to a better target. helpful bestie energy 🦋

  1. Check the Event header field. if the Event header field is missing, or it has an event package the ESC doesn't support, the ESC MUST respond with a 489 (Bad Event) response and skip the remaining steps. 💀
  2. Check the SIP-If-Match header field. this is where we see whether the request has a precondition.
    • if there's no SIP-If-Match header field, the ESC MUST generate and store a locally unique entity-tag to identify the publication. this entity-tag is linked to the event state in the body of the PUBLISH request 🎀
    • else, if the request has a SIP-If-Match header field, the ESC checks whether it holds a single entity-tag. if it doesn't, the request is invalid, so the ESC MUST return a 400 (Invalid Request) response and skip the remaining steps. ✋
    • else, the ESC pulls the entity-tag out of the SIP-If-Match header field and matches it against all the locally stored entity-tags for this resource and event package. if there's no match, the ESC MUST reject the publication with a 412 (Conditional Request Failed) response and skip the remaining steps. 🙃
  3. Process the Expires header field. this sets how long the publication lasts 🧚
    • if the request has an Expires header field, that value MUST be taken as the requested expiration.
    • else, a locally-configured default value MUST be taken as the requested expiration.
    • the ESC MAY pick an expiration that's shorter than the requested one. 🤷‍♀️ only if the requested expiration interval is greater than zero and less than a locally-configured minimum, the ESC MAY reject the publication with a 423 (Interval Too Brief) response and skip the remaining steps. that response MUST contain a Min-Expires header field that says the minimum expiration interval the ESC is willing to honor. ⏰
  4. Process the event state. the ESC handles the published event state in the body of the PUBLISH request. if the content type doesn't match the event package, or the ESC doesn't understand it, the ESC MUST reject the request with an appropriate response, like 415 (Unsupported Media Type), and skip the rest of the steps. 🙅‍♀️
    • the ESC stores the event state from the body of the PUBLISH request, identified by its entity-tag, and updates any existing event state for that entity-tag. the expiration value gets set to the chosen expiration interval. ✅
    • if the request has no message body and no entity-tag, the ESC SHOULD reject it with an appropriate response, like 400 (Invalid Request), and skip the rest of the steps. BUT, if the ESC's local policy or the event package has defined what an initial publication with no message body means, the ESC MAY accept it instead. 🧐
    • else, the event state identified by the entity-tag gets refreshed, with the expiration value set to the chosen expiration interval. 🔄
    • if the chosen expiration interval has the special value of "0", the event state identified by the entity-tag MUST be removed right away. the ESC MUST NOT store any event state because of a request like that. 🗑️💨

the processing of the PUBLISH request MUST be atomic. 🫧 if internal errors happen before processing is finished (like not being able to reach a back-end database), the publication MUST NOT succeed, and the ESC MUST fail with an appropriate error response, like 504 (Server Time-out), and skip the last step. yikes 😭

  1. Send the 200 response. the ESC returns a 200 (OK) response. the response MUST contain an Expires header field showing the expiration interval the ESC chose. ⭐ the response MUST also contain a SIP-ETag header field with a single entity-tag that identifies the publication. the ESC MUST generate a new entity-tag for every successful publication, replacing any previous entity-tag for that event state. the new entity-tag MUST be unique from any other entity-tags currently assigned to event state for that Request-URI, and it MUST be different from any entity-tag ever assigned to event state for that Request-URI before. see Section 8.3 for more on how the ESC handles entity-tags 🫶

7. Processing OPTIONS Requests 🔍

a client may check whether the ESC supports PUBLISH by sending an OPTIONS request, as defined in SIP [4]. the ESC handles OPTIONS requests as defined in Section 11.2 of RFC 3261 [4]. in the response to an OPTIONS request, the ESC SHOULD add "PUBLISH" to the list of allowed methods in the Allow header field. it SHOULD also list the supported event packages in an Allow-Events header field. 📋

the Allow header field can also be used to announce PUBLISH support when registering. 🧾 (see SIP Capabilities [12] for details)

8. Use of Entity-tags in PUBLISH 🏷️

this section is a general overview of how entity-tags get used in PUBLISH. it's informative, so it has no normative protocol description. just vibes and context, not rules 💖

8.1. General Notes ✍️

PUBLISH uses entity-tags, as defined in HTTP/1.1 [13]. the main idea carries over, but the syntax and semantics for entity-tags and their header fields get adapted specifically for PUBLISH. the main differences are:

  • the syntax for entity-tags is a token, not a quoted-string. there's also no prefix for marking a weak entity-tag. 🙅‍♀️
  • a PUBLISH precondition can only apply to a single entity-tag, so preconditions with multiple entity-tags aren't allowed. ☝️
  • a request precondition can't apply to "any" entity. there's no special "*" entity-tag value defined for PUBLISH. 🚫
  • in HTTP/1.1, returning an entity-tag is optional for origin servers. in PUBLISH, though, ESCs are required to always return an entity-tag for a successful publication. big difference! 👀

the reason for these changes is that PUBLISH is basically an HTTP PUT, and HTTP/1.1 only allows a subset of entity-tag cache validation features for PUT. it doesn't make sense to turn on any other features for publishing event state 🧠

the header field names weren't copied straight from HTTP/1.1. instead, similar but different names were created, so it's clear that entity-tag usage in PUBLISH is similar to HTTP/1.1 but not identical. you can see them in Section 11. 🎀

8.2. Client Usage 📱

each successful publication gets an entity-tag, which the ESC sends back to the EPA in the response to the PUBLISH request. the EPA needs to store that entity-tag and replace any previous entity-tag for that event state. if a request fails with a 412 (Conditional Request Failed) response, the EPA throws away the entity-tag that caused the failure. 🗑️

entity-tags are opaque tokens to the EPA. the EPA can't infer any semantics from an entity-tag beyond a simple identifier, and it can't assume a specific format. an entity-tag could be a monotonically increasing counter, or it could be a totally random token. 🎲 it's up to the ESC implementation to decide how the entity-tag is formatted. 💅

8.3. Server Usage 🖥️

the ESC generates and maintains entity-tags. they're part of the state the ESC keeps, along with the actual event state and its remaining expiration interval. an entity-tag is generated and stored for each successful event state publication, and returned to the EPA in a 200 (OK) response. whenever the EPA sends a publication that updates an earlier one, it includes an entity-tag the ESC can use as a search key in its set of active publications. 🔑

how an entity-tag gets generated is up to the implementation. one possible way is an integer counter that goes up by one for every successfully processed publication. other equally valid ways to generate entity-tags exist, and this document doesn't recommend or prefer any single one. ✨

9. Controlling the Rate of Publication ✨

okay so bestie, the ESC is the one collecting state from what could be a LOT of sources, which means it can get buried in publication traffic 😭🌊. Luckily there are a couple of ways to cut down on how many PUBLISH requests it gets 💅

  • The ESC can have a say in the expiration interval for a publication 🦋. If its local default minimum expiration value isn't reached, it can insist that the EPA picks a longer value than the one it suggested. Keeping that default minimum longer at the ESC means publications get refreshed less often, which is so chill 🧘‍♀️
  • Another move is a SIP-level push-back to quench one specific source of publication traffic 🙅‍♀️. To push back on publications from a particular source, the ESC MAY respond to a PUBLISH request with a 503 (Service Unavailable), as defined in RFC 3261 [4]. This response SHOULD contain a Retry-After header field indicating the time interval that the publication source is required to wait before sending another PUBLISH request.

At the time of writing, work on managing load in SIP is just getting started, and it might give us more tools for managing load in event state publication systems 🔮✨

10. Considerations for Event Packages using PUBLISH 🎀

This section is the "hey, don't forget these" list 📝 for when you're using PUBLISH with event packages. It also shows how all of this plays out for presence publication 💖

Any future event package specification SHOULD include a discussion of its considerations for using PUBLISH. At a minimum, those considerations SHOULD cover the issues in this chapter, and they MAY add more 🫶

10.1. PUBLISH Bodies

The body of the PUBLISH request typically carries the published event state 📦. Any application of the PUBLISH mechanism for a given event package MUST define what content type or types are expected in PUBLISH requests. Each event package MUST also describe the semantics associated with that content type, and MUST prescribe a default, mandatory to implement MIME type 🔥

This document defines the semantics of the presence publication requests (event package "presence") when the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) [6] is used 💅 A PUA that uses PUBLISH to publish presence state to the PA MUST support the PIDF presence format. It MAY support other formats.

10.2. PUBLISH Response Bodies

The response to a PUBLISH request tells you whether the request was successful or not ✅ In general, the body of that response will be empty, unless the event package gives explicit meaning to it.

There is no such meaning for the body of a response to a presence publication 🙈

10.3. Multiple Sources for Event State

For some event packages, the underlying model is a single entity aggregating event state (the ESC), plus multiple sources, only some of which may be using the PUBLISH mechanism 🧚

Sources for event state other than those using the PUBLISH mechanism are explicitly allowed. However, defining those interfaces is beyond the scope of this document, so that's a whole other story 📖

Event packages that make use of the PUBLISH mechanism SHOULD describe whether this model for event state publication is applicable, and MAY describe specific mechanisms used for aggregating publications from multiple sources.

For presence, a PUA can publish presence state for just a subset of the tuples that may be composited into the presence document that watchers receive in a NOTIFY 🌸 How the ESC aggregates this information is a matter of local policy and out of scope for this specification.

10.4. Event State Segmentation

For some event packages, there's a natural decomposition of event state into segments 🍓 Each segment is one of potentially many identifiable sections in the published event state. Any event package whose content type supports this kind of segmentation SHOULD describe the way the ESC identifies these event state segments.

In presence publication, the EPA MUST keep the "id" attributes of tuples consistent in the context of an entity-tag 🔐 If a publication modifies the contents of a tuple, that tuple MUST maintain its original "id". The ESC interprets each tuple in the context of the entity-tag the request arrived with. A tuple whose "id" is missing compared to the original publication is considered removed 🗑️ Similarly, a tuple is interpreted as being added if its "id" attribute is one the original publication did not contain ✨

10.5. Rate of Publication

Controlling the rate of publication was covered in Section 9 🙌 Individual event packages MAY in turn define recommendations (SHOULD or MUST strength) on absolute maximum rates at which a single EPA is allowed to generate publications.

There are no rate limiting recommendations for presence publication 💜

11. Protocol Element Definitions 🧩

This section describes the extensions required for event publication in SIP 🦋

11.1. New Methods

11.1.1. PUBLISH Method

"PUBLISH" is added to the definition of the element "Method" in the SIP message grammar. Like all other SIP methods, the method name is case sensitive 🔡 PUBLISH is used to publish event state to an entity responsible for compositing that event state.

Table 2 and Table 3 extend Tables 2 and 3 of RFC 3261 [4] by adding an additional column, which defines the header fields that can be used in PUBLISH requests and responses 📋 The keys in these tables are specified in Section 20 of RFC 3261 [4].

+---------------------+---------+---------+
| Header Field        |  where  | PUBLISH |
+---------------------+---------+---------+
| Accept              |    R    |    o    |
| Accept              |   2xx   |    -    |
| Accept              |   415   |    m*   |
| Accept-Encoding     |    R    |    o    |
| Accept-Encoding     |   2xx   |    -    |
| Accept-Encoding     |   415   |    m*   |
| Accept-Language     |    R    |    o    |
| Accept-Language     |   2xx   |    -    |
| Accept-Language     |   415   |    m*   |
| Alert-Info          |         |    -    |
| Allow               |    R    |    o    |
| Allow               |    r    |    o    |
| Allow               |   405   |    m    |
| Allow-Events        |    R    |    o    |
| Allow-Events        |   489   |    m    |
| Authentication-Info |   2xx   |    o    |
| Authorization       |    R    |    o    |
| Call-ID             |    c    |    m    |
| Call-Info           |         |    o    |
| Contact             |    R    |    -    |
| Contact             |   1xx   |    -    |
| Contact             |   2xx   |    -    |
| Contact             |   3xx   |    o    |
| Contact             |   485   |    o    |
| Content-Disposition |         |    o    |
| Content-Encoding    |         |    o    |
| Content-Language    |         |    o    |
| Content-Length      |         |    t    |
| Content-Type        |         |    *    |
| CSeq                |    c    |    m    |
| Date                |         |    o    |
| Event               |    R    |    m    |
| Error-Info          | 300-699 |    o    |
| Expires             |         |    o    |
| Expires             |   2xx   |    m    |
| From                |    c    |    m    |
| In-Reply-To         |    R    |    -    |
| Max-Forwards        |    R    |    m    |
| Min-Expires         |   423   |    m    |
| MIME-Version        |         |    o    |
| Organization        |         |    o    |
+---------------------+---------+---------+

Table 2: Summary of header fields, A--O

+---------------------+-----------------+---------+
| Header Field        |      where      | PUBLISH |
+---------------------+-----------------+---------+
| Priority            |        R        |    o    |
| Proxy-Authenticate  |       407       |    m    |
| Proxy-Authenticate  |       401       |    o    |
| Proxy-Authorization |        R        |    o    |
| Proxy-Require       |        R        |    o    |
| Record-Route        |                 |    -    |
| Reply-To            |                 |    -    |
| Require             |                 |    o    |
| Retry-After         | 404,413,480,486 |    o    |
| Retry-After         |     500,503     |    o    |
| Retry-After         |     600,603     |    o    |
| Route               |        R        |    c    |
| Server              |        r        |    o    |
| Subject             |        R        |    o    |
| Supported           |        R        |    o    |
| Supported           |       2xx       |    o    |
| Timestamp           |                 |    o    |
| To                  |       c(1)      |    m    |
| Unsupported         |       420       |    o    |
| User-Agent          |                 |    o    |
| Via                 |        R        |    m    |
| Via                 |        rc       |    m    |
| Warning             |        r        |    o    |
| WWW-Authenticate    |       401       |    m    |
| WWW-Authenticate    |       407       |    o    |
+---------------------+-----------------+---------+

Table 3: Summary of header fields, P--Z

11.2. New Response Codes

11.2.1. "412 Conditional Request Failed" Response Code

The 412 (Conditional Request Failed) response is added to the "Client-Error" header field definition 🙅 It's used to indicate that the precondition given for the request has failed 💀

11.3. New Header Fields

Tables 4, 5, and 6 expand on Table 3 in SIP [4], as amended by the changes in Section 11.1 🎀

+--------------+-------+-------+-----+-----+-----+-----+-----+
| Header Field | where | proxy | ACK | BYE | CAN | INF | INV |
+--------------+-------+-------+-----+-----+-----+-----+-----+
| SIP-ETag     |  2xx  |       |  -  |  -  |  -  |  -  |  -  |
| SIP-If-Match |   R   |       |  -  |  -  |  -  |  -  |  -  |
+--------------+-------+-------+-----+-----+-----+-----+-----+

Table 4: Summary of header fields, P--Z

+--------------+-------+-------+-----+-----+-----+-----+-----+
| Header Field | where | proxy | NOT | OPT | PRA | REG | SUB |
+--------------+-------+-------+-----+-----+-----+-----+-----+
| SIP-ETag     |  2xx  |       |  -  |  -  |  -  |  -  |  -  |
| SIP-If-Match |   R   |       |  -  |  -  |  -  |  -  |  -  |
+--------------+-------+-------+-----+-----+-----+-----+-----+

Table 5: Summary of header fields, P--Z

+--------------+-------+-------+-----+-----+-----+---------+
| Header Field | where | proxy | UPD | MSG | REF | PUBLISH |
+--------------+-------+-------+-----+-----+-----+---------+
| SIP-ETag     |  2xx  |       |  -  |  -  |  -  |    m    |
| SIP-If-Match |   R   |       |  -  |  -  |  -  |    o    |
+--------------+-------+-------+-----+-----+-----+---------+

Table 6: Summary of header fields, P--Z

11.3.1. "SIP-ETag" Header Field

SIP-ETag is added to the definition of the element "general-header" in the SIP message grammar 🏷️ Usage of this header is described in Section 4 and Section 6 💖

11.3.2. "SIP-If-Match" Header Field ✨

okay so SIP-If-Match gets tucked into the general-header element of the SIP message grammar 🎀 It's a brand new header that shows up in the grammar with the rest of the general headers, and you'll see how it's used in Section 4 and Section 6 🦋

12. Augmented BNF Definitions 📜

this section is where the new syntax lives. it's all the extra grammar that event publication needs in SIP 💅 the formal definitions are written in the Augmented BNF [7] format that SIP [4] uses, so they lean on elements that are already defined over there. no need to reinvent the wheel bestie 🫶

PUBLISHm           = %x50.55.42.4C.49.53.48 ; PUBLISH in caps.
extension-method   = PUBLISHm / token
SIP-ETag           = "SIP-ETag" HCOLON entity-tag
SIP-If-Match       = "SIP-If-Match" HCOLON entity-tag
entity-tag         = token

13. IANA Considerations 🌸

so this document asks IANA to register one new method name, one new response code, and two new header field names. it's giving registry glow-up 💖

13.1. Methods 🧚

this document registers one new SIP method. it goes into the method and response-code sub-registry at http://www.iana.org/assignments/sip-parameters, and it looks like this:

Method Name:   PUBLISH
Reference:     [RFC3903]

13.2. Response Codes 💜

there's also one new response code. it gets added to the method and response-code sub-registry at http://www.iana.org/assignments/sip-parameters with these details:

Response Code Number:   412
Default Reason Phrase:  Conditional Request Failed

13.3. Header Field Names 🍓

two brand new SIP header field names get registered here. they go into the header sub-registry at http://www.iana.org/assignments/sip-parameters, and neither one has a compact form 🙈

Header Name:    SIP-ETag
Compact Form:   (none)
Header Name:    SIP-If-Match
Compact Form:   (none)

14. Security Considerations 🔐

okay bestie, this is the serious part, so put your listening ears on 👂 event state can be really sensitive, so security is a whole big deal here 😭

14.1. Access Control 🗝️

since event state can be sensitive info, the ESC needs to be able to pick and choose which publications it accepts, and only from sources that are authorized. the decision is based on the identity of the EPA 👑

The state agent SHOULD authenticate the EPA, and SHOULD apply its authorization policies (for example, ones built on access control lists) to all requests. the composition model doesn't assume that every input source for an ESC lives on the same network or in the same administrative domain, so it's giving "anything could be out there" energy 🌈

ESCs and EPAs MUST implement Digest for authenticating PUBLISH requests, as defined in RFC 3261 [4]. how you actually create and manage the access control policies inside the ESC is outside the scope of this document, so that's a different story 💅

14.2. Denial of Service Attacks 🚨

creating state at the ESC when a PUBLISH request shows up is something attackers can abuse to eat up resources on a victim's machine. it could even make it totally unusable 💀

to lower those odds, implementations of ESCs SHOULD require authentication of PUBLISH requests. implementations MUST support Digest authentication, as defined in RFC 3261 [4] ✨

also, the ESC SHOULD throttle incoming publications and the notifications that come from changes in event state. a good first step is picking sensible default minimum Expires header field values for the supported event packages, since that helps limit how often event state gets refreshed 🦋

extra throttling and debounce logic at the ESC is worth having too, because it cuts down even more on the notification traffic that a PUBLISH request kicks off 🛑

14.3. Replay Attacks 🔁

replaying a PUBLISH request can cause real damage 😱 an attacker can redo any event state publication they've seen happen in the past just by replaying that PUBLISH request. one of the nasty things a replayed message can do is spoof old event state information. adding a versioning mechanism, like a timestamp, to the state information can help soften that risk 🕰️

to prevent replay attacks, implementations MUST support Digest authentication with replay protection, as defined in RFC 3261 [4]. more ways to counter replay attacks are discussed in SIP [4] 🛡️

14.4. Man in the Middle Attacks 👀

even with authentication in place, man-in-the-middle attacks using PUBLISH can still happen. an attacker might install arbitrary event state information, change or remove existing event state information in publications, or even wipe out event state entirely at an ESC 😭

to prevent this, implementations SHOULD, at a minimum, provide integrity protection across the To, From, Event, SIP-If-Match, Route, and Expires header fields, plus the bodies of PUBLISH requests 🔒

if the ESC gets event state in a PUBLISH request that's integrity protected using a security association that isn't with the ESC (for example, integrity protection applied end-to-end, from publisher all the way to subscriber), then the state agent working with the ESC MUST NOT modify the event state before exposing it to the subscribers of that event state in NOTIFY requests. this keeps the end-to-end integrity of the event state intact, which is so important 🫶

for integrity protection, ESCs MUST implement TLS [8], and MUST support both mutual and one-way authentication. they also MUST support the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs MAY support S/MIME [9] for integrity protection, as defined in SIP [4] 🎀

14.5. Confidentiality 🤫

the state information in a PUBLISH message can potentially contain sensitive stuff. implementations MAY encrypt that information to keep it confidential 🌙

for confidentiality, ESCs MUST implement TLS [8], MUST support both mutual and one-way authentication, and MUST also support the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs MAY support S/MIME [9] for encryption of event state information, as defined in SIP [4] 💖

15. Examples 🎀

okay so this section walks through a PUBLISH example, and honestly it's the best way to see how presence actually flows 🫶 The watcher subscribes to the presentity's presence info from the PA (presence agent). The PUA (presence user agent) can also SUBSCRIBE to its own presence to see the composite state the PA exposes. That's an optional but likely step for the PUA, and we're skipping it here 💅

Quick heads up: when Content-Length shows up as "...", it just means whatever the computed length of the body ends up being. Bestie, that's it, that's the whole trick ✨

Here's the big picture of who talks to whom:

       PUA                     PA                      WATCHER
      (EPA)                   (ESC)
        |                       |                         |
        |                       | <---- M1: SUBSCRIBE --- |
        |                       |                         |
        |                       | ----- M2: 200 OK -----> |
        |                       |                         |
        |                       | ----- M3: NOTIFY -----> |
        |                       |                         |
        |                       | <---- M4: 200 OK ------ |
        |                       |                         |
        |                       |                         |
        | ---- M5: PUBLISH ---> |                         |
        |                       |                         |
        | <--- M6: 200 OK ----  |                         |
        |                       |                         |
        |                       | ----- M7: NOTIFY -----> |
        |                       |                         |
        |                       | <---- M8: 200 OK ------ |
        |                       |                         |
        | ---- M9: PUBLISH ---> |                         |
        |                       |                         |
        | <--- M10: 200 OK ---  |                         |
        |                       |                         |
        |                       |                         |
        | --- M11: PUBLISH ---> |                         |
        |                       |                         |
        | <-- M12: 200 OK ----  |                         |
        |                       |                         |
        |                       | ----- M13: NOTIFY ----> |
        |                       |                         |
        |                       | <---- M14: 200 OK ----- |
        |                       |                         |

Message flow, step by step (it's giving storytelling 📖):

M1 🦋 The watcher starts a brand new subscription to presentity@example.com's presence agent.

SUBSCRIBE sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 3600
Event: presence
Contact: sip:user@host.example.com
Content-Length: 0

M2 🌸 The presence agent for presentity@example.com handles the subscription request and creates a new subscription. It sends back a 200 (OK) response to confirm everything is set.

SIP/2.0 200 OK
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
 ;received=192.0.2.1
To: <sip:presentity@example.com>;tag=abcd1234
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Contact: sip:pa.example.com
Expires: 3600
Content-Length: 0

M3 🧚 To finish the setup, the presence agent sends the watcher a NOTIFY with the presentity's current presence state.

NOTIFY sip:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 1 NOTIFY
Max-Forwards: 70
Event: presence
Subscription-State: active; expires=3599
Contact: sip:pa.example.com
Content-Type: application/pidf+xml
Content-Length: ...

[PIDF document]

M4 💜 The watcher confirms it got the NOTIFY.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
 ;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 1 NOTIFY

M5 🔥 Now a presence user agent, acting for the presentity, sends a PUBLISH to the presence agent so it can update the presence info. The Expires header field shows the suggested lifetime for this event soft state.

PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: ...

[Published PIDF document]

M6 ✨ The presence agent gets the publication and accepts it. The published data gets folded into the presentity's presence info.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
 ;received=192.0.2.3
To: <sip:presentity@example.com>;tag=1a2b3c4d
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: dx200xyz
Expires: 1800

M7 💅 The presence agent notices a reportable change in the presentity's presence info, so it sends a fresh presence notification to the watcher.

NOTIFY sip:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Max-Forwards: 70
Event: presence
Subscription-State: active; expires=3400
Contact: sip:pa.example.com
Content-Type: application/pidf+xml
Content-Length: ...

[New PIDF document]

M8 🫶 The watcher confirms receipt of this NOTIFY.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
 ;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Content-Length: 0

M9 🍓 The PUA notices its previously published event state is about to expire, so it refreshes that state.

PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
SIP-If-Match: dx200xyz
Expires: 3600
Event: presence
Content-Length: 0

M10 🌈 The presence agent accepts the refresh. The timers for the event state identified by that entity-tag get updated. As always, the ESC hands back an entity-tag in the response to a successful PUBLISH. Nothing actually changed here, so the watchers get no NOTIFYs. Lowkey peak efficiency 🙈

SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
 ;received=192.0.2.3
To: <sip:presentity@example.com>;tag=2affde434
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: kwj449x
Expires: 1800

M11 👑 The PUA for the presentity spots a change in the user's presence state, so it sends a PUBLISH to modify the published info with the latest update.

PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=54321mm
Call-ID: 5566778@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
SIP-If-Match: kwj449x
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: ...

[Published PIDF Document]

M12 🦋 The presence agent accepts the modifying publication. The data gets folded into the presentity's presence info, replacing the earlier publication from the same PUA.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2
 ;received=192.0.2.3
To: <sip:presentity@example.com>;tag=effe22aa
From: <sip:presentity@example.com>;tag=54321mm
Call-ID: 5566778@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: qwi982ks
Expires: 3600

M13 🔥 The presence agent sees a reportable change in the presentity's presence document and sends a new presence notification to all active subscriptions.

NOTIFY sip:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Max-Forwards: 70
Event: presence
Subscription-State: active; expires=3400
Contact: sip:pa.example.com
Content-Type: application/pidf+xml
Content-Length: ...

[New PIDF document]

M14 🎀 The watcher confirms receipt of the NOTIFY, and the whole flow is complete ✨

SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3
 ;received=192.0.2.3
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Content-Length: 0

16. Contributors 🧚

The original contributors to this specification are:

  • Ben Campbell, Estacado Systems
  • Sean Olson, Microsoft
  • Jon Peterson, Neustar, Inc.
  • Jonathan Rosenberg, dynamicsoft
  • Brian Stucker, Nortel Networks, Inc.

17. Acknowledgements 💖

The authors want to thank the SIMPLE Working Group for their collective effort. They also name these people for their review and support of this work: Henning Schulzrinne, Paul Kyzivat, Hisham Khartabil, George Foti, Keith Drage, Samir Srivastava, Arun Kumar, Adam Roach, Pekka Pessi, Kai Wang, Cullen Jennings, Mikko Lonnfors, Eva-Maria Leppanen, Ernst Horvath, Thanos Diacakis, Oded Cnaan, Rohan Mahy, and Dean Willis. Iconic squad 🫶

18. References 📚

18.1. Normative References ✨

okay bestie, these are the must-read docs 📚🎀 you need before any of this makes sense 💅

  • [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 🦋
  • [2] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. 💖
  • [3] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. 🌸
  • [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 👑
  • [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔥
  • [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. ✨
  • [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 🧚
  • [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 🔒
  • [9] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 💜

19.2. Informative References

bestie these are the extra-credit reads 🤓💅 (the RFC literally labels this one 19.2, so that's how it stays 🙈)

  • [10] Campbell, B., "SIMPLE Presence Publication Requirements", Work in Progress, February 2003. 🌈
  • [11] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004. 🍓
  • [12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. 🫶
  • [13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 🦋

Author's Address 🎀

Aki Niemi (editor) is the one who put this together, so here's where to find them 💌

Aki Niemi (editor)
Nokia
P.O. Box 407
NOKIA GROUP, FIN  00045
Finland

Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com

Copyright (C) The Internet Society (2004). 🌸

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 💼

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Intellectual Property 🔥

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. 🧾

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔗

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 📬

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 💖 That's the end of the doc, bestie, you made it through all seven parts 🎉👑🥹

📦 where this page comes from