RFC 3857

RFC 3857: A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) 🎀

• Network Working Group 🌸
• Request for Comments: 3857
• Author: J. Rosenberg, dynamicsoft 💅
• Category: Standards Track ✨
• Date: August 2004 📅
• Obsoletes/Updates: the title block doesn't list anything this RFC obsoletes or updates 🦋

Status of this Memo 🧚

Okay so this doc is an Internet standards track protocol for the whole Internet community, and it's literally asking for discussion and suggestions 🫶. For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited ✨.

Copyright Notice 💜

Copyright (C) The Internet Society (2004).

Abstract 🌈

Okay, the big idea here is the watcher information template-package for the Session Initiation Protocol (SIP) event framework 🔥. "Watcher information" just means the set of users subscribed to a particular resource inside a particular event package 👀. That list is always changing, since people subscribe, unsubscribe, get approved, or get rejected 💅. A user can subscribe to this information and learn about every change to it, which is so iconic 😭. It's a template-package because it can be applied to any event package, including itself 🧚.

Table of Contents 🍓

   1.   Introduction ........................................    2
   2.   Terminology .........................................    3
   3.   Usage Scenarios .....................................    3
        3.1.  Presence Authorization ........................    4
        3.2.  Blacklist Alerts ..............................    5
   4.   Package Definition ..................................    5
        4.1.  Event Package Name ............................    5
        4.2.  Event Package Parameters ......................    5
        4.3.  SUBSCRIBE Bodies ..............................    6
        4.4.  Subscription Duration .........................    6
        4.5.  NOTIFY Bodies .................................    7
        4.6.  Notifier Processing of SUBSCRIBE Requests......    7
        4.7.  Notifier Generation of NOTIFY Requests ........    8
              4.7.1.  The Subscription State Machine.........    9
              4.7.2.  Applying the State Machine.............   11
        4.8.  Subscriber Processing of NOTIFY Requests ......   12
        4.9.  Handling of Forked Requests ...................   12
        4.10. Rate of Notifications .........................   13
        4.11. State Agents ..................................   13
   5.   Example Usage .......................................   14
   6.   Security Considerations .............................   17
        6.1.  Denial of Service Attacks .....................   17
        6.2.  Divulging Sensitive Information ...............   17
   7.   IANA Considerations .................................   18
   8.   Acknowledgements ....................................   18
   9.   Normative References ................................   18
   10.  Informative References ..............................   19
   11.  Author's Address ....................................   19
   12.  Full Copyright Statement ............................   20

1. Introduction 🦋

Okay so the SIP event framework is described in RFC 3265 [1] 📖. It gives you a generic way to subscribe to events related to SIP systems and get notified about them 🔔. The framework defines the methods SUBSCRIBE and NOTIFY, and it introduces the idea of a package 📦. A package is a concrete use of the event framework for one class of events, like user presence [5] 💖.

This doc defines a "template-package" inside the SIP event framework 🎀. A template-package has all the properties of a regular SIP event package, but it's always tied to some other event package. It can also be applied to any event package, including itself 🔁.

The template-package in this doc is for watcher information, and it's written as the token "winfo" ✨. For any event package (presence, say), there's a set of subscriptions, maybe even an empty one, made by users who want to know the state of a resource in that package 👀. That set changes all the time, because new subscriptions come in, old ones expire, and the resource owners approve or reject them 💅. The set of users subscribed to a particular resource for a specific event package, plus the state of their subscriptions, is called watcher information 🧚. Since that state keeps changing, it totally makes sense to subscribe to it and find out about every update 😭. The watcher information template-package exists for exactly that: tracking the state of subscriptions to a resource in another package 💜.

To write the name of this template-package, you stick ".winfo" onto the name of whatever package you're tracking 🍓. For example, the people subscribed to presence are tracked by the "presence.winfo" package 🌸.

2. Terminology 📝

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP14, RFC 2119 [2] 🔥. They show the requirement levels for compliant implementations 👑.

This doc is basically all about recursion, which means subscriptions to subscriptions 🌀. The word "subscription" can get confusing here, so the doc uses a few special terms 🫠. "watcherinfo subscription" means a subscription to watcher information, and "watcherinfo subscriber" means a user who has subscribed to watcher information 💅. "watcherinfo notification" means a NOTIFY request sent as part of a watcherinfo subscription 🔔. When you see "subscription", "subscriber", or "notification" on their own, they're talking about the "inner" ones, the ones being monitored through the watcherinfo subscriptions 👀. The doc also uses "watcher" for a subscriber to that "inner" resource, and watcher info gets reported through the watcherinfo subscriptions 🧚.

3. Usage Scenarios 🌈

There are lots of useful things you can do with the watcher information template-package ✨.

3.1. Presence Authorization 🔐

This template-package is mainly motivated by presence authorization 💖. When user A subscribes to user B's presence, that subscription needs to be authorized 🙈. Usually that happens through direct user intervention, so B's software has to find out that a presence subscription was requested 👀. Watcher information makes that possible 🫶. B's client software would SUBSCRIBE to the watcher information for B's presence:

SUBSCRIBE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
From: sip:B@example.com;tag=123s8a
To: sip:B@example.com
Call-ID: 9987@pc34.example.com
Max-Forwards: 70
CSeq: 9887 SUBSCRIBE
Contact: sip:B@pc34.example.com
Event: presence.winfo

The server's policy lets B subscribe to its own watcher information 💅. So when A subscribes to B's presence, B gets a notification about the change in watcher information state 🔔:

NOTIFY sip:B@pc34.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna66g
From: sip:B@example.com;tag=xyz887
To: sip:B@example.com;tag=123s8a
Call-ID: 9987@pc34.example.com
Max-Forwards: 70
CSeq: 1288 NOTIFY
Contact: sip:B@server.example.com
Event: presence.winfo
Content-Type: application/watcherinfo+xml
Content-Length: ...

<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
             version="0" state="full">
  <watcher-list resource="sip:B@example.com" package="presence">
    <watcher id="7768a77s" event="subscribe"
             status="pending">sip:A@example.com</watcher>
  </watcher-list>
</watcherinfo>

That tells B that A subscribed and the subscription is pending, which means it's waiting for authorization ⏳. B's software can alert B that this subscription is waiting for authorization 🔔. Then B can set policy for that subscription 👑.

3.2. Blacklist Alerts 🚨

Apps can subscribe to watcher information to add extra value-added features 💜. One example is "blacklist alerts" 🙈. Here, an application server keeps a list of known "bad guys" 😈. A user, Joe, signs up for the service, probably by going to a web page and entering his presence URI 🍓. The application server subscribes to the watcher information for Joe's presence 🔎. When someone tries to SUBSCRIBE to Joe's presence, the application finds out about it through its watcher info subscription 👀. It checks the watcher's URI against the database of known bad guys 🕵️. If there's a match, it emails Joe to let him know 📧.

For this to work, Joe needs to make sure the application is allowed to subscribe to his presence.winfo 🫶.

4. Package Definition 🎀

This section fills in the details needed to specify an event package, as defined in Section 4.4 of RFC 3265 [1] 📝.

4.1. Event Package Name 🏷️

RFC 3265 [1] requires package definitions to specify the name of their package or template-package 📛.

The name of this template-package is "winfo" ✨. It can be applied to any other package 🔁. Watcher information for any package foo is written as "foo.winfo" 🌸. Recursive template-packaging is explicitly allowed (and useful), so "foo.winfo.winfo" is a valid package name 🧚.

4.2. Event Package Parameters ⚙️

RFC 3265 [1] requires package and template-package definitions to specify any package-specific parameters of the Event header field 📋.

No package-specific Event header field parameters are defined for this event template-package 🙅.

4.3. SUBSCRIBE Bodies 📦

RFC 3265 [1] requires package or template-package definitions to define how bodies in SUBSCRIBE requests are used, if they're used at all 📖.

A SUBSCRIBE request for watcher information MAY contain a body 🎀. That body would be there to filter the watcherinfo subscription 🧹. What the body actually looks like is outside the scope of this spec 🙃. For presence, for example, the body might say that notifications should carry full state every time something changes, and that the time the subscription was first made should not show up in the watcherinfo notifications 💅.

A SUBSCRIBE request for a watcher information package MAY be sent without a body 🫶. If it has no body, that means you're asking for the default watcherinfo subscription filtering policy 💖. The default policy is:

• Watcherinfo notifications get generated every time there's any change in the state of the watcher information 🔔.
• Watcherinfo notifications triggered from a SUBSCRIBE contain full state, meaning the list of all watchers that the watcherinfo subscriber is permitted to know about 📜. Watcherinfo notifications triggered from a change in watcher state only contain information about the watcher whose state changed 👀.

Of course, the server can apply whatever policy it likes to the subscription 👑💅

4.4. Subscription Duration ⏳

RFC 3265 [1] requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified. 🎀

Okay so watcher information is literally always changing 😭 Users keep subscribing to a resource for some package, and their subscriptions keep timing out. That means the state of watcher information can shift super dynamically, depending on how many subscribers a resource has in a given package. The rate at which subscriptions time out depends on how long a user keeps their subscription going. 🌸

Typically, watcherinfo subscriptions get timed to span the lifetime of the subscriptions being watched, so they can range from minutes to days. ⭐

Because of all this, it's hard to pick a broadly useful default for how long a watcherinfo subscription should last 🙈 So we arbitrarily choose one hour. ✨ However, clients SHOULD use an Expires header field to specify their preferred duration. 💖

4.5. NOTIFY Bodies 🦋

RFC 3265 [1] requires package definitions to describe the allowed set of body types in NOTIFY requests, and to specify the default value to be used when there is no Accept header field in the SUBSCRIBE request. 💅

The body of the watcherinfo notification contains a watcher information document. This document describes some or all of the watchers for a resource within a given package, plus the state of their subscriptions. It's giving "full picture" energy 👑 All watcherinfo subscribers and notifiers MUST support the application/watcherinfo+xml format described in [3], and MUST list its MIME type, application/watcherinfo+xml, in any Accept header field present in the SUBSCRIBE request. 🫶

Other watcher information formats might be defined in the future. In that case, the watcherinfo subscriptions MAY indicate support for other formats. However, they MUST always support and list application/watcherinfo+xml as an allowed format. 🌈

Of course, the watcherinfo notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request. If no Accept header field was present, the notifications MUST use the application/watcherinfo+xml format described in [3]. 🍓

4.6. Notifier Processing of SUBSCRIBE Requests 🔐

RFC 3265 [1] specifies that packages should define any package-specific processing of SUBSCRIBE requests at a notifier, specifically with regards to authentication and authorization. 🧚

The watcher information for a particular package contains sensitive information. Main character energy: this is serious business 😤 Therefore, all watcherinfo subscriptions SHOULD be authenticated and then authorized before approval. Authentication MAY be performed using any of the techniques available through SIP, including digest, S/MIME, TLS or other transport specific mechanisms [4]. Authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made. 💜

It is RECOMMENDED that user A be allowed to subscribe to their own watcher information for any package. This is true recursively, so it is RECOMMENDED that a user be able to subscribe to the watcher information for their watcher information for any package. 🪞

It is RECOMMENDED that watcherinfo subscriptions for some package foo for user A be allowed from some other user B, if B is an authorized subscriber to A within the package foo. However, it is RECOMMENDED that the watcherinfo notifications sent to B only contain the state of B's own subscription. In other words, it is RECOMMENDED that a user be allowed to monitor the state of their own subscription. 👀

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, for any foo. It is also RECOMMENDED that by default, a server does not authorize any subscriptions to foo.winfo.winfo.winfo or any other deeper recursions. 🙃

4.7. Notifier Generation of NOTIFY Requests 🔔

The SIP Event framework requests that packages specify the conditions under which notifications are sent for that package, and how such notifications are constructed. 📬

Each watcherinfo subscription is associated with a set of "inner" subscriptions being watched. This set is defined by the URI in the Request URI of the watcherinfo SUBSCRIBE request, along with the parent event package of the watcherinfo subscription. The parent event package is obtained by removing the trailing .winfo from the value of the Event header field from the watcherinfo SUBSCRIBE request. If the Event header field in the watcherinfo subscription has a value of presence.winfo, the parent event package is presence. If the Event header field has a value of presence.winfo.winfo, the parent event package is presence.winfo. 🧩

Normally, the URI in the Request URI of the watcherinfo SUBSCRIBE identifies an address-of-record within the domain. In that case, the set of subscriptions to be watched are all of the subscriptions for the parent event package that have been made to the resource in the Request URI of the watcherinfo SUBSCRIBE. However, the Request URI can contain a URI that identifies any set of subscriptions, including the subscriptions to a larger collection of resources. For example, sip:all-resources@example.com might be defined within example.com to refer to all resources. In that case, a watcherinfo subscription for presence.winfo to sip:all-resources@example.com is requesting notifications any time the state of any presence subscription for any resource within example.com changes. 🌍 A watcherinfo notifier MAY generate a notification any time the state of any of the watched subscriptions changes. 🔥

Because a watcherinfo subscription is made to a collection of subscriptions, the watcher information package needs a model of subscription state. This is accomplished by specifying a subscription Fine State Machine (FSM), described below, which governs the subscription state of a user in any package. Watcherinfo notifications MAY be generated on transitions in this state machine. It's important to note that this FSM is just a model of the subscription state machinery maintained by a server. An implementation would map its own state machines to this one in an implementation-specific manner. 🧠✨

4.7.1. The Subscription State Machine 🎀

okay so the subscription state machine is shown in Figure 1 ✨ it's built almost entirely off the descriptions in RFC 3265 [1], but it adds this extra thing called a waiting state, which is so iconic 💅

when a SUBSCRIBE request shows up, the subscription FSM gets created in the init state 🧚 this state is transient, so it doesn't stick around. the next move depends on whether policy exists for the subscription. if there's existing policy saying the subscription is forbidden, it goes straight to the terminated state, where the FSM can be destroyed 💀 if there's existing policy saying it's authorized, the FSM moves into the active state, which just means the subscriber will receive notifications 🔥

if there's no authorization policy when the subscription arrives, it moves into the pending state 🦋 in pending, the server is waiting on an authorization decision. no notifications get generated when presence state changes (an initial NOTIFY will have been delivered as per RFC 3265 [1]), but the subscription FSM is still maintained. if the decision comes back positive, the subscription is approved and moves into the active state ✨ if it's negative, the subscription is rejected and the FSM goes into the terminated state. the decision can take a very long time, honestly. it's possible that no decision arrives until after the subscription itself expires 😭 if a pending subscription times out, it moves into the waiting state. at any time, the server can decide to end a pending or waiting subscription, because it's concerned about spending memory and CPU on unauthorized subscription state 🙈 when that happens, the server generates a giveup event, which moves the subscription to terminated.

the waiting state is similar to pending in that no notifications are generated 💜 but if the subscription is approved or denied, the FSM enters the terminated state and gets destroyed. also, if another subscription comes in for the same resource, from the same watcher, for the same event package, event package parameters, and filter in the body of the SUBSCRIBE request (if one was present initially), the FSM enters the terminated state with a giveup event and gets destroyed 👑 this happens because the new subscription with identical parameters will enter pending anyway, so the waiting state for the old one is redundant. the whole point of the waiting state is so a user can fetch watcherinfo state at any time and find out about subscriptions that came in earlier (and might come in again) that need an authorization decision 🌈

let's look at an example. A subscribes to B. B hasn't defined any policy about this subscription, so it moves into pending. B is not "online", so B's software agent can't be contacted to approve the subscription. the subscription expires. let's say it got destroyed. B logs in and fetches its watcherinfo state. there's no record of the subscription from A, so no policy decision gets made about subscriptions from A. B logs off. A refreshes its subscription. once again, it's pending, since no policy is defined for it. this could keep going forever 😩 the waiting state makes sure B can find out about this subscription attempt 💖

subscribe, policy= +----------+ reject | |<------------------------+ +------------>|terminated|<---------+ |

+-------+ +-------+ +-------+ |

+-------+ +-------+ +-------+ |

+-----------------------------------+ | policy = accept | +-------+ |

+----------->| | timeout | | +-------+

Figure 1: Subscription State Machine

the waiting state is also needed so fetch attempts can be authorized 🧁 those are subscriptions that expire immediately.

of course, policy might never get specified for the subscription 🥺 so the server can generate a giveup event to move the waiting subscription into the terminated state. how long to wait before issuing a giveup event is system dependent.

the giveup event is generated in either the waiting or pending states, to destroy resources tied to unauthorized subscriptions ✨ it fires when a giveup timer goes off. this timer gets set to a timeout value when the subscription enters either the pending or waiting states. servers need to be careful picking this value! it has to be large so the user experience is actually useful. a user should be able to log in days later and see that someone tried to subscribe to them 🫶 but allocating state for unauthorized subscriptions can be used as a source of DoS attacks, so it's RECOMMENDED that servers that retain state for unauthorized subscriptions add policies which prohibit a particular subscriber from having more than some number of pending or waiting subscriptions 🛡️

at any time, the server can deactivate a subscription 🦋 deactivation means the subscription is discarded without any change in authorization policy. this might be done to trigger refreshes for a graceful shutdown or a subscription migration operation. a related event is probation, where a subscription is terminated and the subscriber is asked to wait some amount of time before trying again. the details of these events are described in Section 3.2.4 of RFC 3265 [1] 📚

a subscription can be terminated at any time because the resource tied to it no longer exists 💅 that corresponds to the noresource event.

4.7.2. Applying the State Machine 🌸

the server MAY generate a notification to watcherinfo subscribers on a transition of the state machine 🍓 whether it does is policy dependent. however, a few guidelines are defined.

let's say there's some event package foo. A subscribes to B for events within that package. A also subscribes to foo.winfo for B. in this scenario (where the subscriber to foo.winfo is also a subscriber to foo for the same resource), it is RECOMMENDED that A receive watcherinfo notifications only about changes in its own subscription 🎀 normally, A gets notifications about changes in its subscription to foo through the Subscription-State header field. this will frequently make a separate subscription to foo.winfo unnecessary ✨ but if A does perform such a subscription, the foo.winfo notifications SHOULD NOT report any state changes that wouldn't be reported (because of authorization policy) in the Subscription-State header field in notifications on foo.

as a general rule, when a watcherinfo subscriber is authorized to receive watcherinfo notifications about more than one watcher, it is RECOMMENDED that the notifications contain information about the watchers that changed state (and thus triggered a notification) 💜 they shouldn't deliver the current state of every watcher in every watcherinfo notification. however, watcherinfo notifications triggered by a fetch operation (a SUBSCRIBE with Expires of 0) SHOULD result in the full state of all watchers (of course, only the ones that have been authorized to be divulged to the watcherinfo subscriber) being present in the NOTIFY 👑

states in the subscription state machine are often transient 🫧 for example, if an authorized watcher performs a fetch operation, the state machine gets created, transitions from init to active, then from active to terminated, and finally gets destroyed. in cases like that, watcherinfo notifications SHOULD NOT be sent for any transient states. in the example above, the server wouldn't send any notifications, since all of the states are transient 🥹

4.8. Subscriber Processing of NOTIFY Requests 🧚‍♀️

RFC 3265 [1] expects packages to specify, in any package specific ways, how a subscriber processes NOTIFY requests. in particular, it expects them to say how the subscriber uses NOTIFY requests to build a coherent view of the state of the subscribed resource 🔍 typically, a watcherinfo NOTIFY will only contain information about the watchers whose state has changed. so to build a coherent view of the total state of all watchers, a watcherinfo subscriber needs to combine the NOTIFYs it receives over time. this details of this process depend on the document format. see [3] for details on the application/watcherinfo+xml format 💖

4.9. Handling of Forked Requests 🍴✨

Okay so the SIP Events framework literally mandates that every package says whether forked SUBSCRIBE requests can install multiple subscriptions 💅

Say a user wants watcher info for some resource in package foo. The SUBSCRIBE to the watcher info has to reach a bunch of servers that, all together, hold complete info about every watcher on that resource for package foo. If there are a bunch of servers handling subscriptions for that resource for package foo (usually for load balancing), it's very likely that no single server has the full set of watcher info 🙈. There are a few ways to fix this. This spec doesn't force one and doesn't rule out others. It just makes sure a wide range of solutions can be built 🦋.

One option is forking 🍴. The system can be set up so a SUBSCRIBE for watcher info lands on a special proxy that knows what watcher info needs. That proxy forks the SUBSCRIBE to every server that could possibly keep subscriptions for that resource and package. Each of those servers accepts the watcherinfo subscription, whether or not it has any current subscribers for that resource 💖. They all need to accept, because any of them might eventually get a subscription for that resource. The watcherinfo subscriber gets some number of watcherinfo NOTIFY requests, and each one sets up its own separate dialog 💜. By combining the info across every dialog, the watcherinfo subscriber can work out the full watcherinfo state ✨. A lot of the time a particular dialog might never send any watcherinfo notifications. That happens when the servers never get any subscriptions for the resource.

For this to work interoperably, all watcherinfo subscribers MUST be prepared to install multiple subscriptions when a single SUBSCRIBE gets back a bunch of NOTIFY messages 🫶

Another way to handle the server multiplicity problem is state agents 🧚. Check out Section 4.11 for the deets.

4.10. Rate of Notifications 🐢

RFC 3265 [1] mandates that packages define a maximum rate of notifications for their package 📏

Notifications can't get out of hand, because congestion control matters a lot 😭 So it is RECOMMENDED that the server not generate watcherinfo notifications for a single watcherinfo subscriber at a rate faster than once every 5 seconds ⏰

4.11. State Agents 🧚‍♀️

RFC 3265 [1] asks packages to think about the role of state agents in their design 🤔

State agents are a big deal for this package 👑 As Section 4.9 covered, there might be a bunch of servers sharing the load of subscriptions for a particular package. A watcherinfo subscription might need subscription state spread across all of those servers, so you can use a farm of state agents to handle that 🌈. Each state agent would know the entire watcherinfo state for some set of resources. How the state agents figure out the full watcherinfo state is outside the scope of this spec 🙃. When a watcherinfo subscription comes in, it gets routed to a state agent that has the full watcherinfo state for the requested resource. That server accepts the watcherinfo subscription (assuming it was authorized, obviously) and generates watcherinfo notifications as the watcherinfo state changes 💅 The watcherinfo subscriber only has a single dialog in this case 🎀

5. Example Usage 🌸

Okay so this section walks through an example application and call flows using the watcherinfo package 📞

In this example, a user Joe, sip:joe@example.com, provides presence through the example.com presence server. Joe subscribes to his own watcher info so he can learn who's subscribing to his presence and then approve or reject them 👀 Joe sends this SUBSCRIBE request:

SUBSCRIBE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
From: sip:joe@example.com;tag=123aa9
To: sip:joe@example.com
Call-ID: 9987@pc34.example.com
CSeq: 9887 SUBSCRIBE
Contact: sip:joe@pc34.example.com
Event: presence.winfo
Max-Forwards: 70

The server responds with a 401 to authenticate, and Joe resubmits the SUBSCRIBE with credentials (message not shown) 🔐 The server then authorizes the subscription, since it allows Joe to subscribe to his own watcher info for presence. It responds with a 200 OK:

SIP/2.0 200 OK
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds8
  ;received=192.0.2.8
From: sip:joe@example.com;tag=123aa9
To: sip:joe@example.com;tag=xyzygg
Call-ID: 9987@pc34.example.com
CSeq: 9988 SUBSCRIBE
Contact: sip:server19.example.com
Expires: 3600
Event: presence.winfo

The server then sends a NOTIFY with the current state of presence.winfo for joe@example.com:

NOTIFY sip:joe@pc34.example.com SIP/2.0
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1288 NOTIFY
Contact: sip:server19.example.com
Event: presence.winfo
Subscription-State: active
Max-Forwards: 70
Content-Type: application/watcherinfo+xml
Content-Length: ...

<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
             version="0" state="full">
  <watcher-list resource="sip:joe@example.com" package="presence">
    <watcher id="77ajsyy76" event="subscribe"
             status="pending">sip:A@example.com</watcher>
  </watcher-list>
</watcherinfo>

Joe then responds with a 200 OK to the NOTIFY:

SIP/2.0 200 OK
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
  ;received=192.0.2.7
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1288 NOTIFY

The NOTIFY tells Joe that user A currently has a pending subscription 👤 Joe then authorizes A's subscription through some means 🎀 This changes the status of the subscription (it moves from pending to active) and triggers the delivery of another notification:

NOTIFY sip:joe@pc34.example.com SIP/2.0
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1289 NOTIFY
Contact: sip:server19.example.com
Event: presence.winfo
Subscription-State: active
Max-Forwards: 70
Content-Type: application/watcherinfo+xml
Content-Length: ...

<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
             version="1" state="partial">
  <watcher-list resource="sip:joe@example.com" package="presence">
    <watcher id="77ajsyy76" event="approved"
             status="active">sip:A@example.com</watcher>
  </watcher-list>
</watcherinfo>

B then responds with a 200 OK to the NOTIFY:

SIP/2.0 200 OK
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
  ;received=192.0.2.7
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1289 NOTIFY

6. Security Considerations 🔒

6.1. Denial of Service Attacks 💀

Watcher info generates notifications about changes in the state of watchers for a particular resource 📣 A single resource can have lots of watchers, which means a potentially huge volume of notifications. That makes watcherinfo subscription a potential tool for denial of service attacks 😱 You can prevent these with a combo of sensible authorization policies and good operating principles 🛡️

First, when a resource has a lot of watchers, watcherinfo subscriptions to that resource should only be allowed from explicitly authorized entities, whose identity has been properly authenticated. That stops a watcherinfo NOTIFY stream from being generated by subscriptions made by an attacker 🚫

Even when watcherinfo subscriptions are properly authenticated, there are still potential attacks 🥺 For example, consider a valid user, T, who is going to be the target of an attack. T has subscribed to their own watcher information. The attacker generates a large number of subscriptions (not watcherinfo subscriptions). If the server creates subscription state for unauthenticated subscriptions and reports those changes in watcherinfo notifications, user T would receive a flood of watcherinfo notifications. In fact, if the server generates a watcherinfo notification when the subscription is created and another when it is terminated, there will be an amplification by a factor of two. The amplification would actually be substantial if the server generates full state in each watcherinfo notification 😭 Indeed, the amount of data sent to T would be the square of the data generated by the attacker! Each of the N subscriptions generated by the attacker would result in a watcherinfo NOTIFY being sent to T, each of which would report on up to N watchers. To avoid this, servers should never generate subscription state for unauthenticated SUBSCRIBE requests, and should never generate watcherinfo notifications for them either 🙅‍♀️

6.2. Divulging Sensitive Information 🕵️

Watcher info indicates what users are interested in a particular resource 👀 Depending on the package and the resource, this can be super sensitive. For example, in the case of presence, the watcher info for some user represents the friends, family, and business relations of that person. This info can be used for a variety of malicious purposes 💀

One way this information can be revealed is eavesdropping. An attacker can observe watcherinfo notifications and learn this information. To prevent that, watchers MAY use the sips URI scheme when subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST support TLS and sips as if they were a proxy (see Section 26.3.1 of RFC 3261) 🔐

SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests 💌

Another way this information can be revealed is through spoofed subscriptions 👻 These attacks can be prevented by authenticating and authorizing all watcherinfo subscriptions. In order for the notifier to authenticate the subscriber, it MAY use HTTP Digest (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP Digest. This is a redundant requirement, however, since all SIP user agents are mandated to support it by RFC 3261 💅

7. IANA Considerations 📋

This specification registers an event template package as specified in Section 6.2 of RFC 3265 [1] 🦋

Package Name: winfo

Template Package: yes

Published Specification: RFC 3857

Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.

8. Acknowledgements 🫶

The authors would like to thank Adam Roach, Allison Mankin and Brian Stucker for their detailed comments 💖

9. Normative References ✨

okay bestie, these are the docs this RFC needs you to have read first 📚💖 (no cap, you're not getting the full picture without them)

• [1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
• [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [3] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
• [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.

10. Informative References 🧚

and this one's more of a "bonus read" vibe, not required reading 🌸

• [5] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, July 2004.

11. Author's Address 🎀

here's where you can find the author, Jonathan Rosenberg, from dynamicsoft 💜

Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054

EMail: jdrosen@dynamicsoft.com

12. Full Copyright Statement 💅

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. It also doesn't represent that it has made any independent effort to identify any such rights. Info on the procedures for rights in RFC 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 online 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 send that info to the IETF at ietf-ipr@ietf.org. 💌

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

---

That's a wrap on RFC 3857, bestie! You made it through the whole thing 🌈👑