RFC 3840

Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)

📅 published August 2004, from ietf

RFC 3840 💖 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)

okay bestie, this one is all about how a SIP user agent can say what it can do and what it is 🎀 It's titled Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) ✨

The authors are J. Rosenberg (dynamicsoft), H. Schulzrinne (Columbia University), and P. Kyzivat (Cisco Systems). It came out of the Network Working Group in August 2004. It's a Standards Track doc, so it's a real protocol spec, not just vibes 💅 The title block doesn't list anything it obsoletes or updates, so it's standing on its own 👑

Status of this Memo 📜

This document is a standards track protocol spec for the Internet community. It's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 🔍 Distribution of this memo is unlimited 🌈

Copyright Notice ©️

Copyright (C) The Internet Society (2004).

Abstract 🦋

This spec defines how a Session Initiation Protocol (SIP) user agent can share its capabilities and characteristics with other user agents and with the registrar for its domain 🌸 All of that info travels as parameters of the Contact header field, which is so clever 🧚

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
4.  Usage of the Content Negotiation Framework . . . . . . . . . .  6
5.  Computing Capabilities . . . . . . . . . . . . . . . . . . . .  7
6.  Expressing Capabilities in a Registration  . . . . . . . . . . 10
7.  Indicating Feature Sets in Remote Target URIs  . . . . . . . . 12
8.  OPTIONS Processing . . . . . . . . . . . . . . . . . . . . . . 13
9.  Contact Header Field . . . . . . . . . . . . . . . . . . . . . 13
10. Media Feature Tag Definitions  . . . . . . . . . . . . . . . . 14
    10.1.  Audio . . . . . . . . . . . . . . . . . . . . . . . . . 15
    10.2.  Application . . . . . . . . . . . . . . . . . . . . . . 16
    10.3.  Data. . . . . . . . . . . . . . . . . . . . . . . . . . 16
    10.4.  Control . . . . . . . . . . . . . . . . . . . . . . . . 17
    10.5.  Video . . . . . . . . . . . . . . . . . . . . . . . . . 17
    10.6.  Text. . . . . . . . . . . . . . . . . . . . . . . . . . 18
    10.7.  Automata. . . . . . . . . . . . . . . . . . . . . . . . 18
    10.8.  Class . . . . . . . . . . . . . . . . . . . . . . . . . 19
    10.9.  Duplex. . . . . . . . . . . . . . . . . . . . . . . . . 20
    10.10. Mobility. . . . . . . . . . . . . . . . . . . . . . . . 20
    10.11. Description . . . . . . . . . . . . . . . . . . . . . . 21
    10.12. Event Packages. . . . . . . . . . . . . . . . . . . . . 22
    10.13. Priority. . . . . . . . . . . . . . . . . . . . . . . . 22
    10.14. Methods . . . . . . . . . . . . . . . . . . . . . . . . 23
    10.15. Extensions. . . . . . . . . . . . . . . . . . . . . . . 24
    10.16. Schemes . . . . . . . . . . . . . . . . . . . . . . . . 24
    10.17. Actor . . . . . . . . . . . . . . . . . . . . . . . . . 25
    10.18. Is Focus. . . . . . . . . . . . . . . . . . . . . . . . 26
11. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
    11.1.  Considerations for Media Feature Tags . . . . . . . . . 26
    11.2.  Considerations for Registrations. . . . . . . . . . . . 27
    11.3.  Considerations for OPTIONS Responses. . . . . . . . . . 28
    11.4.  Considerations for Dialog Initiating Messages . . . . . 28
12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
    12.1.  SIP Media Feature Tag Registration Tree . . . . . . . . 28
    12.2.  Media Feature Tags. . . . . . . . . . . . . . . . . . . 29
    12.3.  SIP Option Tag. . . . . . . . . . . . . . . . . . . . . 30
13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 30
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
    14.1.  Normative References. . . . . . . . . . . . . . . . . . 31
    14.2.  Informative References. . . . . . . . . . . . . . . . . 31
Appendix.  Overview of RFC 2533. . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36

1. Introduction ✨

SIP [1] user agents are super varied in what they can do and what kind of devices they live on 📱 A lot of the time, it really matters that another SIP element can figure out a SIP UA's capabilities and characteristics 🕵️‍♀️ Some of the situations where that info is useful:

One user agent, a PC-based app, is talking to another one that lives inside a limited-function device. The PC wants to be able to "grey out" the bits of the UI for features its peer doesn't support 🙈 So there needs to be a way to swap capability info within a dialog.
A user has two devices: a videophone and a voice-only wireless phone 📞 A caller wants to video chat with them, so they'd love for the call to be routed to the device that supports video 🎥 To make that happen, the INVITE request can carry parameters that show a preference for a device with certain capabilities [11] 💜
A network app wants to send info to a UA asynchronously in a MESSAGE [16] request 💌 Before sending, they'd like to know if the UA can actually receive it. Ideally they'd check a user database run by the domain, which means the UA has to share its capabilities as part of its registration 📒 So yep, there's a real need for capability info in REGISTER requests 🙌

SIP does have some capability support 🫧 The Allow, Accept, Accept-Language, and Supported header fields share a bit of info about a user agent's capabilities. But they only share a small slice of what's needed 😭 They don't give you a general framework for expressing capabilities. They also only describe capabilities indirectly, since they really show what the UA can do for this particular request. And SIP has zero way to convey characteristics, meaning info that describes what a UA is 💀

So this spec brings in a more general framework for indicating capabilities and characteristics in SIP 👑 That info travels as parameters of the Contact header field. These parameters can be used in REGISTER requests and responses, OPTIONS responses, and in requests and responses that create dialogs (like INVITE) 🦋

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 BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations 🔥

3. Definitions 📚

Feature: As defined in RFC 2703 [17], a piece of information about the media handling properties of a message passing system component or of a data resource. For example, the SIP methods supported by a UA represent a feature 🧩
Feature Tag: As defined in RFC 2703 [17], a feature tag is a name that identifies a feature. An example is "sip.methods" 🏷️
Media Feature: As defined in RFC 2703, [17], a media feature is information that indicates facilities assumed to be available for the message content to be properly rendered or otherwise presented. Media features are not intended to include information that affects message transmission 🎨

In the context of this specification, a media feature is information that indicates facilities for handling SIP requests, rather than specifically for content. In that sense, it is used synonymously with feature ✨

Feature Collection: As defined in RFC 2533 [4], a feature collection is a collection of different media features and associated values. This might be viewed as describing a specific rendering of a specific instance of a document or resource by a specific recipient 📦
Feature Set: As defined in RFC 2703 [17], a feature set is information about a sender, recipient, or other participant in a message transfer which describes the set of features that it can handle. Where a 'feature' describes a single identified attribute of a resource, a 'feature set' describes a full set of possible attributes 🌈
Feature Parameters: A set of SIP header field parameters that can appear in the Contact header field. The feature parameters represent an encoding of a feature set. Each set of feature parameters maps to a feature set predicate 🗝️
Capability: As defined in RFC 2703 [17], a capability is an attribute of a sender or receiver (often the receiver) which indicates an ability to generate or process a particular type of message content. A capability is distinct from a characteristic in that a capability may or may not be utilized in any particular call, whereas a characteristic is a non-negotiable property of a UA. SIP itself will often negotiate whether or not capabilities are used in a call 🤝
Characteristic: A characteristic is like a capability, but describes an aspect of a UA which is not negotiable. As an example, whether or not a UA is a mobile phone is a characteristic, not a capability. The semantics of this specification do not differentiate between capability and characteristic, but the distinction is useful for illustrative purposes. Indeed, in the text below, when we say "capability", it refers to both capabilities and characteristics, unless the text explicitly says otherwise 🎀
Filter: A single expression in a feature set predicate 🔎
Simple Filter: An expression in a feature set predicate which is a comparison (equality or inequality) of a feature tag against a feature value 🍓
Disjunction: A boolean OR operation across some number of terms 🔀
Conjunction: A boolean AND operation across some number of terms 🔗
Predicate: A boolean expression 🧠
Feature Set Predicate: From RFC 2533 [4], a feature set predicate is a function of an arbitrary feature collection value which returns a Boolean result. A TRUE result is taken to mean that the corresponding feature collection belongs to some set of media feature handling capabilities defined by this predicate 💅
Contact Predicate: The feature set predicate associated with a URI registered in the Contact header field of a REGISTER request. The contact predicate is derived from the feature parameters in the Contact header field 💫

🫶 to be continued in part 2, bestie, stay tuned 🦋

4. Usage of the Content Negotiation Framework ✨

okay so this spec leans SUPER hard on the content negotiation stuff the IETF has been cooking up, and it's written up across a bunch of RFCs 💅 the ones that matter here are RFC 2506 [3], which gives you a template for registering media feature tags, RFC 2533 [4], which brings a syntax and matching algorithm for media feature sets, RFC 2738 [5], a minor update to RFC 2533, and RFC 2703 [17], a general framework for content negotiation 🧚

if you don't have time to read all of those (no judgment, we're all busy bestie 🫶), Appendix A gives you a quick rundown of the concepts and terminology from those docs that you need to actually get this spec.

okay now the fun part 🔥 content negotiation was originally built for documents and resources that can come in a bunch of different renderings, so it's not obvious at first how it fits SIP user agents. the vibe is that a feature set is made of feature collections, and each collection is one specific rendering the entity can do. for a SIP UA, a feature collection is an instantaneous modality. like, if you freeze-frame the run-time processing of a SIP UA, the feature collection tells you exactly what it's doing in that very instant ⏸️✨

this model is SO important because it tells you how to decide whether something is a value for a feature tag or a feature tag by itself 👑 if two properties can both be true for a UA at the same time, so they show up together in one instantaneous modality, they need their own separate media feature tags. for example, a UA might handle some media types like audio, video, and control. so should each of those be a different value of one "media-types" feature tag, or should each one be its own boolean feature tag? the model answers that for us 🎀 at any given instant a UA could be handling audio and video, so they each get their own media feature tag. BUT the SIP methods a UA supports can each be a different value of the same media feature tag (the "sip.methods" tag), because fundamentally a UA processes one request at a time. it might be multi-threaded and look like it's doing more, but at a purely functional level, that's the truth 🧵

ngl there are weaknesses in this model, but it's a super useful guideline for applying the RFC 2533 concepts to what we're solving here 🦋

5. Computing Capabilities 🌸

okay so to build the set of Contact header field parameters that describe capabilities, a UA builds a feature predicate for that contact 💖 this is explained in terms of RFC 2533 [4] syntax and constructs (plus its minor update, RFC 2738 [5]), and then it gets converted into the syntax this spec uses. BUT that's just the logical flow of processing, not a rule that your implementation has to actually use RFC 2533 syntax as a middle step 🙈

a UA MAY use any feature tags registered through IANA in the SIP tree (Established in Section 12.1), the IETF tree, or the global tree [3], and this document registers several into the SIP tree ✨ the feature tags discussed in this spec are called base tags. other tags are allowed too, but to show they're feature parameters (and not parameters for some other SIP extension), they get a leading "+" sign in the Contact header field 🫶 it's also fine to use the URI tree [3] for vendor-specific feature tags, and feature tags in any other IANA-created tree MAY also be used 🌈

now the rules for the sip.* tags are lowkey strict, so pay attention 👀

when using the "sip.methods" feature tag, a UA MUST NOT include values for methods that aren't standardized in IETF standards track RFCs 🚫
when using the "sip.events" feature tag, a UA MUST NOT include values for event packages that aren't standardized in IETF standards track RFCs 🚫
when using the "sip.schemes" feature tag, a UA MUST NOT include values for schemes that aren't standardized in IETF standards track RFCs 🚫
when using the "sip.extensions" feature tag, a UA MUST NOT include values for option tags that aren't standardized in IETF standards track RFCs 🚫

quick note 💅 the "sip.schemes" feature tag does NOT tell you the scheme of the URI you registered. it's about which schemes the UA can actually send requests to, in case it gets a URI in a web page or in a Contact header field of a redirect response 🧚‍♀️

okay so now the big recommendations 🍓 it is RECOMMENDED that a UA gives complete info in its contact predicate, meaning it SHOULD give info on as many feature tags as it can. the mechanisms in this spec work best when UAs register complete feature sets 💜 and when a UA registers values for a particular feature tag, it MUST list ALL the values it supports. so if you're including "sip.methods", you MUST list every method you support 🙌

the contact predicate a UA builds MUST be an AND of terms (a conjunction) 🔗 each term is either an OR of simple filters (a disjunction), or negations of simple filters, or a single simple filter (or the negation of one). for a disjunction, every filter in it MUST be for the same feature tag (so the disjunction is a set of values for one tag), while every element of the conjunction MUST be for a DIFFERENT feature tag 🎀 each simple filter can be an equality or, for numeric feature tags, an inequality or a range. if a string (as defined in RFC 2533 [4]) is used as the value of a simple filter, that value MUST NOT include the "<" or ">" characters, the simple filter MUST NOT be negated, and it MUST be the only simple filter for that particular feature tag ⚠️ once that's all set, the contact predicate gets converted into a list of feature parameters using the procedure below 🦋

this is where it gets a little bit intense, so take a deep breath 🌸

the contact predicate is a conjunction of terms. each term puts constraints on ONE feature tag, and each term turns into its own feature parameter in the Contact header field 💖 the syntax of that parameter depends on the feature tag. every forward slash in the feature tag becomes a single quote, and every colon becomes an exclamation point ✨ for the base tags (the ones documented in this spec: sip.audio, sip.automata, sip.class, sip.duplex, sip.data, sip.control, sip.mobility, sip.description, sip.events, sip.priority, sip.methods, sip.extensions, sip.schemes, sip.application, sip.video, language, type, sip.isfocus, sip.actor and sip.text), the leading "sip." gets stripped if it's there 🧚 for feature tags NOT on that list, the leading "sip." MUST NOT be stripped if present, and a plus sign ("+") MUST be added as the first character of the Contact header field parameter 🫶 the result is the feature parameter name. because of these rules, base tags show up "naked" in the Contact header field, with neither a "+" nor a "sip." prefix 🌈 everything else always has a leading "+" when it's in the Contact header field, and it also gets a "sip." if the tag is in the SIP tree 💅

the value of the feature parameter depends on the term of the conjunction 👑 if the term is a boolean expression that's true, like (sip.audio=TRUE), the contact parameter has no value at all ✨ if the term is a disjunction, the contact parameter's value is a quoted string, which is a comma-separated list of strings, each one built from one of the terms in the disjunction 🍓 if the term is a negation, the value is a quoted string that starts with an exclamation point (!), and the rest gets built from the expression being negated 🙈

the last step is making a string from a primitive filter. if the filter is a simple filter doing a numeric comparison, the string starts with an octothorpe (#), then the comparator from the filter (=, >=, or <=), then the value from the filter 🔢 if the value is written as a rational (X / Y), then X and Y get divided, and the resulting decimal number goes into the string 🧮

RFC 2533 uses a fractional notation to describe rational numbers. This specification uses a decimal form. The above text merely converts between the two representations. Practically speaking, this conversion is not needed since the numbers are the same in either case. However, it is described in case implementations wish to directly plug the predicates generated by the rules in this section into an RFC 2533 implementation.

if the filter is a range (foo=X..Y), the string is X:Y, where X and Y have been converted from fractions (A / B) to their decimal equivalents 📏 if the filter is an equality over a token or a boolean, then that token or boolean value ("TRUE" or "FALSE") goes into the string 💜 if the filter is an equality over a quoted string, the output is a less-than sign (<), then the quoted string, then a greater-than sign (>) 💖

okay example time 🎀 this feature predicate:

(& (sip.mobility=fixed)
   (| (! (sip.events=presence)) (sip.events=message-summary))
   (| (language=en) (language=de))
   (sip.description="PC")
   (sip.newparam=TRUE)
   (rangeparam=-4..5125/1000))

would get converted into these feature parameters:

mobility="fixed";events="!presence,message-summary";language="en,de"
   ;description="<PC>";+sip.newparam;+rangeparam="#-4:+5.125"

and those feature tags would then show up as part of the Contact header field:

Contact: <sip:user@pc.example.com>
          ;mobility="fixed";events="!presence,message-summary"
          ;language="en,de";description="<PC>"
          ;+sip.newparam;+rangeparam="#-4:+5.125"

notice how the leading "sip." got stripped off sip.mobility, sip.events and sip.description before they were encoded in the Contact header field 🧚 that's because those are all base tags, which is also why they didn't get a "+" either ✨ but sip.newparam got BOTH the "+" and its leading "sip.", and rangeparam got a leading "+" too 🌈 that's because neither of those is defined in this spec, so the leading "sip." stays on and a "+" gets added 💅 iykyk 💜

6. Expressing Capabilities in a Registration ✨

Okay so when a UA registers, it can choose to share a feature set for its registered contact 💖 Whether it does depends on what the registered URI actually represents 🤔 If the registered URI is a UA instance (the most common case in registrations), a UA compliant to this specification SHOULD indicate a feature set using the mechanisms described here 🦋 But if the registered URI is an address-of-record, or some other resource that can't be described by one single feature set, it SHOULD NOT include a feature set 🙈 For example, if a user wants to forward calls from sip:user1@example.com to sip:user2@example.org, the registration could look something like this, in part:

REGISTER sip:example.com SIP/2.0
To: sip:user1@example.com
Contact: sip:user2@example.org

In this case the registered contact isn't identifying a UA at all, it's just another address-of-record 💅 So the registered contact would not indicate a feature set.

However, sometimes a UA does want to express feature parameters for an address-of-record 🏠 One example is an AOR that represents a bunch of devices in a home network and routes to a proxy server in the user's home. Since every device in the home is for personal use, the AOR itself can be described with the ;class="personal" feature parameter ✨ A registration that forwards calls to this home AOR could make use of that feature parameter. Generally speaking, a feature parameter can only be associated with an address-of-record if all devices bound to that address-of-record share the exact same set of values for that feature parameter.

Similarly, a UA can sometimes show one characteristic or another, but that characteristic isn't known in advance 🧚 For instance, a UA could be a device that's a phone with an embedded answering machine 📞 The ideal way to treat a device like this is to model it as if it were actually a proxy fronting two devices: a phone (which is never an answering machine), and an answering machine (which is never a phone) 💜 The registration from this device would be constructed as if it were an AOR, following the procedures above. Generally, this means that, unless the characteristic is identical between the logical devices, that characteristic will not be present in any registration generated by the actual device.

The rest of this section assumes that a UA would like to associate a feature set with a contact it's registering 🌸 That feature set gets built and converted into a series of Contact header field parameters, as described in Section 5, and those feature parameters are added to the Contact header field value containing the URI they apply to. The Allow, Accept, Accept-Language and Allow-Events [9] header fields are allowed in REGISTER requests too, and they also indicate capabilities. But their meaning in REGISTER is different: they indicate capabilities that the registrar uses to generate the response. So they're not a substitute or an alternate for the Contact feature parameters, which indicate the capabilities of the UA generally speaking 🎀

The REGISTER request MAY contain a Require header field with the value "pref" if the client wants to be sure that the registrar understands the extensions defined in this specification 🫶 This means the registrar will store the feature parameters and make them available to elements accessing the location service within the domain. Without the Require header field, a registrar that doesn't understand this extension will simply ignore the Contact header field parameters 😌

If a UA registers against multiple separate addresses-of-record, and the contacts registered for each one have different capabilities, a UA MUST use different URIs in each registration 🔥 This lets the UA uniquely determine the feature set that's associated with the request URI of an incoming request.

Here's a fun example: a voicemail server that is a UA supporting audio and video media types and that isn't mobile would construct a feature predicate like this 📼

(& (sip.audio=TRUE)
   (sip.video=TRUE)
   (sip.actor=msg-taker)
   (sip.automata=TRUE)
   (sip.mobility=fixed)
   (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS)
      (sip.methods=ACK) (sip.methods=CANCEL)))

These would be converted into feature parameters and included in the REGISTER request:

REGISTER sip:example.com SIP/2.0
From: sip:user@example.com;tag=asd98
To: sip:user@example.com
Call-ID: hh89as0d-asd88jkk@host.example.com
CSeq: 9987 REGISTER
Max-Forwards: 70
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8
Contact: <sip:user@host.example.com>;audio;video
  ;actor="msg-taker";automata;mobility="fixed"
  ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
Content-Length: 0

Note that a voicemail server is usually an automata and a message taker 🤖

When a UAC refreshes its registration, it MUST include its feature parameters in that refresh if it wants them to stay active 💅 And when a registrar returns a 200 OK response to a REGISTER request, each Contact header field value MUST include all of the feature parameters associated with that URI 💯

7. Indicating Feature Sets in Remote Target URIs 🎀

Target refresh requests and responses are used to establish and modify the remote target URI in a dialog 🦋 The remote target URI is conveyed in the Contact header field. A UAC or UAS MAY add feature parameters to the Contact header field value in target refresh requests and responses to indicate the capabilities of the UA 🌈 To do that, it builds a set of feature parameters according to Section 5, and those are then added as Contact header field parameters in the request or response.

Feature parameters can be included in both initial requests and mid-dialog requests, and they MAY change mid-dialog to signal a change in UA capabilities 🔄

Now here's where it gets a little overlappy 👀 The callee capabilities mechanism overlaps with the Allow, Accept, Accept-Language, and Allow-Events [9] header fields, which can also be used in target refresh requests. Specifically, the Allow header field and the "sip.methods" feature tag indicate the same information. The Accept header field and the "type" feature tag indicate the same information. The Accept-Language header field and the "language" feature tag indicate the same information. The Allow-Events header field and the "sip.events" feature tag indicate the same information. It's possible that other header fields and feature tags defined in the future may also overlap 🔮 So when there's a feature tag that describes a capability that can also be represented with a SIP header field, a UA MUST use the header field to describe the capability. And a UA receiving a message that contains both the header field and the feature tag MUST use the header field, and not the feature tag 🫶

8. OPTIONS Processing 💅

When a UAS compliant to this specification receives an OPTIONS request, it MAY add feature parameters to the Contact header field in the OPTIONS response to indicate the capabilities of the UA ✨ To do that, it builds a set of feature parameters according to Section 5. Those get added as Contact header field parameters in the OPTIONS response. And honestly, if feature parameters were included in the registration generated by that UA, those same parameters SHOULD be used in the OPTIONS response 🧁

The guidelines in Section 7 about the overlap between the callee capabilities feature tags and SIP header fields also apply to generating OPTIONS responses 🤓 In particular, they apply when a Contact header field is describing the UA that generated the OPTIONS response. When a Contact header field in the OPTIONS response identifies a different UA, there's no overlap 🙌

9. Contact Header Field 👑

This specification extends the Contact header field 💖 In particular, it lets the Contact header field parameters include feature-param. A feature-param is a feature parameter that describes a feature of the UA associated with the URI in the Contact header field. You can spot feature parameters because they either belong to the well known set of base feature tags, or they begin with a plus sign ➕

feature-param    =  enc-feature-tag [EQUAL LDQUOT (tag-value-list
                    / string-value ) RDQUOT]
enc-feature-tag  =  base-tags / other-tags
base-tags        =  "audio" / "automata" /
                    "class" / "duplex" / "data" /
                    "control" / "mobility" / "description" /
                    "events" / "priority" / "methods" /
                    "schemes" / "application" / "video" /
                    "language" / "type" / "isfocus" /
                    "actor" / "text" / "extensions"
other-tags      =  "+" ftag-name
ftag-name       =  ALPHA *( ALPHA / DIGIT / "!" / "'" /
                   "." / "-" / "%" )

tag-value-list  =  tag-value *("," tag-value)
tag-value       =  ["!"] (token-nobang / boolean / numeric)
token-nobang    =  1*(alphanum / "-" / "." / "%" / "*"
                   / "_" / "+" / "`" / "'" / "~" )
boolean         =  "TRUE" / "FALSE"
numeric         =  "#" numeric-relation number
numeric-relation  =  ">=" / "<=" / "=" / (number ":")
number          =  [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]
string-value    =  "<" *(qdtext-no-abkt / quoted-pair ) ">"
qdtext-no-abkt  =  LWS / %x21 / %x23-3B / %x3D
                        / %x3F-5B / %x5D-7E / UTF8-NONASCII

Note that the tag-value-list uses an actual comma instead of the COMMA construction, because it appears within a quoted string, where line folding can't take place 🧵

The production for qdtext can be found in RFC 3261 [1] 📚

There are additional constraints on the usage of feature-param that can't be represented in a BNF 🙃 There MUST only be one instance of any feature tag in feature-param. And any numbers present in a feature parameter MUST be representable using an ANSI C double 🔢

The following production updates the one in RFC 3261 [1] for contact-params:

contact-params    =  c-p-q / c-p-expires / feature-param
                     / contact-extension

10. Media Feature Tag Definitions 🎀

Okay so this spec comes with a starter pack of media feature tags 🎁 for use with itself. This section is the IANA registration for them, and they all get filed into the SIP media feature tag tree 🌳. New tags get registered in the IETF or global trees using the process for feature tag registrations [3], or in the SIP tree using the process in Section 12.1 ✨.

Any registered feature tags MAY be used with this spec, bestie 💅. A few existing ones look especially relevant though. There's the language feature tag [6], which can say what language the human or automata behind the UA speaks 🌍, and the type feature tag [7], which can say which MIME types a SIP UA can receive in a SIP message 📬. The audio, video, application, data, and control feature tags in the SIP tree (each one indicating a media type, as defined in RFC 2327 [8]) are a different vibe 🦋. They don't indicate top level MIME types that can be received in SIP requests. They indicate media types that can be used in media streams, so they match up with the types defined in RFC 2327 [8].

If a new SDP media type were ever defined, like "message", a new feature tag registration SHOULD be created for it in the SIP tree 🌸. The name of the feature tag MUST equal sip. concatenated with the name of the media type, unless there's an unlikely naming collision between the new media type and an existing feature tag registration 🙈. That means implementations can safely build caller preferences and callee capabilities for the new media type before it's registered, as long as there's no naming conflict 🧚.

If a new media feature tag is registered with the intent of using it with this specification, the registration is done for the unencoded form of the tag (see Section 5) 💜. So if a new feature tag foo is registered in the IETF tree, the IANA registration is for the tag foo and NOT +foo. Similarly, if a new feature tag sip.gruu is registered in the SIP tree, the IANA registration is for the tag sip.gruu and not +sip.gruu or gruu. As such, all registrations into the SIP tree will have the sip. prefix 👑.

The feature tags in this section are all registered in the SIP media feature tag tree created by Section 12.1 ✨.

10.1. Audio 🎧

Media feature tag name: sip.audio

ASN.1 Identifier: 1.3.6.1.8.4.1

Summary of the media feature indicated by this tag: This tag says the device supports audio as a streaming media type 🔊.

Values appropriate for use with this feature tag: Boolean.

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This tag is most useful in a communications app for describing a device's capabilities, like a phone or PDA 📱.

Examples of typical use: Routing a call to a phone that can support audio 📞.

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔐.

10.2. Application 💾

Media feature tag name: sip.application

ASN.1 Identifier: 1.3.6.1.8.4.2

Summary of the media feature indicated by this tag: This tag says the device supports application as a streaming media type. It's mostly here for completeness 🙃. Since so many MIME types live underneath application, saying you can support applications doesn't tell anyone much 🤷‍♀️.

Values appropriate for use with this feature tag: Boolean.

Examples of typical use: Routing a call to a phone that can support a media control application 🎛️.

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔐.

10.3. Data 📊

Media feature tag name: sip.data

ASN.1 Identifier: 1.3.6.1.8.4.3

Summary of the media feature indicated by this tag: This tag says the device supports data as a streaming media type 💜.

Values appropriate for use with this feature tag: Boolean.

Examples of typical use: Routing a call to a phone that can support a data streaming application 🌊.

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔐.

10.4. Control 🕹️

Media feature tag name: sip.control

ASN.1 Identifier: 1.3.6.1.8.4.4

Summary of the media feature indicated by this tag: This tag says the device supports control as a streaming media type 🎮.

Values appropriate for use with this feature tag: Boolean.

Examples of typical use: Routing a call to a phone that can support a floor control application 🙌.

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔐.

10.5. Video 🎥

Media feature tag name: sip.video

ASN.1 Identifier: 1.3.6.1.8.4.5

Summary of the media feature indicated by this tag: This tag says the device supports video as a streaming media type 📹.

Values appropriate for use with this feature tag: Boolean.

Examples of typical use: Routing a call to a phone that can support video 🍿.

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔐.

10.6. Text 💬

Media feature tag name: sip.text

ASN.1 Identifier: 1.3.6.1.8.4.6

Summary of the media feature indicated by this tag: This tag says the device supports text as a streaming media type ✍️.

Values appropriate for use with this feature tag: Boolean.

Examples of typical use: Routing a call to a phone that can support text 💌.

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔐.

10.7. Automata 🤖

Media feature tag name: sip.automata

ASN.1 Identifier: 1.3.6.1.8.4.7

Summary of the media feature indicated by this tag: The sip.automata tag is a boolean that says whether the UA represents an automata (like a voicemail server, conference server, IVR, or recording device) or a human 🧐.

Values appropriate for use with this feature tag: Boolean. TRUE means the UA represents an automata 🚫🙋‍♀️.

Examples of typical use: Refusing to communicate with an automata when it's known that automated services are unacceptable 🙅‍♀️.

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔐.

10.8. Class 🏷️

Media feature tag name: sip.class

ASN.1 Identifier: 1.3.6.1.8.4.8

Summary of the media feature indicated by this tag: This tag says what setting a communications device is used in, business or personal 💼🏡.

Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:

business: The device is used for business communications 💼.
personal: The device is used for personal communications 💖.

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This tag is most useful in a communications app, for describing a device's capabilities, like a phone or PDA 📱.

Examples of typical use: Choosing between a business phone and a home phone ☎️.

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔐.

10.9. Duplex 🔁

Media feature tag name: sip.duplex

ASN.1 Identifier: 1.3.6.1.8.4.9

Summary of the media feature indicated by this tag: The sip.duplex tag says whether a communications device can send and receive media at the same time (full), take turns sending and receiving (half), only receive (receive-only), or only send (send-only) 🌈.

Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:

full: The device can send and receive media simultaneously 🙌.
half: The device can alternate between sending and receiving media 🔄.
receive-only: The device can only receive media 👂.
send-only: The device can only send media 📣.

Examples of typical use: Choosing to communicate with a broadcast server, instead of a regular phone, when calling to hear an announcement 📢.

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔐.

10.10. Mobility 📱✨

Media feature tag name: sip.mobility 💖

ASN.1 Identifier: 1.3.6.1.8.4.10

The vibe: This tag tells you whether a device is fixed (it's tied to a fixed point of contact with the network) or mobile (it isn't tied to one). Heads up, bestie: by this definition, cordless phones count as fixed, not mobile 🙈

Values: Token with an equality relationship. Typical values:

fixed: The device is stationary.
mobile: The device can move around with the user.

Where it's used: This one is most useful in a communications application for describing the capabilities of a device, like a phone or PDA 📞

Example: Choosing to communicate with a wireless phone instead of a desktop phone 🧚

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔒

10.11. Description 🎀

Media feature tag name: sip.description

ASN.1 Identifier: 1.3.6.1.8.4.11

The vibe: sip.description gives you a textual description of the device. Very "about me" section energy 💅

Values: String with an equality relationship.

Where it's used: Mostly in a communications application for describing the capabilities of a device, like a phone or PDA 📱

Example: Indicating that a device is of a certain make and model 🌸

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔒

10.12. Event Packages 🔔

Media feature tag name: sip.events

ASN.1 Identifier: 1.3.6.1.8.4.12

The vibe: Notice the plural 👀 Each value of sip.events is a SIP event package [9] that a SIP UA supports. The values are the event package names that each event package registers. Iconic behaviour from the list-keeping department ✨

Values: Token with an equality relationship. The values come from the IANA SIP Event types namespace registry 📋

Where it's used: Mostly in a communications application for describing the capabilities of a device, like a phone or PDA 📞

Example: Choosing to communicate with a server that supports the message waiting event package, like a voicemail server [12] 📬

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔒

10.13. Priority 🚨

Media feature tag name: sip.priority

ASN.1 Identifier: 1.3.6.1.8.4.13

The vibe: sip.priority says which call priorities the device is willing to handle. A value of X means the device will take requests with priority X and higher 📈 It does not mean a phone has to reject lower-priority calls. Whether to take those is a matter of local policy, as always 🫶

Values: An integer. Each integral value matches one of the possible values of the Priority header field from SIP [1]. The mapping:

non-urgent: Integral value of 10. The device supports non-urgent calls.
normal: Integral value of 20. The device supports normal calls.
urgent: Integral value of 30. The device supports urgent calls.
emergency: Integral value of 40. The device supports calls in the case of an emergency situation. 🆘

Where it's used: Mostly in a communications application for describing the capabilities of a device, like a phone or PDA 📱

Example: Choosing to communicate with the emergency cell phone of a user 🚑

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔒

10.14. Methods 🧩

Media feature tag name: sip.methods

ASN.1 Identifier: 1.3.6.1.8.4.14

The vibe: Again, plural! Each value of sip.methods is a SIP method that this UA supports. Here, "supported" means the UA can receive requests with that method. It's the same vibe as the Allow header field 🦋

Values: Token with an equality relationship. Values come from the Methods table in the IANA SIP parameters registry 📒

Where it's used: Mostly in a communications application for describing the capabilities of a device, like a phone or PDA 📞

Example: Choosing to communicate with a presence application on a PC, instead of a PC phone application 💻

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔒

10.15. Extensions 🧃

Media feature tag name: sip.extensions

ASN.1 Identifier: 1.3.6.1.8.4.15

The vibe: Each value of sip.extensions is a SIP extension that the UA understands. Each one is defined by an option-tag registered with IANA 🗂️ In this context, "understood" means that the option tag would show up in a Supported header field in a request. Very "I can do that too" energy 💜

Values: Token with an equality relationship. Values come from the option tags table in the IANA SIP parameters registry.

Where it's used: Mostly in a communications application for describing the capabilities of a device, like a phone or PDA 📱

Example: Choosing to communicate with a phone that supports quality of service preconditions instead of one that does not 📶

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔒

10.16. Schemes 🌐

Media feature tag name: sip.schemes

ASN.1 Identifier: 1.3.6.1.8.4.16

The vibe: Each value of sip.schemes (plural, as always 💅) is a URI scheme [10] that a UA supports. "Supported" means, for example, that the UA would know how to handle a URI of that scheme in the Contact header field of a redirect response 🔁

Values: Token with an equality relationship. Values come from the IANA URI scheme registry 🗃️

Where it's used: Mostly in a communications application for describing the capabilities of a device, like a phone or PDA 📞

Example: Choosing to get redirected to a phone number when a called party is busy, rather than a web page 📵

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔒

10.17. Actor 🎭

Media feature tag name: sip.actor

ASN.1 Identifier: 1.3.6.1.8.4.17

The vibe: This tag tells you what kind of entity is available at this URI. Main character energy 👑

Values: Token with an equality relationship. These values are defined:

principal: The device provides communication with the principal associated with the device. Often this is a specific human being, but it can be an automata (for example, when calling a voice portal) 🧑
attendant: The device provides communication with an automaton or person that acts as an intermediary in contacting the principal associated with the device, or a substitute 🤖
msg-taker: The device provides communication with an automaton or person that takes messages and delivers them to the principal 📝
information: The device provides communication with an automaton or person that provides information about the principal ℹ️

Where it's used: Mostly in a communications application for describing the capabilities of a device, like a phone or PDA 📱

Example: Requesting that a call not be routed to voicemail 📵✨

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔒

10.18. Is Focus 🎙️

Media feature tag name: sip.isfocus

ASN.1 Identifier: 1.3.6.1.8.4.18

The vibe: This tag says the UA is a conference server, also known as a focus. It will mix together the media for all calls to the same URI [13] 🎶 Mixing-desk girlie 🎧

Values: Boolean.

Where it's used: Mostly in a communications application for describing the capabilities of a device, like a phone or PDA 📞

Example: Telling a UA that the server it has connected to is a conference server 🧑‍🤝‍🧑

Related standards or documents: RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840 🔒

11. Security Considerations 🔐

11.1. Considerations for Media Feature Tags 🔒✨

okay bestie, security time 🫶 this part is about the media feature tags themselves, and not only the ones in this spec. 🔒

the tags from Section 10 can reveal a lot about a user or the user agent they describe 👀 some are capability info about the agent, like which media types it can handle, which SIP methods it supports, and which SIP extensions it knows. honestly, that kind of info could be used for industrial espionage 🕵️‍♀️ so protecting it can matter a lot.

the mobility, priority, and isfocus attributes are even more sensitive 😭 they show how a user agent is actually being used, which means they reveal user preferences and how someone wants their calls handled. and feature tags like languages can tell you about the user themself 🌸 so, applications that use these tags SHOULD provide a way to keep them confidential 🔐

the tags can also change how apps behave 💅 the SIP caller preferences extension [11] lets call routing decisions depend on these values, so if an attacker can change them, they could mess with how the app acts 💀 that's why apps using these tags SHOULD provide a way to keep them intact (integrity) 🧱 and since feature tags should only be trusted when they come from the user or user agent they describe, the ways of carrying tags SHOULD give a way to guarantee authenticity 🪪 literally the main character of security 👑

11.2. Considerations for Registrations 📝

so the rule from Section 11.1 applies here too: when media feature tags travel in a registration, you need authenticity, confidentiality, and integrity 🔐 to get that, a registration that carries capability info SHOULD be addressed to a SIPS URI 🎀 like, the Request URI would be sips:example.com when you're registering in the example.com domain.

on top of that, the registrar SHOULD challenge the UA with digest over TLS to check its authenticity 🫶 TLS and digest together give you integrity, confidentiality, and authenticity, which is exactly what we need ✨

the Contact in the registration doesn't need a sips URI of its own, though 🙈 the feature tags aren't sent in incoming requests to the UA, so it's not needed.

11.3. Considerations for OPTIONS Responses 🧚

when a response to an OPTIONS request includes capability info, the UA SHOULD check with the user (through a UI or earlier configuration) whether that info can be shared with the requester 🙋‍♀️ if the requester's identity can't be cryptographically verified (using digest or the SIP identity enhancements [15]), the user SHOULD also be told about it and get to choose whether to share anyway 🤨

if the user does want to share, wants it kept confidential, and the request didn't come in over SIPS, the UAS SHOULD redirect the request to a sips URI 🔁 this makes the UAC send the OPTIONS request over SIPS instead, so the responses are protected on secure connections 🔒✨

and S/MIME MAY be used in the OPTIONS response 💜 when it is, the capability info lives only inside the secured S/MIME body and not in the response's header fields 🎀

11.4. Considerations for Dialog Initiating Messages 🦋

when a UAS sends a response that starts a dialog and wants to put capability info in the Contact header field, the same stuff from Section 11.3 applies 💅

when a UAC sends a request that starts a dialog, it SHOULD get permission from the user (through a UI or earlier configuration) before putting capability info in the Contact header field of that request 🙏 confidentiality and integrity SHOULD be handled with SIPS 🔐 and S/MIME MAY be used too 🫶

12. IANA Considerations 🌷

there are a bunch of IANA considerations for this spec, so let's go 📋

12.1. SIP Media Feature Tag Registration Tree 🌳

this spec creates a brand new media feature tag registration tree, following the guidelines in Section 3.1.4 of RFC 2506 [3] 🪴 it's called the "SIP Media Feature Tag Registration Tree", and its prefix is sip.. it's for media feature tags that work with the Session Initiation Protocol and only have meaning inside that usage ✨

entries get added through IETF consensus, as defined in RFC 2434 [18] 🗳️ that means you need an RFC that contains the registration. the info needed for a registration is the same as for the IETF tree, so specs adding entries SHOULD use the template in Section 3.4 of RFC 2506 📑 and every media feature tag in the SIP tree will have a name starting with sip. 🏷️ no leading + is used in any of the media feature tag trees, btw 🙅‍♀️

12.2. Media Feature Tags 🎀

this spec registers a bunch of new media feature tags following RFC 2506 [3] procedures 💖 they all go in the new SIP tree, and here they are:

sip.audio: the registration info is in Section 10.1.
sip.application: the registration info is in Section 10.2.
sip.data: the registration info is in Section 10.3.
sip.control: the registration info is in Section 10.4.
sip.video: the registration info is in Section 10.5.
sip.text: the registration info is in Section 10.6.
sip.automata: the registration info is in Section 10.7.
sip.class: the registration info is in Section 10.8.
sip.duplex: the registration info is in Section 10.9.
sip.mobility: the registration info is in Section 10.10.
sip.description: the registration info is in Section 10.11.
sip.events: the registration info is in Section 10.12.
sip.priority: the registration info is in Section 10.13.
sip.methods: the registration info is in Section 10.14.
sip.extensions: the registration info is in Section 10.15.
sip.schemes: the registration info is in Section 10.16.
sip.actor: the registration info is in Section 10.17.
sip.isfocus: the registration info is in Section 10.18.

12.3. SIP Option Tag 🏷️

this spec registers one SIP option tag, pref ✨ the required info for it, as laid out in RFC 3261 [1], is:

Name: pref

Description: This option tag is used in a Require header field of
   a registration to ensure that the registrar supports the caller
   preferences extensions.

13. Acknowledgments 💐

the first set of media feature tags in this spec was influenced by Scott Petrack's CMA design 🌈 big thanks to Jonathan Lennox, Bob Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, and John Hearty for the helpful comments 🫶 Graham Klyne helped out with how RFC 2533 is used 🧠 and thanks to Allison Mankin for the comments and support, and to Ted Hardie for guidance on using the media feature tags 👑

14. References 📚

14.1. Normative References 🔗

[1] 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.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[4] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[5] Klyne, G., "Corrections to "A Syntax for Describing Media Feature Sets"", RFC 2738, December 1999.
[6] Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, November 2000.
[7] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000.
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[9] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

14.2. Informative References 🦋

[11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[12] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[13] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, May 2003.
[14] Howes, T. and M. Smith, "LDAP: String Representation of Search Filters", Work in Progress, March 2003.
[15] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[16] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[17] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Appendix A. Overview of RFC 2533 ✨

okay so this section is a quick tour of RFC 2533 and the related specs that make up the content negotiation framework 💅 it's just a tutorial, not normative behavior 🫶 if the tutorial ever disagrees with the actual normative text in RFC 2533, RFC 2533 wins, no debate 👑

the big idea is the feature set 🦋 a feature set is info about an entity (here, a UA) that describes all the stuff it can handle. picture it as a region in an N-dimensional space 🌈 every dimension is a different media feature, identified by a media feature tag. one axis could be languages, another could be methods, another could be MIME types. like, it's giving graph paper but make it multiverse 🧚

a feature collection is one single point in that space 📍 it's one particular rendering or instance of the UA. so a "rendering" is basically an instant where the UA is running in one specific mode. for example, handling the INVITE method, carrying the application/sdp MIME type, going to a user who speaks English 🎀 that whole combo is one point.

so a feature set is a set of feature collections 💖 another way to say it: a feature set is a region of N-dimensional feature-space, and that region is made of all the points (feature collections) inside it. if a feature collection lives inside the space, the device with that feature set can handle that rendering ✨

how do you even write down a region like that? there are lots of ways to describe an N-dimensional space 😭 one option is math functions that trace the edges, but that's way too complicated to be useful, so no thank you 🙈 RFC 2533 goes with a feature set predicate instead. a predicate defines a relation over the N-dimensional space. its input is any point in the space (a feature collection), and it comes back true for every point inside the region 🍓

RFC 2533 writes these N-dimensional boolean functions using a syntax borrowed from LDAP [14] 💜 it's prolog-style and honestly pretty self-explanatory once you see it. the basic unit is a filter, which is a boolean expression wrapped in round brackets. a filter can be complex (conjunctions and disjunctions of other filters) or simple. a simple filter is just one comparison on a single media feature tag 🌸

here's an example predicate:

(& (foo=A)
   (bar=B)
   (| (baz=C) (& (baz=D) (bif=E))))

this defines a function over four media features: foo, bar, baz, and bif. any point where foo is A, bar is B, baz is either C or D, and bif is E is inside the feature set this predicate describes 🔥

heads up though: the predicate doesn't say anything about how many dimensions the space has. it works on a space with any number of dimensions, but only the ones named foo, bar, baz, and bif actually matter 🧐 so other features don't affect the answer. the feature collection {foo=A,bar=B,baz=C,bop=F} is inside the feature set from the predicate above, even though "bop" never shows up in it 👀 that makes feature set predicates inclusive by default. a feature collection is considered present unless the boolean predicate explicitly rules it out. this was a deliberate design choice in RFC 2533 🫶

RFC 2533 also covers matching a preference with a capability set 💅 both get represented as feature sets. a preference is a feature set, a list of feature collections where any one of them would meet the sender's needs. a capability is also a feature set, describing the feature collections the recipient can support 🎀 there's a match when the two spaces overlap. if they overlap, at least one feature collection is in both sets, which means the recipient supports a modality or rendering the sender wants. iconic, honestly 🦋

which leads straight to the definition of a match: two feature sets match if at least one feature collection is present in both of them ✨

computing a match for two general feature set predicates is not easy 😭 RFC 2533 has an algorithm for it in Section 5, which expands an arbitrary expression into disjunctive normal form. BUT the feature set predicates used by this specification are more constrained 💖 they're always in conjunctive normal form, with each term in the conjunction describing values for a different media feature. that makes matching way easier 🌈 you compute it separately for each media feature, and then the feature sets overlap if the media features specified in both sets overlap. checking the overlap for a single media feature is very straightforward: you just check whether two finite sets overlap 💜

Authors' Addresses

the authors, in case you want to reach out 🌸

Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ  07054
US

Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI:   http://www.jdrosen.net

Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY  10027
US

EMail: schulzrinne@cs.columbia.edu
URI:   http://www.cs.columbia.edu/~hgs

Paul Kyzivat
Cisco Systems
1414 Massachusetts Avenue
BXB500 C2-2
Boxboro, MA  01719
US

EMail: pkyzivat@cisco.com

Full Copyright Statement

the legal bit, but make it cute 🧾

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 in it 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 doesn't take a side on whether any IPR claims about this tech are valid or how far they reach, and whether licenses are available or not. it also doesn't say it has done any independent work to find those rights 🫤 info about how rights work for RFC documents is in BCP 78 and BCP 79.

copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of trying to get a general license or permission for implementers or users, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. 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 🌈 thank you, legends 🫶

📦 where this page comes from

ietf: rfc3840 2004-08
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms