RFC 4660

Functional Description of Event Notification Filtering

📅 published September 2006, from ietf

Functional Description of Event Notification Filtering ✨

📜 RFC: 4660, in the Network Working Group
👯 Authors: H. Khartabil (Telio), E. Leppanen, M. Lonnfors and J. Costa-Requena (all Nokia)
🏷️ Category: Standards Track
📅 Date: September 2006
🔁 Obsoletes / Updates: the title block doesn't list any, so this one doesn't obsolete or update anything else 🫶

Status of This Memo

Okay so this doc is an Internet standards track protocol spec for the whole Internet community, and it's literally asking for your discussion and suggestions to make it better 💌. For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited 🌈.

Copyright Notice

Abstract

Bestie, so the SIP event notification framework is all about using the Session Initiation Protocol (SIP) for subscriptions and for notifications when the state of a resource changes 🦋. The catch is that it doesn't say how to filter event notification information. That's the gap this doc fills ✨.

It describes what a subscriber does to put filtering rules on a subscription to event notification information. It also covers how the subscriber handles responses to subscriptions that carry filtering rules, and how it handles notifications that have those rules applied. On top of that, it explains how the notifier behaves when it gets these filtering rules and how a notification gets built 🔥.

   1. Introduction ....................................................3
   2. Conventions .....................................................3
   3. Client Operation ................................................4
      3.1. Transport Mechanism ........................................4
      3.2. SUBSCRIBE Bodies ...........................................4
      3.3. Subscriber Generating of SUBSCRIBE Requests ................4
           3.3.1. Defining the Filtering Rules ........................4
           3.3.2. Request-URI vs. Filter URI ..........................5
           3.3.3. Changing Filters within a Dialog ....................5
           3.3.4. Subscriber Interpreting of SIP Responses ............6
      3.4. Subscriber Processing of NOTIFY Requests ...................6
   4. Resource List Server Behaviour ..................................7
      4.1. Request-URI vs. Filter URI .................................7
      4.2. Changing Filters within a Dialog ...........................9
   5. Server Operation ................................................9
      5.1. NOTIFY Bodies ..............................................9
      5.2. Notifier Processing of SUBSCRIBE Requests ..................9
           5.2.1. Request-URI vs. Filter URI .........................10
           5.2.2. Changing Filters within a Dialog ...................11
      5.3. Notifier Generating of NOTIFY Requests ....................11
           5.3.1. Generation of NOTIFY Contents ......................12
           5.3.2. Handling of Notification Triggering Rules ..........13
      5.4. Handling Abnormal Cases ...................................13
   6. XML Document Validation ........................................14
   7. Examples .......................................................14
      7.1. Presence Specific Examples ................................14
           7.1.1. Subscriber Requests Messaging-Related Information ..15
           7.1.2. Subscriber Fetches Information about "Open"
                  Communication Means ................................16
           7.1.3. Subscriber Requests Notifications When
                  Presentity's Status Changes ........................18
      7.2. Watcher Information Specific Examples .....................21
           7.2.1. Watcher Subscriber Makes Subscription to
                  Get All the Information about Active Watchers ......22
           7.2.2. Watcher Subscriber Requests Information of
                  Watchers with Specific Subscription Duration
                  Conditions .........................................23
           7.2.3. Watcher Subscriber Requests Specific
                  Watcher Info on Specific Triggers ..................24
   8. Security Considerations ........................................27
   9. IANA Considerations ............................................28
   10. Acknowledgements ..............................................28
   11. References ....................................................28
      11.1. Normative References .....................................28
      11.2. Informative References ...................................28

1. Introduction 🌸

SIP event notification is described in [3]. It's the general framework for sending subscriptions and receiving notifications in SIP-based systems 💅. It brings in the idea of event packages, which are concrete applications of that general framework to one specific kind of event usage.

Filtering is the mechanism for controlling what goes into event notifications. The subscriber can also say when a notification should be sent to it, which is giving total main character energy 👑. Filtering is expected to be especially valuable for users of mobile wireless access devices. These devices usually have high latency, low bandwidth, low data processing power, a small display and limited battery 😭. They can really benefit from being able to filter the amount of information generated at the source of the event notification. Heads up though: implementers need to be aware of the computational burden this puts on the source of the event notification. Section 8 covers this in more detail 🙈.

It's stated in [3] that the notifier may send a NOTIFY at any time, but it's typically sent when the state of the resource changes ✨. That same reference says notifications contain the complete and current state of the resource, as far as a certain subscriber is authorized to see it. The format of that resource state information is package specific. In this memo, we assume the NOTIFY for any package contains an XML document 💖.

This document, together with [5], presents a filtering mechanism. A subscriber uses it to describe its preferences for when notifications get sent to it and what they should contain 🦋. It also describes how the notifier works when it generates notifications, taking into account the filters and the default functionality of the package or service 🧚.

The XML format for defining the filter is described in [5] 🎀.

2. Conventions 💅

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 RFC 2119 [1]. They indicate requirement levels for compliant implementations 🫶.

"Content" refers to the XML document that appears in a notification and reflects the state of a resource ✨.

3. Client Operation 🎀

3.1. Transport Mechanism 🦋

Filters get transported to the server by putting the XML document, as defined in [5], into the body of the SUBSCRIBE request 📦. The XML document can also be uploaded to the server by means that are outside the scope of this document.

SIP entities that are compliant with this specification MUST support the content type application/simple-filter+xml 💜.

This section covers the extra stuff the subscriber has to handle when filters are in the bodies of SUBSCRIBE requests 🍓. Otherwise, normal service operations are followed, for example the ones defined in [8], [10], and [4] 💅.

As defined in [3], the SUBSCRIBE message MAY contain a body. That body would carry the filtering information 🧚. Honouring those filters is at the discretion of the notifier, and it might depend on local policies 🤷‍♀️.

No content in the body of a SUBSCRIBE tells the notifier that no filter is being requested. So the notifier is instructed to send all the NOTIFY requests using its own or its service-specific policy 🌙. Note that, for example in the list case [4], the filter might have been uploaded to the server beforehand, by means outside the scope of this document 📤.

If the body of the SUBSCRIBE includes the filter, the body MUST be of the MIME-Type application/simple-filter+xml 🔥.

3.3.1. Defining the Filtering Rules ✨

Multiple filters MAY be included in one SUBSCRIBE 💖. You do this by putting multiple <filter> elements in the filter [5]. Each <filter> element may include a uri attribute 🦋.

A SUBSCRIBE request destined to a list URI [4] MAY include multiple filters that are specific to individual resources 👑. You do this by including multiple <filter> elements, each with different URIs of resources. Resource-specific filters get processed first, before any list-specific filter, if there is one. The list-specific filter may or may not include a URI 🌈.

Regardless of whether the SUBSCRIBE is destined to a list URI, there can only be one filter that applies to a single resource or domain within a single SUBSCRIBE 🙈. Put simply, each filter within a subscription MUST uniquely identify one resource or one domain 💅.

You can enable and disable a filter with the enabled attribute in the <filter> element, as described in [5] 🎀.

3.3.2. Request-URI vs. Filter URI 🌸

The URI in the filter defines the target resource 🎯. In the Presence service case, for example, the filter gets applied to the presentity's presence information 🫧. The subscriber MAY choose to leave the URI in the filter undefined. If the URI isn't defined within the filter, the filter applies to the resource identified in the Request-URI 💜. The subscriber MAY also define a filter URI. If the Request-URI is a list URI [4], then the filter URI MUST be the list URI, a sub-list URI, or a resource whose URI is one of the URIs that result from a lookup on the Request-URI by a Resource List Server (RLS) 🦋. If it isn't, the filter may be ignored or may be rejected 😬. URI matching is done according to the matching rules defined for a particular scheme. SIP URI matching rules are defined in RFC 3261 [2] 📚.

A filter can also be addressed to a domain by using the domain attribute instead of the uri attribute 🌍. In that case, the filter applies to resources in that domain. This is handy when a subscription is for a resource that is an event list with lots of resources from different domains 🧚. If an individual resource-specific filter is present along with the domain filter, the resource-specific filter overrides any domain-specific filter, if there is one 👑✨.

3.3.3. Changing Filters within a Dialog ✨

okay so the subscriber MAY reset or change the filter by sending a fresh SUBSCRIBE inside the existing dialog 💅. A SUBSCRIBE in that dialog that doesn't have a filter in it is assumed to keep the filters that are already there. So filters are sticky within a dialog and only ever go away on purpose 🎀.

If a subscriber needs a filter gone, they can use the remove="true" attribute, as defined in [5] 🗑️.

If the URI in a filter points to a list, the subscriber can override that for one individual resource in the list. They send a new SUBSCRIBE inside the existing dialog with a filter just for that resource, using a new filter ID 🦋. The new filter doesn't need to include the original one, because filters only get removed in the way we just talked about.

To replace a filter, re-send it with the same filter ID and swap out its contents 🫶. Changing the filter ID while keeping the resource URI is an error, because the server would think there are two filters for the same resource 😭.

Again, a filter can be disabled and re-enabled with the enabled attribute in the <filter> element, as described in [5] 💜.

3.3.4. Subscriber Interpreting of SIP Responses 🔥

The SUBSCRIBE request gets confirmed with a final response. A 200-class response means the subscription was accepted and a NOTIFY will be sent immediately. A "200" response means the subscription is accepted and the filter is accepted too 👑. A "202" response just means the subscription was understood, the content type was accepted, and authorization may or may not have been granted. A "202" response also means the filter hasn't been accepted yet. The acceptance of the filter MAY arrive in a subsequent NOTIFY 🌸.

A non-200 class final response means no subscription or dialog was created, and no NOTIFY message will be sent afterwards. All non-200 class final responses have the same meanings and handling as described in [2] and [3] 🙈.

Specifically, a "415" response means the notifier doesn't understand the MIME type 'application/simple-filter+xml'. A "488" response means the content type (filter) is understood, but some parts of it weren't understood or weren't accepted 💀.

3.4. Subscriber Processing of NOTIFY Requests 🧚

If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that follows MAY contain a body that describes the present state of the resource after the filters have been applied ✨.

If the NOTIFY says a subscription has been terminated [3], the subscription is assumed to be terminated. Behaviour in those events is also described in [3] 🥀.

If the subscription is indicated as active, NOTIFY requests are handled as described in package-specific documents and in [3] 🍓.

4. Resource List Server Behaviour 🎀

The Resource List Server is defined in [4] 🌈. This section describes how that entity behaves when a filter is in a subscription to a list.

4.1. Request-URI vs. Filter URI 💅

If the URI isn't defined within the filter, the filter applies to the resource list identified in the Request-URI of the SUBSCRIBE request. This means the filters get applied to all the notifications the RLS issues for this subscription. The same goes for a filter whose URI matches the request-URI of the SUBSCRIBE request. Either way, the filter applies to all notifications that the RLS issues for this subscription 💖.

If the URI in the filter is for one resource, and that URI is one of the URIs that come back from a lookup by the RLS on the Request-URI, then the filter for that particular resource gets pulled out and passed along in the SUBSCRIBE sent to that resource. A SUBSCRIBE request can have more than one filter in its body, so a filter specific to a resource MUST be extracted, and only that one is propagated 🦋. For example, say the Request-URI in a SUBSCRIBE is "sip:mybuddies@example.com", where "bob@example.com" is a resource in that list, and the URI in a filter is "sip:bob@example.com". Then the filter specific to Bob is extracted and placed in the body of the SUBSCRIBE sent to "bob@example.com" 🫶.

If the URI in the filter is for one resource whose URI is NOT under the RLS's administrative control, the RLS propagates the filter to all the fanned-out subscriptions. This covers the case where the subscriber knows there are sub-lists in the event list that sit under a different administrative domain from the one where the original subscription was sent, and they want to set a filter for a resource in that sub-list 🌍.

If the URI in the filter is for one resource whose URI is under the RLS's administrative control, but that resource isn't part of the resource list the subscription was addressed to, the filter is NOT propagated. In that case it's the RLS's job to make sure the filter gets applied to notifications issued, if information about that resource is present 🧠.

For example, say we have 2 lists, each on its own RLS:

List1 (list1@example.com) on RLS1 has: bob@example.com

list2@biloxi.com

List2 on RLS2 has: alice@biloxi.com sarah@example.com
(Note: list2 is a resource in list1)

RLS1 receives the following SUBSCRIBE request. It's addressed to list1 and contains 2 filters: one for sarah@example.com and the other for alice@biloxi.com 👀.

SUBSCRIBE sip:List1@example.com SIP/2.0
...
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
  </ns-bindings>
  <filter id="999" uri="sip:sarah@example.com">
    <what>
      <include type="namespace">
        urn:ietf:params:xml:ns:pidf</include>
      <exclude>
        //pidf:tuple/pidf:note</exclude>
    </what>
  </filter>
  <filter id="8439" uri="sip:alice@biloxi.com">
    <what>
      <include>
        //pidf:tuple/pidf:status/pidf:basic</include>
    </what>
  </filter>
</filter-set>

RLS1 fans out subscriptions to the resources on list1. The text above suggests that if a filter is aimed at a resource that isn't part of the list and sits outside RLS1's administrative domain, then that filter gets propagated. The rest get consumed. In our example, only the filter for alice@biloxi.com gets propagated, since biloxi.com isn't under RLS1's administrative domain. The filter for sarah@example.com gets consumed, and RLS1 needs to apply that filter to the notifications it receives 🎉.

URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]) 📏.

A filter can also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In that case, the filter applies to resources in that domain, and the RLS MUST NOT apply filters to any notifications it sends. Instead, it MUST forward the filter with all fanned-out subscriptions to the notifiers 🚫.

As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In those situations, an RLS MUST check that there are no filters addressed to the same resource or domain. If there are, it MUST reject the SUBSCRIBE request with a "488" error response 😤.

4.2. Changing Filters within a Dialog 🔄

If an RLS receives a subscription refresh request with no filters specified (empty payload), the RLS assumes the client doesn't want to update the filters. If an RLS receives a subscription refresh with a filter that has the 'remove="true"' attribute, as defined in [5], the RLS assumes the client is removing the filter identified by that filter ID 🗑️.

If an RLS receives a subscription refresh request with a filter that already exists (meaning it has the same filter ID), the RLS treats it as a replacement for the existing filter. Replacing a filter by changing the filter ID and keeping the resource URI is an error, because it makes the RLS assume there are two filters in place for the same resource 😭.

A filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5] 💜.

5. Server Operation 🖥️

5.1. NOTIFY Bodies 📨

SIP entities compliant with this specification MUST support content-type 'application/simple-filter+xml' 🫶.

This section covers the extra functionality the notifier needs when filters are used in the bodies of SUBSCRIBE requests. Otherwise, the normal package-specific functionality is followed 🧁.

The notifier will check the Content-Type header field, and it will return a 415 response if it doesn't understand the content type 'application/simple-filter+xml' 🙅‍♀️.

A 200-class response means the subscription has been accepted, and the NOTIFY will be sent immediately. A "200" response means the subscription has been accepted, the user is authorized, and the filter is accepted ✨. A "202" response just means the subscription has been understood, but authorization may or may not have been granted. A "202" response also means the filters haven't been accepted yet. The acceptance of the filters MAY arrive in a subsequent NOTIFY 🌷.

If an error comes up, the procedures described in Section 5.4 are followed 🚨.

As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In those situations, a server MUST check that there are no filters addressed to the same resource or domain. If there are, it MUST reject the SUBSCRIBE request with a "488" error response 🛑.

5.2.1. Request-URI vs. Filter URI 🔍

The subscriber may have chosen to leave the URI in the filter undefined. If the URI isn't defined within the filter, the filter applies to the resource identified in the Request-URI 🎯.

Similarly, the subscriber may have chosen to include a URI in the filter. In that case, the filter applies to all notifications sent with content associated with the resource with that URI for this subscription. If the Request-URI and the URI in the filter don't match, the filter may be ignored or rejected. URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]) 🧐.

A filter can also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In that case, the filter applies to resources in that domain. A notifier MUST ignore any filter that uses a 'domain' attribute containing a domain this notifier isn't responsible for. The notifier MUST NOT apply such a filter to any notification it sends. Notifiers that belong to the domain MUST apply the filter to all notifications they send for that subscription, unless policy dictates otherwise 🏰.

5.2.2. Changing Filters within a Dialog 💅

okay so, if a server gets a subscription refresh with an empty payload (no filters at all), it assumes the client does not wish to update the filters 🫶. but if the refresh has a filter with the remove="true" attribute (that's from [5]), the server knows the client is removing whichever filter has that filter ID 🗑️

if the server gets a subscription refresh with a filter that already exists (same filter ID), it reads that as a replacement of the existing filter 🔁 now, replacing a filter by changing the filter ID but keeping the resource URI is an error 🚫 bc the server would then think two filters are placed on the same resource 😭

5.3. Notifier Generating of NOTIFY Requests 🔔

okay this part is the notifier's to-do list 📋 when the SUBSCRIBE with the filter comes in, the notifier SHOULD keep that filter for as long as the subscription sticks around ✨ the filter MAY be folded into an existing subscription (in an active dialog) by sending a re-SUBSCRIBE that has the filter in the body 💖

if the response to the SUBSCRIBE was a "202" and the "202" got picked because the filter couldn't be accepted at that time, the NOTIFY MAY be used to terminate the subscription if the filter ends up being unacceptable 💀

as described in [3], the NOTIFY message MAY contain a body that describes the state of the resource 🌸 that body is in one of the formats listed in the Accept header field of the SUBSCRIBE, or in the package-specific default if the Accept header field is left out 🍓

so based on what's inside a filter, here's what happens 👑

a filter with only a <what> element sends the requested resource state info in that <what> element whenever the resource state changes 🦋
a filter with only a <trigger> element sends all resource state info whenever the resource state changes in a way that matches the triggers 🌈
a filter with <what> and <trigger> elements sends the requested resource state info in that <what> element whenever the resource state changes in a way that matches the triggers 🔥

when a filter is disabled (by setting the enabled attribute to "false"), it means the exact same thing as the filter not being there at all 🙈 so all state and state changes get reported by sending a notification to the subscriber (assuming there are no other filters) 💜

when a filter is re-enabled (by setting the enabled attribute to "true" or by leaving the enabled attribute out), the notifier acts like the filter was just placed by the SUBSCRIBE request that enabled it ✨ the Immediate NOTIFY rules, as stated in Section 5.3.1, apply 🫶

5.3.1. Generation of NOTIFY Contents 🎀

if the NOTIFY being sent is the one right after a 2xx response to the original SUBSCRIBE, its contents MUST be populated according to the filter <what> element 💅 the exceptions: processing the filters would take too long, or the NOTIFY follows a "202" response to the SUBSCRIBE and is terminating the subscription 😭 if the filter is taking too long, the NOTIFY being sent may be empty, or it may be filled with a pre-configured value that's authorised for that subscriber 🧚 if applying the filter leaves no content to deliver, the NOTIFY MUST be sent with empty contents 🫧 and if the filter has <trigger> elements, the notifier ignores the trigger values when it generates the first NOTIFY ✨

the input to the content filter is a package-specific XML document (e.g., [7] and [9]) that's derived following the package-specific specifications (e.g., [8] and [10]) 📄

the content gets filtered according to the expressions in the <what> element of the filter 🔍 the expression says which XML elements and/or attributes get delivered. the namespace prefixes of the items in the XML document being filtered must be expanded before the filter is applied to those items 💖

the expression directly states which XML elements and attributes get delivered in the NOTIFY, along with their values 🎯 on top of the selected contents, the namespaces of all the selected items are included in the NOTIFY too 🌸 the XML elements and/or attributes indicated by the expression in the <what> element must be items the subscriber is authorised to see. if they aren't, the notifier policy decides what happens (the notifier can ignore the filter, parts of the filter, or reject the filter completely) 🚦 implementers need to think really carefully about this one 🧠 the subscriber may not know what they're authorised to see, so they'll most likely include a filter asking for stuff they can't access 🙈 so it is RECOMMENDED that notifiers just ignore the parts of the filter asking for unauthorised info (i.e., the filter in the <filter> element where unauthorised contents are requested gets ignored) 🫶 if the notifier uses polite blocking, it may choose to deliver notifications with bogus information in the unauthorised elements or attributes, and apply the filter afterwards 🎭

the resultant XML document MUST be well formed and valid according to the XML schema 💯 this means all mandatory elements and attributes, along with their values, MUST be included in the XML document no matter what the expression says 👑 in other words, if applying a filter to an XML document gives you a non-valid XML document, the notifier MUST add elements and attributes (along with their values) from the original XML document into the newly made one so it becomes valid 🛠️

5.3.2. Handling of Notification Triggering Rules 🚨

one <filter> element can have several <trigger> elements inside it 🌈 if the criteria for any of the <trigger> elements are satisfied, a NOTIFY SHOULD be generated 🔔

the items (XML elements and/or attributes) indicated by the expression in the <changed> element, <added> element, or <removed> element must be items the subscriber is authorised to access 🔐 if they aren't, the notifier policy decides what happens (it can ignore the filter, parts of the filter, or reject the filter completely) 🙃

5.4. Handling Abnormal Cases ⚠️

if a filter definition is invalid, meaning its XML document doesn't line up with the XML schema of the filter format [5], the notifier rejects the SUBSCRIBE request with a "488" response 🙅‍♀️ a Warning header field in that response may give a better hint about why the filters weren't accepted 💡 if the subscription got accepted with a "202" response but the invalid filter was discovered after that, a NOTIFY with a subscription-state of value 'terminated' is sent 💀 an event-reason-value "badfilter" (introduced here) of subexp-params [3] MAY be included 🫧

if there's an erroneous expression in the filter definition, the notifier either ignores the filter definition or terminates the subscription 🙈

if a <what> or <trigger> element is empty, the notifier proceeds as if that element didn't exist 🌸

6. XML Document Validation 📑

the subscriber of the filter MUST ensure that the XML document inserted as the SUBSCRIBE request body is well formed and valid 💯 the subscriber MUST NOT insert any extension elements or attributes into the XML document unless it has access to the extension schema and can validate the XML document 🚫 the XML document notifier MAY validate the XML document according to the schemas it has access to that apply to this XML document, including extension schemas 🔍

7. Examples 🧁

the following sections include filtering examples for Presence and Watcher Information 🦋 the format of the filter follows [5] 💅

7.1. Presence Specific Examples 💖

this section covers three use cases where the presence information filtering solution gets used [8] ✨ in the first use case, the watcher wants messaging-specific info about a certain presentity 💬 in the second, the watcher wants to know the communication means and contact addresses the presentity is currently available on 📞 and the third case shows how a presentity can request triggers to receive notifications 🔔

below is the presentity's presence information in PIDF [7] 🌷 it has two tuples: one for instant messaging and another for voice-related info 🎀

   <?xml version="1.0" encoding="UTF-8"?>
         <presence xmlns="urn:ietf:params:xml:ns:pidf"
                           xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
                           entity="sip:presentity@example.com">
            <tuple id="432sd">
               <status>
                  <basic>closed</basic>
               </status>
               <rpid:class>IM</rpid:class>
               <contact>im:presentity@example.com</contact>
            </tuple>
            <tuple id="thr76jk">
               <status>
                  <basic>open</basic>
               </status>
               <rpid:class>voice</rpid:class>
               <contact>tel:2224055555@example.com</contact>

            </tuple>
         </presence>

Okay so the subscriber is basically saying "hey, only tell me about my messaging stuff" 💬✨ (MMS, IM, and SMS presence info, to be exact). That subscription comes with a content limiting filter attached 🎀

The filter is written as an expression that picks out the <basic> element plus every parent above it (the <status>, the <tuple>, and the root element), and it also grabs the <class> element and the <contact> element 🧚 The filter matches when <class> contains "MMS", "SMS", or "IM" 💅

So in this case, the notification only includes the tuple whose <class> is "IM" 💖

Here's the SUBSCRIBE request coming from the subscriber, filter and all:

SUBSCRIBE sip:presentity@example.com
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag:12341111
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
Expires: 3600
Event: Presence
Contact: <sip:watcher@client.example.com>
Content-Type: application/simple-filter+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
    <ns-binding prefix="rpid"
                       urn="urn:ietf:params:xml:ns:pidf:rpid"/>
  </ns-bindings>
  <filter id="123" uri="sip:presentity@example.com">
    <what>
      <include type="xpath">
        //pidf:tuple[rpid:class="IM" or rpid:class="SMS"
        or rpid:class="MMS"]/pidf:status/pidf:basic
    </include>
    <include type="xpath">
      //pidf:tuple[rpid:class="IM" or rpid:class="SMS"
      or rpid:class="MMS"]/rpid:class

    </include>
    <include type="xpath">
      //pidf:tuple[rpid:class="IM" or rpid:class="SMS"
      or rpid:class="MMS"]/pidf:contact
    </include>
    </what>
  </filter>
</filter-set>

And here's the notification that goes back to the subscriber 📬🌸

NOTIFY sip:watcher@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: <sip:watcher@example.com>;tag:12341111
From: <sip:presentity@example.com>;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Event: Presence
Subscription-State: active; expires=3599
Contact: sip:presentity@server.example.com
Content-Type: application/pidf+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
   xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
   entity="sip:presentity@example.com">
      <tuple id="432sd">
         <status>
            <basic>closed</basic>
         </status>
         <rpid:class>IM</rpid:class>
         <contact>im:presentity@example.com</contact>
      </tuple>
   </presence>

7.1.2. Subscriber Fetches Information about "Open" Communication Means

Now the subscriber wants to know which communication means the presentity has available 🦋 So it subscribes with a content-limiting filter too 🎀

Same vibe as before: the expression picks the <basic> element and all its parents (the <status>, the <tuple>, and the root element), plus the <class> element and the <contact> element 🧚 This time the filter matches when the <basic> element's value is "open" 🌈

So the notification returns the tuple that has "open" inside its <status> element 💖

Here's the SUBSCRIBE request with the filter:

SUBSCRIBE sip:presentity@example.com SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag:12341111
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
Expires: 3600
Event: Presence
Contact: <sip:watcher@client.example.com>
Content-Type: application/simple-filter+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
    <ns-binding prefix="rpid"
                       urn="urn:ietf:params:xml:ns:pidf:rpid"/>
  </ns-bindings>
  <filter id="123" uri="sip:presentity@example.com">
    <what>
      <include type="xpath">
        //pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic
      </include>
      <include type="xpath">
        //pidf:tuple[pidf:status/pidf:basic="open"]/rpid:class
      </include>
      <include type="xpath">
        //pidf:tuple[pidf:status/pidf:basic="open"]/pidf:contact
      </include>
    </what>
  </filter>
</filter-set>

And the notification back to the subscriber 📨✨

NOTIFY sip:watcher@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: <sip:watcher@example.com>;tag:12341111
From: <sip:presentity@example.com>;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Event: Presence
Subscription-State: active; expires=3599
Contact: sip:presentity@server.example.com
Content-Type: application/pidf+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
   xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
   entity="sip:presentity@example.com">
      <tuple id="thr76jk">
         <status>
            <basic>open</basic>
         </status>
            <rpid:class>voice</rpid:class>
            <contact>tel:2224055555@example.com</contact>
      </tuple>
   </presence>

7.1.3. Subscriber Requests Notifications When Presentity's Status Changes

This one is giving "tell me when it changes" energy 🔔 The subscriber subscribes to the presentity and says it only wants notifications when the <basic> element has changed to "open" 🌸

Here's the SUBSCRIBE request with that filter:

SUBSCRIBE sip:presentity@example.com
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag:12341111
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
Expires: 3600
Event: Presence
Contact: <sip:watcher@client.example.com>
Content-Type: application/simple-filter+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
  </ns-bindings>
  <filter id="123" uri="sip:presentity@example.com">
    <trigger>
      <changed from="closed" to="open">
        /pidf:presence/pidf:tuple/pidf:status/pidf:basic

      </changed>
    </trigger>
  </filter>
</filter-set>

Later on during the subscription, a second PIDF document shows up, and this time both tuples have a status of "closed" 🥺

<?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
   xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
   entity="sip:presentity@example.com">
      <tuple id="432sd">
         <status>
           <basic>closed</basic>
         </status>
            <rpid:class>IM</rpid:class>
            <contact>im:presentity@example.com</contact>
      </tuple>
      <tuple id="thr76jk">
         <status>
            <basic>closed</basic>
         </status>
         <rpid:class>voice</rpid:class>
         <contact>tel:2224055555@example.com</contact>
      </tuple>
   </presence>

No NOTIFY gets sent to the subscriber in this case 🙈

Then a third PIDF document is created once the IM status flips to "open" 🚀

<?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
   xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
   entity="sip:presentity@example.com">
      <tuple id="432sd">
         <status>
            <basic>open</basic>
         </status>
         <rpid:class>IM</rpid:class>
         <contact>im:presentity@example.com</contact>
      </tuple>
      <tuple id="thr76jk">
         <status>
            <basic>closed</basic>
         </status>
         <rpid:class>voice</rpid:class>
         <contact>tel:2224055555@example.com</contact>
      </tuple>
   </presence>

This time the notification contains both tuples and gets sent to the subscriber 👑

NOTIFY sip:watcher@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: <sip:watcher@example.com>;tag:12341111
From: <sip:presentity@example.com>;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Event: Presence
Subscription-State: active; expires=3599
Contact: sip:presentity@server.example.com
Content-Type: application/pidf+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
   xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
   entity="sip:presentity@example.com">
      <tuple id="432sd">
         <status>
            <basic>closed</basic>
         </status>
         <rpid:class>IM</rpid:class>
         <contact>im:presentity@example.com</contact>
      </tuple>
      <tuple id="thr76jk">
         <status>
            <basic>open</basic>
         </status>
         <rpid:class>voice</rpid:class>
         <contact>tel:2224055555@example.com</contact>
      </tuple>
   </presence>

7.2. Watcher Information Specific Examples

Bestie, these examples use the winfo template-package together with the presence event package [10] 🧚💜

Here's the watcher information sent to a presentity 👀

<?xml version="1.0"?>
  <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
  <watcher-list resource="sip:presentity@example.com"
                package="presence">
      <watcher status="active"
         id="sr8fdsj"
         duration-subscribed="509"
         expiration="20"
         event="approved">sip:watcherA@example.com"</watcher>
      <watcher status="pending"
         id="sr8fdsj"
         duration-subscribed="501"
         expiration="100"
         event="subscribe">sip:watcherB@example.com"</watcher>
      <watcher status="terminated"
         id="sr8fdsj"
         duration-subscribed="500"
         expiration="0"
         event="rejected">sip:watcherC@example.com"</watcher>
      <watcher status="active"
         id="sr8fdsj"
         duration-subscribed="20"
         expiration="30"
         event="approved">sip:watcherD@example.com"</watcher>
  </watcher-list>
  </watcherinfo>

7.2.1. Watcher Subscriber Makes Subscription to Get All the Information about Active Watchers ✨

Okay so this one is giving "I want ALL the info about my active watchers" 💖 Here's the SUBSCRIBE request from the presentity, filter and all:

SUBSCRIBE sip:presentity@example.com
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag:12341111
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
Expires: 3600
Event: Presence.winfo
Contact: sip:presentity@client.example.com
Content-Type: application/simple-filter+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="wi"
                       urn="urn:ietf:params:xml:ns:watcherinfo"/>
  </ns-bindings>
  <filter id="123" uri="sip:presentity@example.com">
    <what>
      <include>
        /wi:watcherinfo/wi:watcher-list[@package="presence"]/
        wi:watcher[@status="active"]
      </include>
</what>
</filter>
</filter-set>

And here's the notification going back to the subscriber 🦋

NOTIFY sip:presentity@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: sip:presentity@example.com;tag:12341111
From: sip:presentity@example.com;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Contact: sip:presentity@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:presentity@example.com"
                package="presence">
      <watcher status="active"
         id="sr8fdsj"
         duration-subscribed="509"
         expiration="20"
         event="approved">sip:watcherA@example.com"</watcher>
      <watcher status="active"
         id="sr8fdsj"
         duration-subscribed="20"
         expiration="30"
         event="approved">sip:watcherD@example.com"</watcher>
  </watcher-list>
  </watcherinfo>

7.2.2. Watcher Subscriber Requests Information of Watchers with Specific Subscription Duration Conditions 🎀

This time the presentity sends a SUBSCRIBE with Expires: 0 and a filter that only wants watchers whose subscription has lasted longer than 500. Main character energy 👑 Here's the request:

SUBSCRIBE sip:presentity@example.com
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk
To: <sip:presentity@example.com>;tag:12341111
From: <sip:presentity@example.com>
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
Expires: 0
Event: Presence.winfo
Contact: <sip:presentity@client.example.com>
Content-Type: application/simple-filter+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="wi"
                       urn="urn:ietf:params:xml:ns:watcherinfo"/>
  </ns-bindings>
  <filter id="123" uri="sip:presentity@example.com">
    <what>
      <include>
        /wi:watcherinfo/wi:watcher-list[@package="presence"]/
        wi:watcher[@duration-subscribed>500]
      </include>
    </what>

  </filter>
</filter-set>

And the notification that comes back, where only the matching watchers show up 💅

NOTIFY sip:presentity@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: sip:presentity@example.com;tag:12341111
From: sip:presentity@example.com;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Contact: sip:presentity@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:presentity@example.com"
                package="presence">
      <watcher status="active"
         id="sr8fdsj"
         duration-subscribed="509"
         expiration="20"
         event="approved">sip:watcherA@example.com"</watcher>
      <watcher status="pending"
         id="sr8fdsj"
         duration-subscribed="501"
         expiration="100"
         event="subscribe">sip:watcherB@example.com"</watcher>
  </watcher-list>
  </watcherinfo>

7.2.3. Watcher Subscriber Requests Specific Watcher Info on Specific Triggers 🧚

This one is so specific and I'm obsessed. This filter picks out the watcher information notifications [9] that should be sent when the pending subscription status changes from "pending" to "terminated". In the notification, only the watchers with a status of "terminated" and an event of "rejected" are included.

Here's the SUBSCRIBE request from the Watcher Subscriber, filter included:

SUBSCRIBE sip:presentity@example.com
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk
To: <sip:presentity@example.com>;tag:12341111
From: <sip:presentity@example.com>
Call-ID: 32432udfidfjmk342
Cseq: 1 SUBSCRIBE
Expires: 0
Event: Presence.winfo
Contact: <sip:presentity@client.example.com>
Content-Type: application/simple-filter+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-winfo-filter">
  <ns-bindings>
    <ns-binding prefix="wi"
                       urn="urn:ietf:params:xml:ns:watcherinfo"/>
  </ns-bindings>
  <filter id="123" uri="sip:presentity@example.com">
    <what>
      <include>
        /wi:watcherinfo/wi:watcher-list[@package="presence"]/
        wi:watcher[@status="terminated" and @event="rejected"]
      </include>
    </what>
    <trigger>
      <changed from="pending"
                                           to="terminated">
        //@status
      </changed>
    </trigger>
  </filter>
</filter-set>

Later on in the subscription, a second Winfo document shows up because something changed 👀

<?xml version="1.0"?>
    <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
  version="0" state="full">
    <watcher-list resource="sip:presentity@example.com"
                  package="presence">
        <watcher status="active"
           id="sr8fdsj"
           duration-subscribed="509"
           expiration="20"
           event="approved">sip:watcherA@example.com"</watcher>
        <watcher status="terminated"
           id="sr8fdsj"
           duration-subscribed="501"
           expiration="100"
           event="rejected">sip:watcherB@example.com"</watcher>
        <watcher status="terminated"
           id="sr8fdsj"
           duration-subscribed="500"
           expiration="0"
           event="rejected">sip:watcherC@example.com"</watcher>
        <watcher status="active"
           id="sr8fdsj"
           duration-subscribed="20"
           expiration="30"
           event="approved">sip:watcherD@example.com"</watcher>
   </watcher-list>
    </watcherinfo>

So the notification gets built using both the <trigger> and the <what> elements. Here's what the subscriber gets 🫶

NOTIFY sip:presentity@client.example.com SIP/2.0
Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder
To: sip:presentity@example.com;tag:12341111
From: sip:presentity@example.com;tag:232321
Call-ID: 32432udfidfjmk342
Cseq: 1 NOTIFY
Contact: sip:presentity@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:presentity@example.com"
                package="presence">
      <watcher status="terminated"
         id="sr8fdsj"
         duration-subscribed="501"
         expiration="100"
         event="rejected">sip:watcherB@example.com"</watcher>
      <watcher status="terminated"
         id="sr8fdsj"
         duration-subscribed="500"
         expiration="0"
         event="rejected">sip:watcherC@example.com"</watcher>
  </watcher-list>
  </watcherinfo>

8. Security Considerations 🔒

Okay, this section is serious, bestie, so read it carefully 😭 Putting filters in the body of a SIP message has a big effect on how a server handles the request. That's exactly why messages with this extension need to be authenticated and authorized. Authentication can use the Digest Authentication mechanism described in [2]. The authorization decision is based on the permissions that the resource (notifier) has given to the watcher. An example of that kind of authorization policy is in [11].

Processing requests and looking up filters takes set operations and searches, which can cost a fair bit of computation. That opens the door to a DoS attack, where a user sends requests stuffed with lots of messages with big contents, hoping to overload the server 💀 To counter this, the server can set a limit on how many <what>, <changed>, <added>, and <removed> elements are allowed in the filters. A default limit of 40 is RECOMMENDED; however, servers may raise or lower the limit depending upon their specific engineered capacity.

Requests can reveal sensitive information about a User Agent's (UA's) capabilities. If that information is sensitive, it SHOULD be encrypted using SIP S/MIME capabilities [6]. All package-specific security measures MUST be followed.

Propagating filters in SUBSCRIBE requests to foreign domains reveals sensitive information about a user's resource lists 😱 So it's required that an RLS does not forward a filter if that filter is addressed to a resource under the administrative domain of the RLS, but that resource is not on the resource list. Section 4.1 shows an example where this scenario can happen.

Also, a filtered document at a subscriber can project a false reality 🙈 For example, say a subscriber asked to be notified when a resource changes its presence state from "closed" to "open", but not from "open" to "closed". The subscriber might then believe the resource's presence state is "open", even long after the resource has changed it to "closed". So subscribers need to be sure what they put in a filter, understand what they asked for, and be ready to be out of sync with the real state of a resource.

9. IANA Considerations 📋

A new event-reason-value "badfilter" is defined to represent the event where the filter is not well formed and/or not accepted. No IANA registration is required for this value.

10. Acknowledgements 💜

The authors would like to thank George Foti, Tim Moran, Sreenivas Addagatla, Juha Kalliokulju, Jari Urpalainen, and Mary Barnes for their valuable input. Iconic behavior from all of them 🌈

11. References 📚

11.1. Normative References 📚

Okay bestie, these are the must-read sources the spec leans on, so I'm listing them all with every detail 💅

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4663, September 2006.
[5] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, "An Extensible Markup Language (XML)-Based Format for Event Notification Filtering", RFC 4661, September 2006.
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

11.2. Informative References 🦋

These ones are the background reading. Super helpful, not strictly required, but iconic to know about 🧚

[7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[9] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
[10] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[11] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006.

Authors' Addresses 🎀

Meet the girls who made this happen 🫶

Hisham Khartabil
Telio
P.O. Box 1203 Vika
Oslo
Norway

Phone: +47 2167 3544
EMail: hisham.khartabil@telio.no


Eva Leppanen
Nokia
P.O BOX 785
Tampere
Finland

Phone: +358 7180 77066
EMail: eva-maria.leppanen@nokia.com


Mikko Lonnfors
Nokia
P.O BOX 321
Helsinki
Finland

Phone: + 358 71800 8000
EMail: mikko.lonnfors@nokia.com


Jose Costa-Requena
Nokia
P.O. Box 321
FIN-00045 NOKIA GROUP
FINLAND

Phone: +358 71800 8000
EMail: jose.costa-requena@nokia.com

Full Copyright Statement ⭐

Legal stuff time, but it's still important 💖

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 is being very careful here, and honestly that's a whole mood 🧚

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 procedures with respect to 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 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 🍓

Shoutout to whoever keeps the lights on 💜

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

📦 where this page comes from

ietf: rfc4660 2006-09
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms