idnits 2.17.1 draft-ietf-sip-callerprefs-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1218 has weird spacing: '... where proxy...' == Line 1220 has weird spacing: '... ar o ...' == Line 1221 has weird spacing: '... ar o ...' == Line 1222 has weird spacing: '... ar o ...' == Line 1224 has weird spacing: '...Contact and ...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2003) is 7719 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (ref. '7') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2976 (ref. '8') (Obsoleted by RFC 6086) ** Obsolete normative reference: RFC 2327 (ref. '13') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2396 (ref. '18') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2806 (ref. '19') (Obsoleted by RFC 3966) ** Obsolete normative reference: RFC 2616 (ref. '20') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '32') (Obsoleted by RFC 9110) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 H. Schulzrinne 6 Columbia U. 7 P. Kyzivat 8 Cisco 9 draft-ietf-sip-callerprefs-08.txt 10 March 2, 2003 11 Expires: September 2003 13 Caller Preferences and Callee Capabilities for the Session 14 Initiation Protocol (SIP) 16 STATUS OF THIS MEMO 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 To view the list Internet-Draft Shadow Directories, see 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes a set of extensions to the Session Initiation 40 Protocol (SIP) which allow a caller to express preferences about 41 request handling in servers. These preferences include the ability to 42 select which Uniform Resource Identifiers (URI) a request gets routed 43 to, and to specify certain request handling directives in proxies and 44 redirect servers. It does so by defining three new request header 45 fields, Accept-Contact, Reject-Contact, and Request-Disposition, 46 which specify the caller's preferences. The extension also defines 47 new parameters for the Contact header field that describe the 48 capabilities and characteristics of a User Agent (UA). 50 Table of Contents 52 1 Introduction ........................................ 5 53 2 Terminology ......................................... 6 54 3 Definitions ......................................... 6 55 4 Overview of Operation ............................... 8 56 5 Usage of the Content Negotiation Framework .......... 9 57 6 UA Behavior ......................................... 11 58 6.1 Expressing Capabilities in a Registration ........... 11 59 6.2 Expressing Preferences in a Request ................. 14 60 6.2.1 Request Handling Preferences ........................ 15 61 6.2.2 Feature Set Preferences ............................. 15 62 6.3 Indicating Feature Sets in Remote Target URIs ....... 16 63 6.4 Processing Request Handling and Feature Set 64 Preferences .................................................... 17 65 6.5 OPTIONS Processing .................................. 17 66 7 Proxy Behavior ...................................... 18 67 7.1 Request-Disposition Processing ...................... 18 68 7.2 Preference and Capability Matching .................. 18 69 7.2.1 Extracting Explicit Preferences ..................... 18 70 7.2.2 Extracting Implicit Preferences ..................... 19 71 7.2.2.1 Methods ............................................. 19 72 7.2.2.2 Event Packages ...................................... 20 73 7.3 Constructing Contact Predicates ..................... 20 74 7.4 Matching ............................................ 21 75 7.4.1 Example ............................................. 27 76 8 Header Field Definitions ............................ 29 77 8.1 Request Disposition ................................. 29 78 8.2 Accept-Contact and Reject-Contact Header Fields ..... 31 79 8.3 Contact Header Field ................................ 31 80 9 Media Feature Tag Definitions ....................... 32 81 9.1 Attendant ........................................... 32 82 9.2 Audio ............................................... 33 83 9.3 Application ......................................... 33 84 9.4 Data ................................................ 34 85 9.5 Control ............................................. 35 86 9.6 Automata ............................................ 35 87 9.7 Class ............................................... 36 88 9.8 Duplex .............................................. 36 89 9.9 Mobility ............................................ 37 90 9.10 Description ......................................... 38 91 9.11 Event Packages ...................................... 38 92 9.12 Priority ............................................ 39 93 9.13 Methods ............................................. 40 94 9.14 SIP Extensions ...................................... 41 95 9.15 Schemes ............................................. 42 96 9.16 Video ............................................... 43 97 9.17 Message Server ...................................... 43 98 9.18 Is Focus ............................................ 44 99 9.19 URI User ............................................ 44 100 9.20 URI Domain .......................................... 45 101 10 Augmented BNF ....................................... 45 102 11 Mapping Feature Parameters and Feature Set 103 Predicates ..................................................... 47 104 12 Security Considerations ............................. 50 105 13 IANA Considerations ................................. 50 106 13.1 Media Feature Tags .................................. 50 107 13.2 SIP Header Fields ................................... 51 108 13.3 SIP Option Tags ..................................... 51 109 14 Acknowledgments ..................................... 52 110 15 Author's Addresses .................................. 52 111 16 Normative References ................................ 52 112 17 Informative References .............................. 54 113 A Overview of RFC 2533 ................................ 55 115 1 Introduction 117 When a Session Initiation Protocol (SIP) [1] server receives a 118 request, there are a number of decisions it can make regarding 119 processing of the request. These include: 121 o whether to proxy or redirect the request 123 o which URIs to proxy or redirect to 125 o whether to fork or not 127 o whether to search recursively or not 129 o whether to search in parallel or sequentially 131 The server can base these decisions on any local policy. This policy 132 can be statically configured, or can be based on programmatic 133 execution or database access. 135 However, the administrator of the server is the not the only entity 136 with an interest in request processing. There are at least three 137 parties which have an interest: (1) the administrator of the server, 138 (2) the user that sent the request, and (3) the user to whom the 139 request is directed. The directives of the administrator are embedded 140 in the policy of the server. The preferences of the user to whom the 141 request is directed (referred to as the callee, even though the 142 request may not be INVITE) can be expressed most easily through a 143 script written in some type of scripting language, such as the Call 144 Processing Language (CPL) [22]. However, no mechanism exists to 145 incorporate the preferences of the user that sent the request (also 146 referred to as the caller, even though the request may not be 147 INVITE). For example, the caller might want to speak to a specific 148 user, but want to reach them only at work, because the call is a 149 business call. As another example, the caller might want to reach a 150 user, but not their voicemail, since it is important that the caller 151 talk to the called party. In both of these examples, the caller's 152 preference amounts to having a proxy make a particular routing choice 153 based on the preferences of the caller. 155 This extension allows the caller to have these preferences met. It 156 does so by specifying mechanisms by which a caller can provide 157 preferences on processing of a request. There are two types of 158 preferences. One of them, called request handling preferences, are 159 encapsulated in the Request-Disposition header field. They provide 160 specific request handling directives for a server. The other, called 161 feature preferences, are present in the Accept-Contact and Reject- 162 Contact header fields. They allow the caller to provide a feature set 164 [2] that expresses its preferences on the characteristics of the UA 165 that is to be reached. These are matched with a feature set carried 166 in the Contact header field of a REGISTER request, which describes 167 the capabilities of the UA represented by the Contact URI. The 168 extension is very general purpose, and not tied to a particular 169 service. Rather, it is a tool that can be used in the development of 170 many services. 172 Indeed, the feature sets uploaded to the server in REGISTER requests 173 can be used for a variety of purposes, not just meeting caller 174 preferences. Applications can use this information to tailor 175 information sent to a user as part of an instant message, for example 176 [3]. 178 One example of the a service enabled by caller preferences is a "one 179 number" service. A user can have a single identity (their SIP URI) 180 for all of their devices - their cell phone, PDA, work phone, home 181 phone, and so on. If the caller wants to reach the user at their 182 business phone, they simply select "business phone" from a pull-down 183 menu of options when calling that URI. Users would no longer need to 184 maintain and distribute separate identities for each device. 186 2 Terminology 188 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 189 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 190 and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and 191 indicate requirement levels for compliant SIP implementations. 193 3 Definitions 195 Caller: Within the context of this specification, a caller 196 refers to the user on whose behalf a UAC is operating. It 197 is not limited to a user who's UAC sends the INVITE method. 199 Feature: As defined in RFC 2703 [23], a piece of information 200 about the media handling properties of a message passing 201 system component or of a data resource. For example, the 202 SIP methods supported by a UA represent a feature. 204 Feature Tag: As defined in RFC 2703 [23], a feature tag is a 205 name that identifies a feature. An example is "methods". 207 Media Feature: As defined in RFC 2703, [23], a media feature is 208 information that indicates facilities assumed to be 209 available for the message content to be properly rendered 210 or otherwise presented. Media features are not intended to 211 include information that affects message transmission. 213 In the context of this specification, a media feature is 214 information that indicates facilities for handling SIP 215 requests, rather than specifically for content. In that 216 sense, it is used synonymously with feature. 218 Feature Collection: As defined in RFC 2533 [2], a feature 219 collection is a collection of different media features and 220 associated values. This might be viewed as describing a 221 specific rendering of a specific instance of a document or 222 resource by a specific recipient. 224 Feature Set: As defined in RFC 2703 [23], a feature set is 225 Information about a sender, recipient or other participant 226 in a message transfer which describes the set of features 227 that it can handle. Where a 'feature' describes a single 228 identified attribute of a resource, a 'feature set' 229 describes full set of possible attributes. 231 Feature Preferences: Caller preferences that described desired 232 properties of a UA that the request is to be routed to. 233 Feature preferences can be made explicitly with the 234 Accept-Contact and Reject-Contact header fields. 236 Request Handling Preferences: Caller preferences that describe 237 desired request treatment at a server. These preferences 238 are carried in the Request-Disposition header field. 240 Feature Parameters: A set of SIP header field parameters that 241 can appear in the Contact, Accept-Contact and Reject- 242 Contact header fields. The feature parameters represent an 243 encoding of a feature set. Each set of feature parameters 244 maps to a feature set predicate. 246 Capability: As defined in RFC 2703 [23], a capability is an 247 attribute of a sender or receiver (often the receiver) 248 which indicates an ability to generate or process a 249 particular type of message content. 251 Target Set: A target set is a set of candidate URI that a proxy 252 or redirect server can send or redirect a request to. 253 Frequently, target sets are obtained from a registration, 254 but they need not be. 256 Explicit Preference: A caller preference indicated explicitly in 257 the Accept-Contact or Reject-Contact header fields. 259 Implicit Preference: A caller preference that is implied through 260 the presence of other aspects of a request. For example, if 261 the request method is INVITE, it represents an implicit 262 caller preference to route the request to a UA that 263 supports the INVITE method. 265 Filter: A single expression in a feature set predicate. 267 Simple Filter: An expression in a feature predicate which is a 268 comparison (equality or inequality) of a feature tag 269 against a feature value. 271 Disjunction: A boolean OR operation across some number of terms. 273 Conjunction: A boolean AND operation across some number of 274 terms. 276 Predicate: A boolean expression. 278 Feature Set Predicate: From RFC 2533 [2], a feature set 279 predicate is a function of an arbitrary feature collection 280 value which returns a Boolean result. A TRUE result is 281 taken to mean that the corresponding feature collection 282 belongs to some set of media feature handling capabilities 283 defined by this predicate. 285 Contact Predicate: The feature set predicate associated with a 286 URI registered in the Contact header field of a REGISTER 287 request. The contact predicate is derived from the feature 288 parameters in the Contact header field. 290 4 Overview of Operation 292 This extension defines a set of additional parameters to the Contact 293 header field, called feature parameters. Each parameter name is an 294 encoded feature tag, as defined in RFC 2703 [23], that defines a 295 capability for the UA associated with the Contact header field value. 296 For example, there is a parameter for the SIP methods supported by 297 the UA. Each feature parameter has a value; that value is the set of 298 feature values for that feature tag. Put together, all of the feature 299 parameters specify a feature set that is supported by the UA 300 associated with that Contact header field value. 302 When a UA registers, it places these parameters in the Contact header 303 field value to provide a feature set for a URI it is registering. The 304 feature parameters are also mirrored in the Contact header field in a 305 REGISTER response. The proxy can use this feature set to route 306 requests based on caller preferences. Furthermore, Contact header 307 fields in requests and responses that establish a dialog can contain 308 these parameters. That allows a UA in a dialog to indicate its 309 feature set to its peer. For example, by including the "msgserver" 310 feature tag with value "TRUE" in the 200 OK to an INVITE, the UAS can 311 indicate to the UAC that it is a voicemail server. This information 312 is useful for user interfaces, as well as automated call handling. 314 When a caller sends a request, it can optionally include new header 315 fields which request certain handling at a server. These preferences 316 fall into two categories. The first category, called request handling 317 preferences, are carried in the Request-Disposition header field. 318 They describe specific behavior that is desired at a server. Request 319 handling preferences include whether the caller wishes the server to 320 proxy or redirect, and whether sequential or parallel search is 321 desired. These preferences can be applied at every proxy or redirect 322 server on the call signaling path. 324 The second category of preferences, called feature preferences, are 325 carried in the Accept-Contact and Reject-Contact header fields. These 326 header fields also contain feature sets, represented by the same 327 feature parameters that are used in the Contact header field. Here, 328 the feature parameters represent the caller's preferences. The 329 Accept-Contact header field contains feature sets that describe UAs 330 that the caller would like to reach. The Reject-Contact header field 331 contains feature sets which, if matched by a UA, imply that the 332 request should not be routed to that UA. 334 Proxies use the information in the Accept-Contact and Reject-Contact 335 header fields to select amongst contacts in their target set. When 336 neither of those header fields are present, the proxy computes 337 implicit preferences from the request. These are caller preferences 338 that are not explicitly placed into the request, but can be inferred 339 from the presence of other message components. As an example, if the 340 request method is INVITE, this is an implicit preference to route the 341 call to a UA that supports the INVITE method. 343 Both request handling and feature preferences can appear in any 344 request, not just INVITE. However, they are only useful in requests 345 where proxies need to determine a request target. If the domain in 346 the request URI is not owned by any proxies along the request path, 347 those proxies will never access a location service, and therefore, 348 never have the opportunity to apply the caller preferences. This 349 makes sense; typically, the request URI will identify a UAS for mid- 350 dialog requests. In those cases, the routing decisions were already 351 made on the initial request, and it makes no sense to redo them for 352 subsequent requests in the dialog. 354 5 Usage of the Content Negotiation Framework 356 This specification makes heavy use of the terminology and concepts in 357 the content negotiation work carried out within the IETF, and 358 documented in several RFCs. The ones relevant to this specification 359 are RFC 2506 [5] which provides a template for registering media 360 feature tags, RFC 2533 [2] which presents a syntax and matching 361 algorithm for media feature sets, RFC 2738 [6], which provides a 362 minor update to RFC 2533, and RFC 2703 [23] which provides a general 363 framework for content negotiation. 365 In case the reader does not have the time to read those 366 specifications, Appendix A provides a brief overview of the concepts 367 and terminology in those documents that is critical for understanding 368 this specification. 370 Since the content negotiation work was primarily meant to apply to 371 documents or other resources with a set of possible renderings, it is 372 not immediately apparent how it is used to model the SIP entities at 373 hand. The goal of this specification is to allow a UA to express its 374 feature set, and for a caller to express a feature set that describes 375 properties of a desirable (or undesirable) UA. Therefore, we are 376 using feature sets to describe SIP user agents. 378 A feature set is composed of a set of feature collections, each of 379 which represents a specific rendering supported by the entity 380 described by the feature set. In the context of a SIP user agent, a 381 feature collection represents an instantaneous modality. That is, if 382 you look at the run time processing of a SIP UA, and take a snapshot 383 in time, the feature collection describes what it is doing at that 384 very instant. 386 This model is important, since it provides guidance on how to 387 determine whether something is a value for a particular feature tag, 388 or a feature tag by itself. If two properties can be exhibited by a 389 UA simultaneously, so that both are present in an instantaneous 390 modality, they need to be represented by separate media feature tags. 391 For example, a UA may be able to support some number of media types - 392 audio, video, and control. Should each of these be different values 393 for a single "media-types" feature tag, or should each of them be a 394 separate boolean feature tag? The model provides the answer. Since, 395 at any instant of time, a UA could be handling both audio and video, 396 they need to be separate media feature tags. However, the SIP methods 397 supported by a UA can each be represented as different values for the 398 same media feature tag (the "methods" tag), because fundamentally, a 399 UA processes a single request at a time. It may be multi-threading, 400 so that it appears that this is not so, but at a purely functional 401 level, it is true. 403 Clearly, there are weaknesses in this model, but it serves as a 404 useful guideline for applying the concepts of RFC 2533 to the problem 405 at hand. 407 6 UA Behavior 409 UA behavior covers five separate cases. The first is registration, 410 where a UA can declare its capabilities. The second is expression of 411 preferences in a request, where a UA can tell a proxy how it wants 412 the request to be processed and routed. The third is expressing of 413 capabilities, through a feature set, in the Contact header field of a 414 target refresh request or response. The fourth is UAS processing of 415 the request handling and feature preferences. The fifth is UAS 416 processing of an OPTIONS request. 418 6.1 Expressing Capabilities in a Registration 420 When a UA registers, it can choose to indicate a feature set 421 associated with a registered contact. Whether or not a UA does so 422 depends on what the registered URI represents. If the registered URI 423 represents a UA instance (the common case in registrations), a UA 424 compliant to this specification SHOULD indicate a feature set using 425 the mechanisms described here. If, however, the registered URI 426 represents an address-of-record, or some other resource that is not 427 representable by a single feature set, it SHOULD NOT include a 428 feature set. As an example, if a user wishes to forward calls from 429 sip:user1@example.com to sip:user2@example.org, it could generate a 430 registration that looks like, in part: 432 REGISTER sip:example.com SIP/2.0 433 To: sip:user1@example.com 434 Contact: sip:user2@example.org 436 In this case, the registered contact is not identifying a UA, but 437 rather, another address-of-record. In such a case, the registered 438 contact would not indicate a feature set. 440 If a UA does not include feature parameters for a contact, that 441 contact will be immune from the caller preference processing. 442 Therefore, if a registering client does not want caller preferences 443 applied to a contact, it omits all feature parameters. Addresses-of- 444 record in particular often need to be immune from caller preferences 445 processing. If they were not, such a URI might be eliminated from 446 consideration, even though a downstream UA satisfies the desired 447 constraints. 449 However, in some cases a UA may wish to express feature parameters 450 for an address-of-record. One example is an AOR which represents a 451 mutliplicity of devices in a home network, and routes to a proxy 452 server in the user's home. Since all devices in the home are for 453 personal use, the AOR itself can be described with the 454 "class=personal" feature parameter. A registration that forwards 455 calls to this home AOR could make use of that feature parameter. 456 Generally speaking, a feature parameter can only be associated with 457 an address-of-record if all devices bound to that address-of-record 458 share the exact same set of values for that feature parameter. 460 The remainder of this section assumes that a UA would like to 461 associate a feature set with a contact that it is registering. To do 462 that, it constructs a feature predicate for that contact. In the 463 text that follows, this process is described in terms of RFC 2533 [2] 464 (and its minor update, [6]) syntax and constructs, followed by a 465 conversion to the syntax used in this specification. However, this 466 represents a logical flow of processing. There is no requirement that 467 an implementation actually use RFC 2533 syntax as an intermediate 468 step. 470 The feature predicate constructed by a UA MUST be an AND of terms 471 (called a conjunction). Each term is either an OR of simple filters 472 (called a disjunction), or a single simple filter. In the case of an 473 OR of simple filters, each filter MUST indicate feature values for 474 the same feature tag (i.e., the disjunction represents a set of 475 values for a particular feature tag), and each element of the 476 conjunction MUST be for a different feature tag. Each filter can be 477 an equality, the negation of an equality, or in the case of numeric 478 feature tags, an inequality, range, or negation of an inequality or 479 range. This feature predicate is then converted to a list of feature 480 parameters using the procedure specified in Section 11. Those feature 481 parameters are added to the the Contact header field value containing 482 the URI that the parameters apply to. 484 A UA MAY use any feature tags that are registered through IANA in the 485 IETF or global trees [5]; this document registers several that are 486 appropriate for SIP. It is also permissible to use the URI tree [5] 487 for expressing vendor-specific feature tags. Feature tags in any 488 other trees created through IANA MAY also be used. 490 A UA SHOULD include the "uri-user" and "uri-domain" feature tag in 491 its feature parameters. The value of those tags SHOULD be equal to 492 the user and domain part of the registered URI, respectively. Setting 493 them differently is likely to result in odd behavior, and should only 494 be done if some unforseen service neccesitates it. Note that the 495 "uri-user" feature tag is a quoted string (implying case sensitive 496 matching), and the "uri-domain" feature tag is a token, implying case 497 insensitive matching. 499 Note that the "schemes" feature tag is not a peer of the "uri-user" 500 and "uri-domain" feature tags. That is, it does not indicate the 501 scheme of the registered URI. Rather, it indicates schemes that a UA 502 is capable of sending requests to, should such a URI be received in a 503 web page or Contact header field of a redirect response. 505 It is RECOMMENDED that a UA provide complete information in its 506 feature predicate. That is, it SHOULD provide information on as many 507 feature tags as possible. The mechanisms in this specification work 508 best when user agents register complete feature sets. Furthermore, 509 when a UA registers values for a particular feature tag, it MUST list 510 all values that it supports. For example, when including the 511 "methods" feature tag, a UA MUST list all methods it supports. The 512 matching algorithms in this specification assume that omission of a 513 value from a list means that the value is not supported. 515 When using the "methods" feature tag, a UA MUST NOT include values 516 that correspond to methods not standardized in IETF standards track 517 RFCs. When using the "events" feature tag, a UA MUST NOT include 518 values that correspond to event packages not standardized in IETF 519 standards track RFCs. When using the "schemes" feature tag, a UA MUST 520 NOT include values that correspond to schemes not standardized in 521 IETF standards track RFCs. When using the "sip-extensions" feature 522 tag, a UA MUST NOT include values that correspond to option tags not 523 standardized in IETF standards track RFCs. 525 The REGISTER request MAY contain a Require header field with the 526 value "pref" if the client wants to be sure that the registrar 527 understands the extensions defined in this specification. In absence 528 of the Require header field, a server that does not understand this 529 extension will simply ignore the Contact header field parameters. 531 As an example, a UA that supports audio and video media types, is a 532 voicemail server, and is not mobile would construct a feature 533 predicate like this: 535 (& (audio=TRUE) 536 (video=TRUE) 537 (msgserver=TRUE) 538 (automata=TRUE) 539 (attendant=TRUE) 540 (mobility=fixed) 541 (| (methods=INVITE) (methods=BYE) (methods=OPTIONS) (methods=ACK) 542 (methods=CANCEL)) 544 (uri-user="user") 545 (uri-domain=host.example.com) 547 These would be converted into feature parameters and included in the 548 REGISTER request: 550 REGISTER sip:example.com SIP/2.0 551 From: sip:user@example.com;tag=asd98 552 To: sip:user@example.com 553 Call-ID: hh89as0d-asd88jkk@host.example.com 554 CSeq: 9987 REGISTER 555 Max-Forwards: 70 556 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 557 Contact: ;audio="TRUE";video="TRUE" 558 ;msgserver="TRUE";automata;attendant;mobility="fixed" 559 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 560 ;uri-user="" 561 ;uri-domain="host.example.com" 562 Content-Length: 0 564 Note that a voicemail server is usually an automata and an attendant, 565 as defined below. 567 6.2 Expressing Preferences in a Request 569 A caller wishing to express preferences for a request includes 570 Accept-Contact, Reject-Contact or Request-Disposition header fields 571 in the request, depending on their particular preferences. No 572 additional behavior is required after the request is sent. 574 The Accept-Contact, Reject-Contact and Request-Disposition header 575 fields in an ACK for a non-2xx final response, or in a CANCEL 576 request, MUST be equal to the values in the original request being 577 acknowledged or cancelled. This is to ensure proper operation through 578 stateless proxies. 580 If the UAC wants to be sure that servers understand the header fields 581 described in this specification, it MAY include a Proxy-Require 582 header field with a value of "pref". However, this is NOT 583 RECOMMENDED, as it leads to interoperability problems. In any case, 584 caller preferences can only be considered preferences - there is no 585 guarantee that the requested service is executed. As such, inclusion 586 of a Proxy-Require header field does not mean the preferences will be 587 executed, just that the caller preferences extension is understood by 588 the proxies. 590 6.2.1 Request Handling Preferences 592 The Request-Disposition header field specifies caller preferences for 593 how a server should process a request. Its value is a list of tokens, 594 each of which specifies a particular processing directive. 596 The syntax of the header field can be found in Section 10, and the 597 semantics of the directives are described in Section 8.1. 599 6.2.2 Feature Set Preferences 601 A UAC can indicate caller preferences for the capabilities of a UA 602 that should be reached or not reached as a result of sending a SIP 603 request. To do that, it adds one or more Accept-Contact and Reject- 604 Contact header field values. Each header field value contains a set 605 of feature parameters that define a feature set. In the case of 606 Accept-Contact, each value can also have a q-value parameter. 608 Each feature set MUST follow the constraints of Section 6.1. The 609 feature sets placed into these header fields MAY overlap; that is, a 610 UA MAY indicate preferences for feature sets that match according to 611 the matching algorithm of RFC 2533 [2]. The UA MAY use any feature 612 tag in an IANA registry or in a vendor defined URI tree. 614 A UAC can express explicit preferences for the methods and event 615 packages supported by a UA. It is RECOMMENDED that a UA include a 616 term in an Accept-Contact feature set with the "methods" feature tag, 617 whose value includes the method of the request. When a UA sends a 618 SUBSCRIBE request, it is RECOMMENDED that a UA include a term in an 619 Accept-Contact feature set with the "events" feature tag, whose value 620 includes the event package of the request. Whether these terms are 621 placed into a new feature set, or whether they are included in each 622 feature set, is at the discretion of the implementor. In most cases, 623 the right effect is achieved by including a term in each feature set. 625 The Reject-Contact header field allows the UAC to specify that a UA 626 should not be contacted if it matches any of the values of the header 627 field. Each value of the Reject-Contact header field contains a "*", 628 purely to align the syntax with guidelines for SIP extensions [24], 629 and is parameterized by a set of feature parameters. Any UA whose 630 capabilities match the feature set described by the feature 631 parameters matches the value. As with registrations, it is not 632 necessary for a UAC to construct the feature set in RFC 2533 syntax 633 as an intermediate step. The only requirement is that the feature 634 parameters, if converted back to RFC 2533 format, meet the 635 requirements above. 637 The Accept-Contact header field allows the UAC to specify that a UA 638 should be contacted if it matches some or all of the values of the 639 header field. Each value of the Accept-Contact header field contains 640 a "*" and is parameterized by a set of feature parameters. Any UA 641 whose capabilities match the feature set described by the feature 642 parameters matches the value. The q-value parameter provides a 643 weighting operation. A q-value parameter with a particular value 644 means that the caller's preference for a UA described by the feature 645 parameters equals that value. The processing rules at a proxy will 646 also favor those UA that are a "better" match to a particular value. 647 Here, better means that more of its capabilities explicitly match the 648 feature preferences. The value may also contain an "explicit" 649 parameter, which indicates that only UA whose capabilities explicitly 650 match are considered a match. If one of the values contains the 651 "require" parameter, it means that the UA must match that value. As 652 with registrations, it is not necessary for a UAC to construct the 653 feature set in RFC 2533 syntax as an intermediate step. The only 654 requirement is that the feature parameters, if converted back to RFC 655 2533 format, meet the requirements above. 657 6.3 Indicating Feature Sets in Remote Target URIs 659 Target refresh requests and responses are used to establish and 660 modify the remote target URI. The remote target URI is contained in 661 the Contact header field. A UAC or UAS MAY add feature parameters to 662 the Contact header field value in target refresh requests and 663 responses, for the purpose of indicating the capabilities of the UA. 664 To do that, it constructs a feature set predicate according to the 665 constraints of Section 6.1, and converts it to a set of feature 666 parameters using the rules in Section 11. These are then added as 667 Contact header field parameters in the request or response. 669 The feature parameters can be included in both initial requests and 670 mid-dialog requests, and MAY change mid-dialog to signal a change in 671 UA capabilities. 673 There is overlap in the caller preferences mechanism with the Allow, 674 Accept, Accept-Language, and Allow-Events [7] header fields, which 675 can also be used in target refresh requests. Specifically, the Allow 676 header field and "methods" feature tag indicate the same information. 677 The Accept header field and the "type" feature tag indicate the same 678 information. The Accept-Language header field and the "language" 679 feature tag indicate the same information. The Allow-Events header 680 field and the "events" feature tag indicate the same information. It 681 is possible that other header fields and feature tags defined in the 682 future may also overlap. When there exists a feature tag that 683 describes a capability that can also be represented with a SIP header 684 field, a UA MUST use the header field to describe the capability. A 685 UA receiving a message that contains both the header field and the 686 feature tag MUST use the header field, and not the feature tag. 688 6.4 Processing Request Handling and Feature Set Preferences 690 When a UAS compliant to this specification receives a request whose 691 request-URI corresponds to one of its registered Contacts, it SHOULD 692 apply the behavior described in Section 7 as if it were a proxy for 693 the domain in the request-URI. The UAS acts as if its location 694 database contains a single request target for the request-URI. That 695 target is associated with a feature set. The feature set is the same 696 as the one placed in the registration of the URI in the request-URI. 698 This processing occurs after the client authenticates and authorizes 699 the request, but before the remainder of the general UAS processing 700 described in Section 8.2.1 of RFC 3261. 702 If a UA registers against two separate addresses-of-record, and the 703 contacts registered for each have different capabilities, a UA MUST 704 use different URIs in each registration. This is so that the UA can 705 uniquely determine the feature set that is associated with the 706 request URI of an incoming request. 708 If, after performing this processing, there are no URI left in the 709 target set, the UA SHOULD reject the request with a 480 response. If 710 there is a URI remaining (there was only one to begin with), the UA 711 proceeeds with request processing as per RFC 3261. 713 Having a UAS perform the matching operations as if it were 714 a proxy allows certain caller preferences to be honored 715 even if the proxy doesn't support the extension. 717 6.5 OPTIONS Processing 719 When a UAS compliant to this specification receives an OPTIONS 720 request, it MAY add feature parameters to the Contact header field in 721 the OPTIONS response for the purpose of indicating the capabilities 722 of the UA. To do that, it constructs a feature set predicate 723 according to the constraints of Section 6.1, and converts it to a set 724 of feature parameters using the rules in Section 11. These are then 725 added as Contact header field parameters in OPTIONS response. Indeed, 726 if feature parameters were included in the registration generated by 727 that UA, those same parameters SHOULD be used in the OPTIONS 728 response. 730 7 Proxy Behavior 732 Proxy behavior consists of two orthogonal sets of rules - one for 733 processing the Request-Disposition header field, and one for 734 processing the URI and feature set preferences in the Accept-Contact 735 and Reject-Contact header fields. 737 In addition to processing these headers, a proxy MAY add one if not 738 present, or add a value to an existing header field, as if it were a 739 UAC. This is useful for a proxy to request processing in downstream 740 proxies in the implementation of a feature. However a proxy MUST NOT 741 modify or remove an existing header field or header field value. This 742 is particularly important when S/MIME is used. The message signature 743 could include the caller preferences header fields, allowing the UAS 744 to verify that, even though proxies may have added header fields, the 745 original caller preferences were still present. 747 7.1 Request-Disposition Processing 749 If the request contains a Request-Disposition header field, the 750 server SHOULD execute the directives as described in Section 8.1, 751 unless it has local policy configured to direct it otherwise. 753 7.2 Preference and Capability Matching 755 A proxy compliant to this specification MUST NOT apply the 756 preferences matching operation described here to a request unless it 757 is the owner of the domain in the request URI, and accessing a 758 location service that has capabilities associated with request 759 targets. However, if it is the owner of the domain, and accessing a 760 location service that has capabilities associated with request 761 targets, it SHOULD apply the processing described in this section. 762 Typically, this is a proxy that is using a registration database to 763 determine the request targets. However, if a proxy knows about 764 capabilities through some other means, it SHOULD apply the processing 765 defined here as well. If it does perform the processing, it MUST do 766 so as described below. 768 The processing is described through a conversion from the syntax 769 described in this specification to RFC 2533 syntax, followed by a 770 matching operation and a sorting of resulting contact values. The 771 usage of RFC 2533 syntax as an intermediate step is not required, it 772 only serves as a useful tool to describe the behavior required of the 773 proxy. A proxy can use any steps it likes so long as the results are 774 identical to the ones that would be achieved with the processing 775 described here. 777 7.2.1 Extracting Explicit Preferences 778 The first step in proxy processing is to extract explicit 779 preferences. To do that, it looks for the Accept-Contact and Reject- 780 Contact header fields. 782 For each value of those header fields, it extracts the feature 783 parameters. These are the header field parameters whose name is one 784 of the base-tags (see Section 10), or whose name begins with a plus 785 (+). The proxy converts all of those parameters to the syntax of RFC 786 2533, based on the rules in Section 11. 788 The result will be a set of feature set predicates in conjunctive 789 normal form, each of which is associated with one of the two 790 preference header fields. If there was a q parameter associated with 791 a header field value in the Accept-Contact header field, the feature 792 set predicate derived from that header field value is assigned a 793 preference equal to that q value. If there was a req-parameter 794 associated with a header field value in the Accept-Contact header 795 field, the feature set predicate derived from that header field value 796 is said to have its require flag set. Similarly, if there was an 797 explicit-param associated with a header field value in the Accept- 798 Contact header field, the feature set predicate derived from that 799 header field value is said to have its explicit flag set. 801 7.2.2 Extracting Implicit Preferences 803 If, and only if, the proxy did not find any explicit preferences in 804 the request (because there was no Accept-Contact or Reject-Contact 805 header field), the proxy extracts implicit preferences. These 806 preferences are ones implied by the presence of other information in 807 the request. 809 First, the proxy creates a conjunction with no terms. This 810 conjunction represents a feature set that will be associated with the 811 Accept-Contact header field, as if it were included there. Note that 812 there is no modification of the message implied - only an association 813 for the purposes of processing. Furthermore, this feature set has its 814 require flag set, but not its explicit flag. 816 The proxy then adds terms to the conjunction for the two implicit 817 preference types below. 819 7.2.2.1 Methods 821 One implicit preference is the method. When a UAC sends a request 822 with a specific method, it is an implicit preference to have the 823 request routed only to UAs that support that method. To support this 824 implicit preference, the proxy adds a term to the conjunction of the 825 following form: 827 (methods=[method of request]) 829 7.2.2.2 Event Packages 831 For requests that establish a subscription [7], the Event header 832 field is another expression of an implicit preference. It expresses a 833 desire for the request to be routed only to a server than supports 834 the given event package. To support this implicit preference, the 835 proxy adds a term to the conjunction of the following form: 837 (events=[value of the Event header field]) 839 7.3 Constructing Contact Predicates 841 The proxy then takes each URI in the target set (the set of URI it is 842 going to proxy or redirect to), and obtains its capabilities as an 843 RFC 2533 formatted feature set predicate. This is called a contact 844 predicate. If the target URI was obtained through a registration, the 845 proxy computes the contact predicate by extracting the feature 846 parameters from the Contact header field and the converting them to a 847 feature predicate. To extract the feature parameters, the proxy 848 follows these steps: 850 1. Create an initial, empty list of feature parameters. 852 2. If the Contact URI parameters included the "attendant", 853 "audio", "automata", "class", "duplex", "data", "control", 854 "mobility", "description", "events", "priority", "methods", 855 "schemes", "application", "video", "msgserver", "language", 856 "isfocus", "uri-user", "uri-domain" or "type" parameters, 857 those are copied into the list. 859 3. If any Contact URI parameter name begins with a "+", it is 860 copied into the list if the list does not already contain 861 that name with the plus removed. In other words, if the 862 "video" feature parameter is in the list, the "+video" 863 parameter would not be placed into the list. This conflict 864 should never arise if the client were compliant to this 865 specification, since it is illegal to use the + form for 866 encoding of a feature tag in the base set. 868 If the URI in the target set had no feature parameters, it is said to 869 be immune to caller preference processing. This means that the URI is 870 removed from the target set temporarily, the caller preferences 871 processing described below is executed, and then the URI is added 872 back in. 874 Assuming the URI has feature parameters, they are converted to RFC 875 2533 syntax using the rules of Section 11. 877 The resulting predicate is associated with a q-value. If the contact 878 predicate was learned through a REGISTER request, the q-value is 879 equal to the q-value in the Contact header field parameter, else 880 "1.0" if not specified. 882 As an example, consider the following registered Contact header 883 field: 885 Contact: ;audio;video;mobility="fixed"; 886 +message="TRUE";other-param=66372; 887 methods="INVITE,OPTIONS,BYE,CANCEL,ACK";schemes="sip,http"; 888 uri-user="";uri-domain="example.com" 890 This would be converted into the following predicate: 892 (& (audio=TRUE) 893 (video=TRUE) 894 (mobility=fixed) 895 (message=TRUE) 896 (| (methods=INVITE) (methods=OPTIONS) (methods=BYE) 897 (methods=CANCEL) (methods=ACK)) 898 (| (schemes=sip) (schemes=http)) 899 (uri-user="user") 900 (uri-domain="example.com")) 902 Note that "other-param" was not considered a featuer parameter, since 903 it is neither a base tag nor did it begin with a leading +. 905 7.4 Matching 907 It is important to note that the proxy does not have to know anything 908 about the meaning of the feature tags that it is comparing in order 909 to perform the matching operation. The rules for performing the 910 comparison depend on syntactic hints present in the values of each 911 feature tag. For example, a predicate such as: 913 (foo>=4) 915 implies that the feature tag "foo" is a numeric value. The matching 916 rules in RFC 2533 only require an implementation to know whether the 917 feature tag is a numeric, token, or quoted string (booleans can be 918 treated as tokens). Quoted strings are always matched using a case- 919 sensitive matching operation. Tokens are matched using case- 920 insensitive matching. Numerics are matched using normal mathematical 921 comparisons. 923 First, the proxy applies the predicates associated with the Reject- 924 Contact header field. 926 For each contact predicate, each Reject-Contact predicate (that is, 927 each predicate associated with the Reject-Contact header field) is 928 examined. If that Reject-Contact predicate contains a filter for a 929 feature tag, and that feature tag is not present anywhere in the 930 contact predicate, that Reject-Contact predicate is discarded for the 931 processing of that contact predicate. If the Reject-Contact predicate 932 is not discarded, it is matched to the contact predicate using the 933 matching operation of RFC 2533 [2]. If the result is a match, the URI 934 corresponding to that contact predicate is discarded from the target 935 set. 937 The result is that Reject-Contact will only discard URIs where the UA 938 has explicitly indicated support for the features that are not 939 wanted. 941 Next, the proxy applies the predicates associated with the Accept- 942 Contact header field. For each contact that remains in the target 943 set, the proxy constructs a matching set, Ms. Initially, this set 944 contains all of the Accept-Contact predicates. Each of those 945 predicates is examined. It is matched to the contact predicate using 946 the matching operation of RFC 2533 [2]. If the result is not a match, 947 and the Accept-Contact predicate had its require flag set, the URI 948 corresponding to that contact predicate is discarded from the contact 949 set. If the result is not a match, but the Accept-Contact predicate 950 did not have its require flag set, that contact URI is not discarded 951 from the contact set, however, the Accept-Contact predicate is 952 removed from the matching set for that contact. 954 For each contact that remains in the target set, the proxy computes a 955 score for that contact against each predicate the contact's matching 956 set. Let the number of terms in the Accept-Contact predicate 957 conjunction be equal to N. Each term in that predicate contains a 958 single feature tag. If the contact predicate has a term containing 959 that same feature tag, the score is incremented by 1/N. If the 960 feature tag was not present in the contact predicate, the score 961 remains unchanged. Based on these rules, the score can range between 962 zero and one. 964 The require and explicit tags are then applied, resulting in 965 potential modification of the score and the target set. This process 966 is summarized in Figure 1. If the score for the contact predicate 967 against that Accept-Contact predicate was less than one, and the 968 Accept-Contact predicate had an explicit tag, if the predicate also 969 had a require tag, the Contact URI corresponding to that contact 970 predicate is dropped. If, however, the predicate did not have a 971 require tag, the score is set to zero. If there was no explicit tag, 972 the score is unchanged. 974 The next step is to combine the scores and the q-values associated 975 with the predicates in the matching set, to arrive at an overall 976 caller preference, Qa. For those URIs in the target set which remain, 977 there will be a score which indicates its match against each Accept- 978 Contact predicate in the matching set. If there are M Accept-Contact 979 predicates in the matching set, there will be M scores S1 through SM, 980 for each contact. There will also be a preference associated with 981 each Accept-Contact predicate (derived from the q-value parameter, as 982 discussed in Section 7.2.1), X1..XM. The caller preference, Qa, is 983 computed as shown in Figure 2. 985 Note that in the limit as all Si go to zero, Qa equals the arithmetic 986 average of Xi. 988 This algorithm was chosen carefully so as to exhibit certain 989 properties: 991 o If Si is 1 for i=j, and zero for all other i, Qa=Xi. In other 992 words, if a contact predicate matches one of the Accept- 993 Contact predicates with a score of one (referred to as an 994 explicit match), and all others match with a score of zero 995 (referred to as an implicit match), the caller's preference 996 equals the q-value of that predicate. 998 o If Si is the same for all predicates in the matching set, Qa 999 is equal to the average of the q-values for the predicates. 1001 o If the contact predicate matches only one Accept-Contact 1002 predicate, Qa is equal to the q-value of that predicate, 1003 independent of the score. 1005 The final step is to combine the overall caller preference for the 1006 contact (Qa) with the q-value provided for that contact by the callee 1007 (which we denote as Qb). The proxy can use any averaging mechanism at 1008 its disposal, prefentially treating the callers preference and the 1009 callee's preference as policy dictates. In the absence of policy 1010 indicating otherwise, the two values are arithmetically averaged. 1011 This results in an overall q-value for that contact, Qo, equal to: 1013 Qa + Qb 1014 Qo = --------- 1015 2 1017 At this point, any URI that were removed from the target set because 1018 they were immune from caller preferences are added back in, and Qo 1019 for that URI is set to its original q-value, or 1.0 if there was no 1020 q-value specified. 1022 If there were no URIs in the target set after the application of the 1023 processing in this section, and the caller preferences were based on 1024 implicit preferences (Section 7.2.2), the processing in this section 1025 is discarded, and the original target set, along with their original 1026 q-values, is used. 1028 This handles the case where implicit preferences for the 1029 method or event packages resulted in the elimination of all 1030 potential targets. By going back to the original target 1031 set, those URIs will be tried, and result in the generation 1032 of a 405 or 489. The UAC can then use this information to 1033 try again, or report the error to the user. Without 1034 reverting to the original target set, the UAC would see a 1035 480 response, and have no knowledge of why their request 1036 failed. Of course, the target set can also be empty after 1037 the application of explicit preferences. This will result 1038 in the generation of a 480 by the proxy. This behavior is 1039 acceptable, and indeed, desirable in the case of explicit 1040 preferences. When the caller makes an explicit preference, 1041 T 1042 +----------> DROP Contact 1043 | 1044 | 1045 / \ 1046 / \ 1047 T / \ F 1048 +---->/require\------> Set score=0 1049 | \ / 1050 | \ / 1051 / \ \ / 1052 / \ \/ 1053 score<1 / \ 1054 +-------> /explicit----> Score unchanged 1055 | \ / F 1056 | \ / 1057 / \ \ / 1058 / \ \/ 1059 +--------+ / \ 1060 -->|Compute |--> /Score \ --------> Score unchanged 1061 | Score | \ / score=1 1062 +--------+ \ / 1063 \ / 1064 \/ 1066 Figure 1: Score Computation 1067 / 1068 / 1069 / 1070 | 0, if M=0 1071 | 1072 | 1073 | 1074 | M 1075 | ------ 1076 | \ 1077 | \ 1078 | / Si*Xi 1079 | / 1080 Qa = | ------ 1081 | i=1 1082 | if M>0 1083 | ------------------ 1084 | 1085 | M 1086 | ------ 1087 | \ 1088 | \ 1089 | / Si 1090 | / 1091 | ------ 1092 \ i=1 1093 \ 1094 \ 1096 Figure 2: Computation of Qa 1098 it is agreeing that its request might fail because of a 1099 preference mismatch. One might try to return an error 1100 indicating the capabilities of the callee, so that the 1101 caller could perhaps try again. However, doing so results 1102 in the leaking of potentially sensitive information to the 1103 caller without authorization from the callee, and therefore 1104 this specification does not provide a means for it. 1106 Any proxy processing that takes the q-values as inputs (for example, 1107 a forking operation as described in Section 16.6 of RFC 3261 [1]) 1108 would use Qo instead of the original q-value associated with the 1109 contact, for this specific transaction only. To avoid preferring one 1110 contact to another because of a relatively small difference in their 1111 overall q-value, it is RECOMMENDED that the values be rounded to the 1112 nearest tenth before they are used by the proxy. 1114 If a proxy server is recursing, it applies the caller preferences to 1115 the Contact header fields returned in the redirect responses. Any URI 1116 remaining after the application of caller preferences are added to 1117 the proxy's target set if it is not already in the target set. This 1118 list is then resorted based on q values. The server uses this list 1119 for subsequent proxy operations. 1121 If the server is redirecting, it returns all entries in the target 1122 set, including a q-value of Qo for each Contact URI as obtained 1123 through the process above. This includes any URI with a zero q-value. 1124 However, it MUST NOT include the feature parameters for the entries 1125 in the target set. If it did, the upstream proxy server would apply 1126 the same caller preferences once more, resulting in a double 1127 application of those preferences. If the redirect server does wish to 1128 include the feature parameters in the Contact header field, it MUST 1129 redirect using the original target set and original q-values, before 1130 the application of caller preferences. 1132 It is the usage of these modified q-values that allows the caller 1133 preferences to be taken into account, while at the same time giving 1134 the proxy flexibility in how it processes the request. 1136 7.4.1 Example 1138 Consider the following example, which is contrived but illustrative 1139 of the various components of the matching process. There are five 1140 registered Contacts for sip:user@example.com. They are: 1142 Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.1 1143 Contact: sip:u2@h.example.com;audio="FALSE"; 1144 methods="INVITE";msgserver;q=0.2 1145 Contact: sip:u3@h.example.com;audio;msgserver; 1146 methods="INVITE";video;q=0.3 1147 Contact: sip:u4@h.example.com;audio;methods="INVITE,OPTIONS";q=0.4 1148 Contact: sip:u5@h.example.com;q=0.5 1150 an INVITE sent to sip:user@example.com contained the following caller 1151 preferences header fields: 1153 Reject-Contact: *;msgserver;video 1154 Accept-Contact: *;audio;require;q=0.5, *;video;explicit;q=0.4, 1155 *;methods="BYE";class="business";q=1.0 1157 There are no implicit preferences in this example, because explicit 1158 preferences are provided. 1160 The proxy first removes u5 from the target set, since it is immune 1161 from caller preferences processing. 1163 Next, the proxy processes the Reject-Contact header field. It is a 1164 match for all four remaining contacts, but only an explicit match for 1165 u3. Thats because u3 is the only one that explicitly indicated 1166 support for video, and explicitly indicated it is a messaging server. 1167 So, u3 gets discarded, and the others remain. 1169 Next, each of the remaining three contacts is compared against each 1170 of the three Accept-Contact predicates. u1 is a match to all three, 1171 earning a score of 1.0 for the first two predicates, and 0.5 for the 1172 third (the methods feature tag was present in the contact predicate, 1173 but the class tag was not). u2 doesn't match the first predicate. 1174 Because that predicate has a require tag, u2 is discarded. u4 matches 1175 the first predicate, earning a score of 1.0. u4 does match the second 1176 predicate, but since the match is not explicit (the score is 0.0, in 1177 fact), the score is set to zero (it was already zero, so nothing 1178 changes). u4 does not match the third predicate. 1180 At this point, u1 and u4 remain. u1 matched all three Accept-Contact 1181 predicates, so that its matching set contains all three, with scores 1182 of 1, 1, and 0.5. u4 matches the first two predicates, with scores of 1183 1.0 and 0.0. 1185 Qa for u1 is then computed as: 1187 1.0*0.5 + 1.0*0.4 + 0.5*1.0 1188 --------------------------- = 0.56 1189 1.0 + 1.0 + 0.5 1191 Qa for u4 is then computed as: 1193 1.0*0.5 + 0.0*0.4 1194 ------------------ = 0.5 1195 1.0 + 0.0 1197 Qo for u1 is the average of 0.56 and the registered q-value of 0.1, 1198 which equals 0.33. Qo for u4 is the average of 0.5 and the registered 1199 q-value of 0.4, which equals 0.45. Rounding these to the nearest 1200 tenth, Qo for u1 is 0.3 and Qo for u4 is 0.5. 1202 Now, u5 is added back in. It retains its original q-value of 0.5. 1203 Since its q-value matches that of u4, both u4 and u5 would be tried 1204 in parallel. Should both fail, u1 would be tried. 1206 8 Header Field Definitions 1208 This specification defines three new header fields - Accept-Contact, 1209 Reject-Contact, and Request-Disposition. 1211 Tables 1 and 2 are an extension of Tables 2 and 3 in [1] for the 1212 Accept-Contact, Reject-Contact and Request-Disposition header fields. 1213 The column "INF" is for the INFO method [8], "PRA" is for the PRACK 1214 method [9], "UPD" is for the UPDATE method [10], "SUB" is for the 1215 SUBSCRIBE method [7], "NOT" is for the NOTIFY method [7], and "MSG" 1216 is for the MESSAGE method [3]. 1218 Header field where proxy ACK BYE CAN INV OPT REG 1219 _________________________________________________________ 1220 Accept-Contact R ar o o o o o - 1221 Reject-Contact R ar o o o o o - 1222 Request-Disposition R ar o o o o o o 1224 Table 1: Accept-Contact, Reject-Contact and Request-Disposition 1225 header fields 1227 8.1 Request Disposition 1229 The Request-Disposition header field specifies caller preferences for 1230 how a server should process a request. Its value is a list of tokens, 1231 each of which specifies a particular directive. Its syntax is 1232 specified in Section 10. Note that a compact form, using the letter 1233 d, has been defined. The directives are grouped into types. There can 1234 only be one directive of each type per request (i.e., you can't have 1235 both "proxy" and "redirect" in the same Request-Disposition header 1236 Header field where proxy PRA UPD SUB NOT INF MSG 1237 _________________________________________________________ 1238 Accept-Contact R ar o o o o o o 1239 Reject-Contact R ar o o o o o o 1240 Request-Disposition R ar o o o o o o 1242 Table 2: Accept-Contact, Reject-Contact, and Request-Disposition 1243 header fields 1245 field). 1247 When the caller specifies a directive, the server SHOULD honor that 1248 directive. 1250 The following types of directives are defined: 1252 proxy-directive: This type of directive indicates whether the 1253 caller would like each server to proxy ("proxy") or 1254 redirect ("redirect"). 1256 cancel-directive: This type of directive indicates whether the 1257 caller would like each proxy server to send a CANCEL 1258 request downstream ("cancel") in response to a 200 OK from 1259 the downstream server (which is the normal mode of 1260 operation, making it somewhat redundant), or whether this 1261 function should be left to the caller ("no-cancel"). If a 1262 proxy receives a request with this parameter set to "no- 1263 cancel", it SHOULD NOT CANCEL any outstanding branches on 1264 receipt of a 2xx. However, it would still send CANCEL on 1265 any outstanding branches on receipt of a 6xx. 1267 fork-directive: This type of directive indicates whether a proxy 1268 should fork a request ("fork"), or proxy to only a single 1269 address ("no-fork"). If the server is requested not to 1270 fork, the server SHOULD proxy the request to the "best" 1271 address (generally the one with the highest q-value). The 1272 directive is ignored if "redirect" has been requested. 1274 recurse-directive: This type of directive indicates whether a 1275 proxy server receiving a 3xx response should send requests 1276 to the addresses listed in the response ("recurse"), or 1277 forward the list of addresses upstream towards the caller 1278 ("no-recurse"). The directive is ignored if "redirect" has 1279 been requested. 1281 parallel-directive: For a forking proxy server, this type of 1282 directive indicates whether the caller would like the proxy 1283 server to proxy the request to all known addresses at once 1284 ("parallel"), or go through them sequentially, contacting 1285 the next address only after it has received a non-2xx or 1286 non-6xx final response for the previous one ("sequential"). 1287 The directive is ignored if "redirect" has been requested. 1289 queue-directive: If the called party is temporarily unreachable, 1290 e.g., because it is in another call, the caller can 1291 indicate that it wants to have its call queued ("queue") or 1292 rejected immediately ("no-queue"). If the call is queued, 1293 the server returns "182 Queued". A queued call can be 1294 terminated as described in [1]. 1296 Example: 1298 Request-Disposition: proxy, recurse, parallel 1300 The set of request disposition directives is purposefully not 1301 extensible. This is to avoid a proliferation of new extensions to SIP 1302 that are "tunneled" through this header field. 1304 8.2 Accept-Contact and Reject-Contact Header Fields 1306 The syntax for these header fields is described in Section 10. A 1307 compact form, with the letter a, has been defined for the Accept- 1308 Contact header field, and with the letter j for the Reject-Contact 1309 header field. 1311 The enc-feature-tag is an encoded version of any valid feature tag, a 1312 number of which are applicable to SIP, and defined in Section 9. Note 1313 that string-value uses the qdtext production from RFC 3261. This 1314 production allows UTF-8 characters. This is in contrast to RFC 2533, 1315 which only allows ASCII characters in quoted strings. Usage of UTF-8 1316 here is permissible since these values are never compared except 1317 using case sensitive matching rules. 1319 8.3 Contact Header Field 1321 This specification extends the Contact header field. In particular, 1322 it allows for the Contact header field parameters to include 1323 feature-param, whose BNF is described in Section 10. Feature-param is 1324 a feature parameter that describes a feature of the UA associated 1325 with the URI in the Contact header field. Feature parameters are 1326 identifiable because they either belong to the well known set of base 1327 feature tags, or they begin with a plus sign. 1329 9 Media Feature Tag Definitions 1331 This specification defines an initial set of media feature tags for 1332 use with this specification. New media feature tags MAY be registered 1333 with IANA, based on the process defined for feature tag registrations 1334 [5]. This section also serves as the IANA registration for these 1335 feature tags. 1337 Any registered feature tags MAY be used with this specification. 1338 However, several existing ones appear to be particularly applicable. 1339 These include the language feature tag [11], which can be used to 1340 specify the language of the human or automata represented by the UA, 1341 and the type feature tag [12], which can be used to specify the MIME 1342 types of the media formats supported by the UA. However, the usage of 1343 the audio, video, application, data and control feature tags (each of 1344 which indicate a media type, as defined in RFC 2327 [13] supported by 1345 the UA) are preferred to indicating support for specific media 1346 formats. When the type feature tag is present, there SHOULD also be a 1347 feature tag present for the its top-level MIME type with a value of 1348 TRUE. In other words, if a UA indicates in a registration that it 1349 supports the video/H263 MIME type, it should also indicate that it 1350 supports video generally: 1352 Contact: sip:192.0.2.1;type="video/H263";video="TRUE" 1354 If a new SDP media type were to be defined, such as "message", a new 1355 feature tag registration SHOULD be created for it. The name of the 1356 feature tag MUST equal that of the media type, unless there is an 1357 unlikely naming collision between the new media type and an existing 1358 feature tag registration. As a result of this, implementations can 1359 safely construct caller preferences and callee capabilities for the 1360 new media type before it is registered, as long as there is no naming 1361 conflict. 1363 If a new media feature tag is registered with the intent of using 1364 that tag with this specification, the registration is done for the 1365 unencoded form of the tag (see Section 11). In other words, if a new 1366 feature tag "foo" is registered, the IANA registration would be for 1367 the tag "foo" and not "+foo". When that parameter is used within the 1368 Contact, Accept-Contact and Reject-Contact header fields, it would be 1369 encoded using its + form. 1371 9.1 Attendant 1372 Media feature tag name: attendant 1374 ASN.1 Identifier: New assignment by IANA. 1376 Summary of the media feature indicated by this tag: This feature 1377 tag indicates that the device is an automated or human 1378 attendant that will answer if the actual user of the device 1379 is not available. 1381 Values appropriate for use with this feature tag: Boolean. 1383 The feature tag is intended primarily for use in the following 1384 applications, protocols, services, or negotiation 1385 mechanisms: This feature tag is most useful in a 1386 communications application, for describing the capabilities 1387 of a device, such as a phone or PDA. 1389 Examples of typical use: Routing a call to a phone that has an 1390 auto-attendant feature. 1392 Related standards or documents: RFC XXXX [[Note to IANA: Please 1393 replace XXXX with the RFC number of this specification.]] 1395 9.2 Audio 1397 Media feature tag name: audio 1399 ASN.1 Identifier: New assignment by IANA. 1401 Summary of the media feature indicated by this tag: This feature 1402 tag indicates that the device supports audio as a media 1403 type. 1405 Values appropriate for use with this feature tag: Boolean. 1407 The feature tag is intended primarily for use in the following 1408 applications, protocols, services, or negotiation 1409 mechanisms: This feature tag is most useful in a 1410 communications application, for describing the capabilities 1411 of a device, such as a phone or PDA. 1413 Examples of typical use: Routing a call to a phone that can 1414 support audio. 1416 Related standards or documents: RFC XXXX [[Note to IANA: Please 1417 replace XXXX with the RFC number of this specification.]] 1419 9.3 Application 1420 Media feature tag name: application 1422 ASN.1 Identifier: New assignment by IANA. 1424 Summary of the media feature indicated by this tag: This feature 1425 tag indicates that the device supports application as a 1426 media type. This feature tag exists primarily for 1427 completeness. Since so many MIME types are underneath 1428 application, indicating the ability to support applications 1429 provides little useful information. In most cases, the 1430 concrete MIME type is a better parameter to use in a 1431 predicate representing a preference. 1433 Values appropriate for use with this feature tag: Boolean. 1435 The feature tag is intended primarily for use in the following 1436 applications, protocols, services, or negotiation 1437 mechanisms: This feature tag is most useful in a 1438 communications application, for describing the capabilities 1439 of a device, such as a phone or PDA. 1441 Examples of typical use: Routing a call to a phone that can 1442 supports gaming application. 1444 Related standards or documents: RFC XXXX [[Note to IANA: Please 1445 replace XXXX with the RFC number of this specification.]] 1447 9.4 Data 1449 Media feature tag name: data 1451 ASN.1 Identifier: New assignment by IANA. 1453 Summary of the media feature indicated by this tag: This feature 1454 tag indicates that the device supports data as a media 1455 type. 1457 Values appropriate for use with this feature tag: Boolean. 1459 The feature tag is intended primarily for use in the following 1460 applications, protocols, services, or negotiation 1461 mechanisms: This feature tag is most useful in a 1462 communications application, for describing the capabilities 1463 of a device, such as a phone or PDA. 1465 Examples of typical use: Routing a call to a phone that can 1466 supports a data streaming application. 1468 Related standards or documents: RFC XXXX [[Note to IANA: Please 1469 replace XXXX with the RFC number of this specification.]] 1471 9.5 Control 1473 Media feature tag name: control 1475 ASN.1 Identifier: New assignment by IANA. 1477 Summary of the media feature indicated by this tag: This feature 1478 tag indicates that the device supports control as a media 1479 type. 1481 Values appropriate for use with this feature tag: Boolean. 1483 The feature tag is intended primarily for use in the following 1484 applications, protocols, services, or negotiation 1485 mechanisms: This feature tag is most useful in a 1486 communications application, for describing the capabilities 1487 of a device, such as a phone or PDA. 1489 Examples of typical use: Routing a call to a phone that can 1490 supports a floor control application. 1492 Related standards or documents: RFC XXXX [[Note to IANA: Please 1493 replace XXXX with the RFC number of this specification.]] 1495 9.6 Automata 1497 Media feature tag name: automata 1499 ASN.1 Identifier: New assignment by IANA. 1501 Summary of the media feature indicated by this tag: The automata 1502 feature tag is a boolean value that indicates whether the 1503 UA represents an automata (such as a voicemail server, 1504 conference server, or recording device) or a human. 1506 Values appropriate for use with this feature tag: Boolean. TRUE 1507 indicates that the UA represents an automata. 1509 The feature tag is intended primarily for use in the following 1510 applications, protocols, services, or negotiation 1511 mechanisms: This feature tag is most useful in a 1512 communications application, for describing the capabilities 1513 of a device, such as a phone or PDA. 1515 Examples of typical use: Choosing to communicate with a message 1516 recording device instead of a user. 1518 Related standards or documents: RFC XXXX [[Note to IANA: Please 1519 replace XXXX with the RFC number of this specification.]] 1521 9.7 Class 1523 Media feature tag name: class 1525 ASN.1 Identifier: New assignment by IANA. 1527 Summary of the media feature indicated by this tag: This feature 1528 tag indicates the setting, business or personal, in which a 1529 communications device is used. 1531 Values appropriate for use with this feature tag: Token with an 1532 equality relationship. Typical values include: 1534 business: The device is used for business communications. 1536 personal: The device is used for personal communications. 1538 The feature tag is intended primarily for use in the following 1539 applications, protocols, services, or negotiation 1540 mechanisms: This feature tag is most useful in a 1541 communications application, for describing the capabilities 1542 of a device, such as a phone or PDA. 1544 Examples of typical use: Choosing between a business phone and a 1545 home phone. 1547 Related standards or documents: RFC XXXX [[Note to IANA: Please 1548 replace XXXX with the RFC number of this specification.]] 1550 9.8 Duplex 1552 Media feature tag name: duplex 1554 ASN.1 Identifier: New assignment by IANA. 1556 Summary of the media feature indicated by this tag: The duplex 1557 media feature tag lists whether a communications device can 1558 simultaneously send and receive media ("full"), alternate 1559 between sending and receiving ("half"), can only receive 1560 ("receive-only") or only send ("send-only"). 1562 Values appropriate for use with this feature tag: Token with an 1563 equality relationship. Typical values include: 1565 full: The device can simultaneously send and receive media. 1567 half: The device can alternate between sending and 1568 receiving media. 1570 receive-only: The device can only receive media. 1572 send-only: The device can only send media. 1574 The feature tag is intended primarily for use in the following 1575 applications, protocols, services, or negotiation 1576 mechanisms: This feature tag is most useful in a 1577 communications application, for describing the capabilities 1578 of a device, such as a phone or PDA. 1580 Examples of typical use: Choosing to communicate with a 1581 broadcast server, as opposed to a regular phone, when 1582 making a call to hear an announcement. 1584 Related standards or documents: RFC XXXX [[Note to IANA: Please 1585 replace XXXX with the RFC number of this specification.]] 1587 9.9 Mobility 1589 Media feature tag name: mobility 1591 ASN.1 Identifier: New assignment by IANA. 1593 Summary of the media feature indicated by this tag: The mobility 1594 feature tag indicates whether the device is fixed, 1595 wireless, or somewhere in-between. 1597 Values appropriate for use with this feature tag: Token with an 1598 equality relationship. Typical values include: 1600 fixed: The device is stationary. 1602 mobile: The device can move around with the user. 1604 The feature tag is intended primarily for use in the following 1605 applications, protocols, services, or negotiation 1606 mechanisms: This feature tag is most useful in a 1607 communications application, for describing the capabilities 1608 of a device, such as a phone or PDA. 1610 Examples of typical use: Choosing to communicate with a wireless 1611 phone instead of a desktop phone. 1613 Related standards or documents: RFC XXXX [[Note to IANA: Please 1614 replace XXXX with the RFC number of this specification.]] 1616 9.10 Description 1618 Media feature tag name: description 1620 ASN.1 Identifier: New assignment by IANA. 1622 Summary of the media feature indicated by this tag: The 1623 description feature tag provides a textual description of 1624 the device. 1626 Values appropriate for use with this feature tag: String with an 1627 equality relationship. 1629 The feature tag is intended primarily for use in the following 1630 applications, protocols, services, or negotiation 1631 mechanisms: This feature tag is most useful in a 1632 communications application, for describing the capabilities 1633 of a device, such as a phone or PDA. 1635 Examples of typical use: Indicating that a device is of a 1636 certain make and model. 1638 Related standards or documents: RFC XXXX [[Note to IANA: Please 1639 replace XXXX with the RFC number of this specification.]] 1641 9.11 Event Packages 1643 Media feature tag name: events 1645 ASN.1 Identifier: New assignment by IANA. 1647 Summary of the media feature indicated by this tag: The event 1648 packages [7] supported by a SIP UA. The values for this tag 1649 equal the event package names that are registered by each 1650 event package. 1652 Values appropriate for use with this feature tag: Token with an 1653 equality relationship. Typical values include: 1655 presence: SIP event package for for user presence [25]. 1657 winfo: SIP event package for watcher information [26]. 1659 refer: The SIP REFER event package [27]. 1661 dialog: The SIP dialog event package [28]. 1663 conference: The SIP conference event package [29]. 1665 reg: The SIP registration event package [30]. 1667 message-summary: The SIP message summary event package 1668 [31]. 1670 The feature tag is intended primarily for use in the following 1671 applications, protocols, services, or negotiation 1672 mechanisms: This feature tag is most useful in a 1673 communications application, for describing the capabilities 1674 of a device, such as a phone or PDA. 1676 Examples of typical use: Choosing to communicate with a server 1677 that supports the message waiting event package, such as a 1678 voicemail server [31]. 1680 Related standards or documents: RFC XXXX [[Note to IANA: Please 1681 replace XXXX with the RFC number of this specification.]] 1683 9.12 Priority 1685 Media feature tag name: priority 1687 ASN.1 Identifier: New assignment by IANA. 1689 Summary of the media feature indicated by this tag: The priority 1690 feature tag indicates the call priorities the device is 1691 willing to handle. A value of X means that the device is 1692 willing to take requests with priority X and higher. 1694 Values appropriate for use with this feature tag: An integer. 1695 Each integral value corresponds to one of the possible 1696 values of the Priority header field as specified in SIP 1697 [1]. The mapping is defined as: 1699 non-urgent: Integral value of 10. The device supports non- 1700 urgent calls. 1702 normal: Integral value of 20. The device supports normal 1703 calls. 1705 urgent: Integral value of 30. The device supports urgent 1706 calls. 1708 emergency: Integral value of 40. The device supports 1709 emergency calls. 1711 The feature tag is intended primarily for use in the following 1712 applications, protocols, services, or negotiation 1713 mechanisms: This feature tag is most useful in a 1714 communications application, for describing the capabilities 1715 of a device, such as a phone or PDA. 1717 Examples of typical use: Choosing to communicate with the 1718 emergency cell phone of a user. 1720 Related standards or documents: RFC XXXX [[Note to IANA: Please 1721 replace XXXX with the RFC number of this specification.]] 1723 9.13 Methods 1725 Media feature tag name: methods 1727 ASN.1 Identifier: New assignment by IANA. 1729 Summary of the media feature indicated by this tag: The methods 1730 (note the plurality) feature tag indicates the SIP methods 1731 supported by this UA. In this case, "supported" means that 1732 the UA can receive requests with this method. In that 1733 sense, it has the same connotation as the Allow header 1734 field. 1736 Values appropriate for use with this feature tag: Token with an 1737 equality relationship. Values include: 1739 INVITE: The SIP INVITE method [1]. 1741 ACK: The SIP ACK method [1]. 1743 BYE: The SIP BYE method [1]. 1745 CANCEL: The SIP CANCEL method [1]. 1747 OPTIONS: The SIP OPTIONS method [1]. 1749 REGISTER: The SIP REGISTER method [1]. 1751 INFO: The SIP INFO method [8]. 1753 UPDATE: The SIP UPDATE method [10]. 1755 SUBSCRIBE: The SIP SUBSCRIBE method [7]. 1757 NOTIFY: The SIP NOTIFY method [7]. 1759 PRACK: The SIP PRACK method [9]. 1761 MESSAGE: The SIP MESSAGE method [3]. 1763 The feature tag is intended primarily for use in the following 1764 applications, protocols, services, or negotiation 1765 mechanisms: This feature tag is most useful in a 1766 communications application, for describing the capabilities 1767 of a device, such as a phone or PDA. 1769 Examples of typical use: Choosing to communicate with a presence 1770 application on a PC, instead of a PC phone application. 1772 Related standards or documents: RFC XXXX [[Note to IANA: Please 1773 replace XXXX with the RFC number of this specification.]] 1775 9.14 SIP Extensions 1777 Media feature tag name: sip-extensions 1779 ASN.1 Identifier: New assignment by IANA. 1781 Summary of the media feature indicated by this tag: The sip- 1782 extensions feature tag is a list of SIP extensions (each of 1783 which is defined by an option-tag registered with IANA) 1784 that are understood by the UA. Understood, in this context, 1785 means that the option tag would be included in a Supported 1786 header field in a request. 1788 Values appropriate for use with this feature tag: Token with an 1789 equality relationship. Values include: 1791 100rel: The UA supports reliability of provisional 1792 responses [9]. 1794 path: The UA supports the SIP Path header field [14]. 1796 precondition: The UA supports the preconditions mechanism 1797 described in RFC 3312 [15]. 1799 privacy: The UA supports the privacy extension described in 1800 RFC 3323 [16]. 1802 sec-agree: The UA supports the security agreement extension 1803 described in RFC 3329 [17]. 1805 The feature tag is intended primarily for use in the following 1806 applications, protocols, services, or negotiation 1807 mechanisms: This feature tag is most useful in a 1808 communications application, for describing the capabilities 1809 of a device, such as a phone or PDA. 1811 Examples of typical use: Choosing to communicate with a phone 1812 that supports quality of service preconditions instead of 1813 one that does not. 1815 Related standards or documents: RFC XXXX [[Note to IANA: Please 1816 replace XXXX with the RFC number of this specification.]] 1818 9.15 Schemes 1820 Media feature tag name: schemes 1822 ASN.1 Identifier: New assignment by IANA. 1824 Summary of the media feature indicated by this tag: The set of 1825 URI schemes [18] that are supported by a UA. Supported 1826 implies, for example, that the UA would know how to handle 1827 a URI of that scheme in the Contact header field of a 1828 redirect response. 1830 Values appropriate for use with this feature tag: Token with an 1831 equality relationship. Typical values include: 1833 sip: The SIP URI scheme [1]. 1835 sips: The SIPS URI scheme [1]. 1837 tel: The tel URI scheme [19]. 1839 http: The HTTP URI scheme [20]. 1841 https: The HTTPS URI scheme [32]. 1843 cid: The CID URI scheme [21]. 1845 The feature tag is intended primarily for use in the following 1846 applications, protocols, services, or negotiation 1847 mechanisms: This feature tag is most useful in a 1848 communications application, for describing the capabilities 1849 of a device, such as a phone or PDA. 1851 Examples of typical use: Choosing get redirected to a phone 1852 number when a called party is busy, rather than a web page. 1854 Related standards or documents: RFC XXXX [[Note to IANA: Please 1855 replace XXXX with the RFC number of this specification.]] 1857 9.16 Video 1859 Media feature tag name: video 1861 ASN.1 Identifier: New assignment by IANA. 1863 Summary of the media feature indicated by this tag: This feature 1864 tag indicates that the device supports video as a media 1865 type. 1867 Values appropriate for use with this feature tag: Boolean. 1869 The feature tag is intended primarily for use in the following 1870 applications, protocols, services, or negotiation 1871 mechanisms: This feature tag is most useful in a 1872 communications application, for describing the capabilities 1873 of a device, such as a phone or PDA. 1875 Examples of typical use: Routing a call to a phone that can 1876 support video. 1878 Related standards or documents: RFC XXXX [[Note to IANA: Please 1879 replace XXXX with the RFC number of this specification.]] 1881 9.17 Message Server 1883 Media feature tag name: msgserver 1885 ASN.1 Identifier: New assignment by IANA. 1887 Summary of the media feature indicated by this tag: This feature 1888 tag indicates that the device is a messaging server which 1889 will record messages for a user. An example of such a 1890 device is a voicemail server. 1892 Values appropriate for use with this feature tag: Boolean. 1894 The feature tag is intended primarily for use in the following 1895 applications, protocols, services, or negotiation 1896 mechanisms: This feature tag is most useful in a 1897 communications application, for describing the capabilities 1898 of a device, such as a phone or PDA. 1900 Examples of typical use: Requesting that a call not be routed to 1901 voicemail. 1903 Related standards or documents: RFC XXXX [[Note to IANA: Please 1904 replace XXXX with the RFC number of this specification.]] 1906 9.18 Is Focus 1908 Media feature tag name: isfocus 1910 ASN.1 Identifier: New assignment by IANA. 1912 Summary of the media feature indicated by this tag: This feature 1913 tag indicates that the UA is a conference server, also 1914 known as a focus, and will mix together the media for all 1915 calls to the same URI [33]. 1917 Values appropriate for use with this feature tag: Boolean. 1919 The feature tag is intended primarily for use in the following 1920 applications, protocols, services, or negotiation 1921 mechanisms: This feature tag is most useful in a 1922 communications application, for describing the capabilities 1923 of a device, such as a phone or PDA. 1925 Examples of typical use: Indicating to a UA that the server it 1926 has connected to is a conference server. 1928 Related standards or documents: RFC XXXX [[Note to IANA: Please 1929 replace XXXX with the RFC number of this specification.]] 1931 9.19 URI User 1933 Media feature tag name: uri-user 1935 ASN.1 Identifier: New assignment by IANA. 1937 Summary of the media feature indicated by this tag: The uri-user 1938 feature tag provides the user part of the SIP URI that 1939 represents the device. 1941 Values appropriate for use with this feature tag: String with an 1942 equality relationship. 1944 The feature tag is intended primarily for use in the following 1945 applications, protocols, services, or negotiation 1946 mechanisms: This feature tag is most useful in a 1947 communications application, for describing the capabilities 1948 of a device, such as a phone or PDA. 1950 Examples of typical use: Requesting to route a call to a 1951 specific device, identified by a URI. 1953 Related standards or documents: RFC XXXX [[Note to IANA: Please 1954 replace XXXX with the RFC number of this specification.]] 1956 9.20 URI Domain 1958 Media feature tag name: uri-domain 1960 ASN.1 Identifier: New assignment by IANA. 1962 Summary of the media feature indicated by this tag: The uri- 1963 domain feature tag indicates the hostname of a device. 1965 Values appropriate for use with this feature tag: Token with a 1966 case-insensitive equality relationship. 1968 The feature tag is intended primarily for use in the following 1969 applications, protocols, services, or negotiation 1970 mechanisms: This feature tag is most useful in a 1971 communications application, for describing the capabilities 1972 of a device, such as a phone or PDA. 1974 Examples of typical use: Requesting to route a call to a 1975 specific device, identified by a URI. 1977 Related standards or documents: RFC XXXX [[Note to IANA: Please 1978 replace XXXX with the RFC number of this specification.]] 1980 10 Augmented BNF 1982 Request-Disposition = ( "Request-Disposition" / "d" ) HCOLON 1983 directive *(COMMA directive) 1984 directive = proxy-directive / cancel-directive / 1985 fork-directive / recurse-directive / 1986 parallel-directive / queue-directive) 1987 proxy-directive = "proxy" / "redirect" 1988 cancel-directive = "cancel" / "no-cancel" 1989 fork-directive = "fork" / "no-fork" 1990 recurse-directive = "recurse" / "no-recurse" 1991 parallel-directive = "parallel" / "sequential" 1992 queue-directive = "queue" / "no-queue" 1993 Accept-Contact = ("Accept-Contact" / "a") HCOLON ac-value 1994 *(COMMA ac-value) 1995 Reject-Contact = ("Reject-Contact" / "j") HCOLON rc-value 1996 *(COMMA rc-value) 1997 ac-value = "*" *(SEMI ac-params) 1998 rc-value = "*" *(SEMI rc-params) 1999 ac-params = feature-param / c-p-q / req-param 2000 / explicit-param / generic-param 2001 rc-params = feature-param / req-param 2002 / explicit-param / generic-param 2003 feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list 2004 / string-value ) RDQUOT] 2005 enc-feature-tag = base-tags / other-tags 2006 base-tags = "attendant" / "audio" / "automata" / 2007 "class" / "duplex" / "data" / 2008 "control" / "mobility" / "description" / 2009 "events" / "priority" / "methods" / 2010 "schemes" / "application" / "video" / 2011 "msgserver" / "language" / "type" / 2012 "isfocus" / "uri-user" / "uri-domain" 2013 other-tags = "+" ftag-name 2014 ftag-name = ALPHA *( ALPHA / DIGIT / "!" / ""' / 2015 "." / "-" / "%" ) 2016 tag-value-list = tag-value *("," tag-value) 2017 tag-value = ["!"] (token-nobang / boolean / numeric) 2018 token-nobang = 1*(alphanum / "-" / "." / "%" / "*" 2019 / "_" / "+" / "`" / "'" / "~" ) 2020 boolean = "TRUE" / "FALSE" 2021 numeric = "#" numeric-relation number 2022 numeric-relation = ">=" / "<=" / "=" / (number ":") 2023 number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] 2024 string-value = "<" qdtext ">" 2025 req-param = "require" 2026 explicit-param = "explicit" 2028 Note that the tag-value-list uses an actual comma instead of the 2029 COMMA construction. Thats because it appears within a quoted string, 2030 where line folding cannot take place. 2032 The productions for c-p-q, name-addr, addr-spec, qdtext and generic- 2033 param can be found in RFC 3261 [1]. 2035 Despite the BNF, there MUST NOT be more than one c-p-q, req-param or 2036 explicit-param in an ac-params or rc-params. Furthermore, there can 2037 only be one instance of any feature tag in feature-param. 2039 Any numbers present in a feature parameter MUST be representable 2040 using an ANSI C double. 2042 The following production updates the one in RFC 3261 for contact- 2043 params: 2045 contact-params = c-p-q / c-p-expires / feature-param 2046 / contact-extension 2048 11 Mapping Feature Parameters and Feature Set Predicates 2050 Mapping between feature parameters and a feature set predicate, 2051 formatted according to the syntax of RFC 2533 [2] is trivial. 2053 Starting from a set of feature-param, the procedure is as follows. 2054 Construct a conjunction. Each term in the conjunction derives from 2055 one feature-param. If the feature-param has no value, it is 2056 equivalent, in terms of the processing which follows, as if it had a 2057 value of "TRUE". 2059 If the feature-param value is a tag-value-list, the element of the 2060 conjunction is a disjunction. There is one term in the disjunction 2061 for each tag-value in the tag-value-list. 2063 Consider now the construction of a filter from a tag-value. If the 2064 tag-value starts with a bang (!), the filter is of the form: 2066 (! ) 2068 where "filter from remainder" refers to the filter that would be 2069 constructed from the tag-value if the bang had not been present. 2071 If the tag-value starts with an octothorpe (#), the filter is a 2072 numeric comparison. The comparator is either =, >=, <= or a range 2073 based on the next characters in the phrase. If the next characters 2074 are =. >= or <=, the filter is of the form: 2076 (name comparator compare-value) 2077 where name is the name of the feature parameter after it has been 2078 decoded (see below), and comparator is either =, >= or <= depending 2079 of the initial characters in the phrase. If the remainder of the text 2080 in the tag-value after the equal contains a decimal point (implying a 2081 rational number), the decimal point is shifted right N times until it 2082 is an integer, I. Compare-value above is then set to "I / 10**N", 2083 where 10**N is the result of computing the number 10 to the Nth 2084 power. 2086 RFC 2533 uses a fractional notation to describe rational 2087 numbers. This specification use a decimal form. The above 2088 text merely converts between the two representations. 2089 Practically speaking, this conversion is not needed since 2090 the numbers are the same in either case. However, it is 2091 described in case implementations wish to directly plug the 2092 predicates generated by the rules in this section into an 2093 RFC 2533 implementation. 2095 If the value after the octothorpe is a number, the filter is a range. 2096 The format of the filter is: 2098 (name=[remainder]) 2100 where name is the feature-tag after it has been decoded (see below), 2101 and remainder is the remainder of the text in the tag-value after the 2102 #, with any decimal numbers converted to a rational form, and the 2103 colon replaced by a double dot (..). 2105 If the tag-value does not begin with an octothorpe (it is a token- 2106 nobang or boolean), the filter is of the form: 2108 (name=tag-value) 2110 where name is the feature-tag after it has been decoded (see below). 2112 If the feature-param contains a string-value (based on the fact that 2113 it begins with a left angle bracket ("<") and ends with a right angle 2114 bracket (">")), the filter is of the form: 2116 (name="qdtext") 2118 Note the explicit usage of quotes around the qdtext, which indicate 2119 that the value is a string. In RFC 2533, strings are compared using 2120 case sensitive rules, and tokens, case insensitive. 2122 In RFC 2533, when an feature tag value is unquoted, its a 2123 token, and when quoted, its a string. The comparison rules 2124 are case insensitive for the former, and sensitive for the 2125 latter. The presence of quotes, or lack thereof, is the 2126 means by which an implementation can tell whether to apply 2127 sensitive or insensitive comparison rules. In the syntax 2128 described here, we cannot use quoted strings, since there 2129 is already a quoted string around each contact parameter 2130 value. So, we use an angle bracket to signify that the 2131 value is to be interpreted as a case sensitive string. If 2132 no brackets are present, the proxy would perform matching 2133 operations in a case insensitive manner, and if they are 2134 present, case sensitive. 2136 Feature tags, as specified in RFC 2506, cannot be directly 2137 represented as header field parameters in the Contact, Accept-Contact 2138 and Reject-Contact header fields. This is due to an inconsistency in 2139 the grammars, and in the need to differentiate feature parameters 2140 from parameters used by other extensions. As such, feature tag values 2141 are encoded from RFC2506 format to yield an enc-feature-tag, and then 2142 are decoded into RFC 2506 format. The decoding process is simple. If 2143 there is a leading plus (+) sign, it is removed. Any exclamation 2144 point (!) is converted to a colon (:) and any single quote (') is 2145 converted to a forward slash (/). The encoding process is similarly 2146 performed. Any forward slashes in the feature tag are converted to a 2147 single quote, and any colons are converted to an exclamation point. 2148 If the feature tag name is not amongst the base tags specified in 2149 Section 10, a plus sign is added to the front of the feature tag to 2150 create the encoded feature tag. The plus sign MUST NOT be added if 2151 the feature tag name is amongst the base tags. 2153 As an example, the Accept-Contact header: 2155 Accept-Contact:*;mobility="fixed";events="!presence,winfo";language="en,de" 2156 ;description="";+newparam;+rangeparam="#-4:+5.125" 2158 would be converted to the following feature predicate: 2160 (& (mobility=fixed) 2161 (| (! (events=presence)) (events=winfo)) 2162 (| (language=en) (language=de)) 2163 (description="PC") 2164 (newparam=TRUE) 2165 (rangeparam=-4..5125/1000)) 2167 The conversion of an RFC 2533 formatted feature set to a set of 2168 feature parameters proceeds in the same way, but in reverse. The 2169 conversion can only be done for feature sets constrained as described 2170 in Section 6.1. The feature tag has to be encoded into a feature 2171 parameter using the process described above. 2173 12 Security Considerations 2175 The presence of caller preferences in a request has an effect on the 2176 ways in which the request is handled at a server. As a result, it is 2177 especially important that requests with caller preferences be 2178 integrity-protected. The same holds true for registrations with 2179 feature parameters in the Contact header field. User agents who are 2180 concerned with protecting the integrity of their requests SHOULD use 2181 the SIPS URI scheme. 2183 Processing of caller preferences requires set operations and searches 2184 which can require some amount of computation. This enables a DOS 2185 attack whereby a user can send requests with substantial numbers of 2186 caller preferences, in the hopes of overloading the server. To 2187 counter this, servers SHOULD reject requests with too many rules. A 2188 reasonable number is around 20. 2190 Feature sets contained in REGISTER requests can reveal sensitive 2191 information about a user or UA (for example, the languages spoken). 2192 If this information is sensitive, confidentiality SHOULD be provided 2193 by using the SIPS URI scheme, as described in RFC 3261 [1]. 2195 13 IANA Considerations 2197 There are a number of IANA considerations associated with this 2198 specification. 2200 13.1 Media Feature Tags 2201 This specification registers a number of new Media feature tags 2202 according to the procedures of RFC 2506 [5]. Those registrations are 2203 contained in Section 9, and are meant to be placed into the IETF tree 2204 for media feature tags. 2206 13.2 SIP Header Fields 2208 This specification registers three new SIP header fields, according 2209 to the process of RFC 3261 [1]. 2211 The following is the registration for the Accept-Contact header 2212 field: 2214 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number 2215 of this specification.] 2217 Header Field Name: Accept-Contact 2219 Compact Form: a 2221 The following is the registration for the Reject-Contact header 2222 field: 2224 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number 2225 of this specification.] 2227 Header Field Name: Reject-Contact 2229 Compact Form: j 2231 The following is the registration for the Request-Disposition header 2232 field: 2234 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number 2235 of this specification.] 2237 Header Field Name: Request-Disposition 2239 Compact Form: d 2241 13.3 SIP Option Tags 2243 This specification registers a single SIP option tag, pref. The 2244 required information for this registration, as specified in RFC 3261, 2245 is: 2247 Name: pref 2248 Description: This option tag is used in a Proxy-Require header 2249 field by a UAC to ensure that caller preferences are 2250 honored at each proxy along the path. However, this usage 2251 is discouraged. It can also be used in the Require header 2252 field of a registration to ensure that the registrar 2253 supports the caller preferences extensions. 2255 14 Acknowledgments 2257 The initial set of media feature tags used by this specification were 2258 influenced by Scott Petrack's CMA design. Jonathan Lennox, Rohan 2259 Mahy and John Hearty provided helpful comments. Graham Klyne provided 2260 assistance on the usage of RFC 2533. 2262 15 Author's Addresses 2264 Jonathan Rosenberg 2265 dynamicsoft 2266 72 Eagle Rock Avenue 2267 First Floor 2268 East Hanover, NJ 07936 2269 email: jdrosen@dynamicsoft.com 2271 Henning Schulzrinne 2272 Columbia University 2273 M/S 0401 2274 1214 Amsterdam Ave. 2275 New York, NY 10027-7003 2276 email: schulzrinne@cs.columbia.edu 2278 Paul Kyzivat 2279 Cisco Systems 2280 Mail Stop LWL3/12/2 2281 900 Chelmsford St. 2282 Lowell, MA 01851 2283 email: pkzivat@cisco.com 2285 16 Normative References 2287 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 2288 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 2289 initiation protocol," RFC 3261, Internet Engineering Task Force, June 2290 2002. 2292 [2] G. Klyne, "A syntax for describing media feature sets," RFC 2533, 2293 Internet Engineering Task Force, Mar. 1999. 2295 [3] "Session initiation protocol (SIP) extension for instant 2296 messaging," RFC 3428, Internet Engineering Task Force, Dec. 2002. 2298 [4] S. Bradner, "Key words for use in rfcs to indicate requirement 2299 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 2301 [5] K. Holtman, A. Mutz, and T. Hardie, "Media feature tag 2302 registration procedure," RFC 2506, Internet Engineering Task Force, 2303 Mar. 1999. 2305 [6] G. Klyne, "Corrections to "A syntax for describing media feature 2306 sets"," RFC 2738, Internet Engineering Task Force, Dec. 1999. 2308 [7] A. B. Roach, "Session initiation protocol (sip)-specific event 2309 notification," RFC 3265, Internet Engineering Task Force, June 2002. 2311 [8] S. Donovan, "The SIP INFO method," RFC 2976, Internet Engineering 2312 Task Force, Oct. 2000. 2314 [9] J. Rosenberg and H. Schulzrinne, "Reliability of provisional 2315 responses in session initiation protocol (SIP)," RFC 3262, Internet 2316 Engineering Task Force, June 2002. 2318 [10] J. Rosenberg, "The session initiation protocol (SIP) UPDATE 2319 method," RFC 3311, Internet Engineering Task Force, Oct. 2002. 2321 [11] P. Hoffman, "Registration of charset and languages media 2322 features tags," RFC 2987, Internet Engineering Task Force, Nov. 2000. 2324 [12] G. Klyne, "MIME content types in media feature expressions," RFC 2325 2913, Internet Engineering Task Force, Sept. 2000. 2327 [13] M. Handley and V. Jacobson, "SDP: session description protocol," 2328 RFC 2327, Internet Engineering Task Force, Apr. 1998. 2330 [14] D. Willis and B. Hoeneisen, "Session initiation protocol (SIP) 2331 extension header field for registering non-adjacent contacts," RFC 2332 3327, Internet Engineering Task Force, Dec. 2002. 2334 [15] "Integration of resource management and session initiation 2335 protocol (SIP)," RFC 3312, Internet Engineering Task Force, Oct. 2336 2002. 2338 [16] J. Peterson, "A privacy mechanism for the session initiation 2339 protocol (SIP)," RFC 3323, Internet Engineering Task Force, Nov. 2341 2002. 2343 [17] J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, and T. Haukka, 2344 "Security mechanism agreement for the session initiation protocol 2345 (SIP)," RFC 3329, Internet Engineering Task Force, Jan. 2003. 2347 [18] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 2348 identifiers (URI): generic syntax," RFC 2396, Internet Engineering 2349 Task Force, Aug. 1998. 2351 [19] A. Vaha-Sipila, "Urls for telephone calls," RFC 2806, Internet 2352 Engineering Task Force, Apr. 2000. 2354 [20] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. 2355 J. Leach, and T. Berners-Lee, "Hypertext transfer protocol -- 2356 HTTP/1.1," RFC 2616, Internet Engineering Task Force, June 1999. 2358 [21] E. Levinson, "Content-id and message-id uniform resource 2359 locators," RFC 2392, Internet Engineering Task Force, Aug. 1998. 2361 17 Informative References 2363 [22] J. Lennox and H. Schulzrinne, "Call processing language 2364 framework and requirements," RFC 2824, Internet Engineering Task 2365 Force, May 2000. 2367 [23] G. Klyne, "Protocol-independent content negotiation framework," 2368 RFC 2703, Internet Engineering Task Force, Sept. 1999. 2370 [24] J. Rosenberg and H. Schulzrinne, "Guidelines for authors of 2371 extensions to the session initiation protocol (SIP)," internet draft, 2372 Internet Engineering Task Force, Nov. 2002. Work in progress. 2374 [25] J. Rosenberg, "A presence event package for the session 2375 initiation protocol (SIP)," internet draft, Internet Engineering Task 2376 Force, Jan. 2003. Work in progress. 2378 [26] J. Rosenberg, "A watcher information event template-package for 2379 the session initiation protocol (SIP)," internet draft, Internet 2380 Engineering Task Force, Jan. 2003. Work in progress. 2382 [27] R. Sparks, "The SIP refer method," internet draft, Internet 2383 Engineering Task Force, Dec. 2002. Work in progress. 2385 [28] J. Rosenberg and H. Schulzrinne, "A session initiation protocol 2386 (SIP) event package for dialog state," internet draft, Internet 2387 Engineering Task Force, June 2002. Work in progress. 2389 [29] J. Rosenberg and H. Schulzrinne, "A session initiation protocol 2390 (SIP) event package for conference state," internet draft, Internet 2391 Engineering Task Force, June 2002. Work in progress. 2393 [30] J. Rosenberg, "A session initiation protocol (SIP) event package 2394 for registrations," internet draft, Internet Engineering Task Force, 2395 Oct. 2002. Work in progress. 2397 [31] R. Mahy, "A message summary and message waiting indication event 2398 package for the session initiation protocol (SIP)," internet draft, 2399 Internet Engineering Task Force, Nov. 2002. Work in progress. 2401 [32] E. Rescorla, "HTTP over TLS," RFC 2818, Internet Engineering 2402 Task Force, May 2000. 2404 [33] J. Rosenberg, "A framework for conferencing with the session 2405 initiation protocol," internet draft, Internet Engineering Task 2406 Force, Feb. 2003. Work in progress. 2408 [34] M. Smith and T. Howes, "LDAP: string representation of search 2409 filters," internet draft, Internet Engineering Task Force, Aug. 2002. 2410 Work in progress. 2412 A Overview of RFC 2533 2414 This section provides a brief overview of RFC 2533 and related 2415 specifications that form the content negotiation framework. 2417 A critical concept in the framework is that of a feature set. A 2418 feature set is information about an entity (in our case, a UA), which 2419 describes a set of features it can handle. A feature set can be 2420 thought of as a region in N-dimensional space. Each dimension in this 2421 space is a different media feature, identified by a media feature 2422 tag. For example, one dimension (or axis) might represent languages, 2423 another might represent methods, and another, MIME types. A feature 2424 collection represents a single point in this space. It represents a 2425 particular rendering or instance of an entity (in our case, a UA). 2426 For example, a "rendering" of a UA would define an instantaneous mode 2427 of operation that it can support. One such rendering would be 2428 processing the INVITE method, which carried the application/sdp MIME 2429 type, sent to a UA for a user that is speaking English. 2431 A feature set can therefore be defined as a set of feature 2432 collections. In other words, a feature set is a region of N- 2433 dimensional feature-space, that region being defined by the set of 2434 points - feature collections - that make up the space. If a 2435 particular feature collection is in the space, it means that the 2436 rendering described by that feature collection is supported by the 2437 device with that feature set. 2439 How does one represent a feature set? There are many ways to describe 2440 an N-dimensional space. One way is to identify mathematical functions 2441 which identify its contours. Clearly, that is too complex to be 2442 useful. The solution taken in RFC 2533 is to define the space with a 2443 feature set predicate. A feature predicate defines a relation over an 2444 N-dimensional space; its input is any point in that space (i.e. a 2445 feature collection), and is true for all points that are in the 2446 region thus defined. 2448 RFC 2533 describes a syntax for writing down these N-dimensional 2449 boolean functions, borrowed from LDAP [34]. It uses a prolog-style 2450 syntax which is fairly self-explanatory. This representation is 2451 called a feature set predicate. The base unit of the predicate is a 2452 filter, which is a boolean expression encased in round brackets. A 2453 filter can be complex, where it contains conjunctions and 2454 disjunctions of other filters, or it can be simple. A simple filter 2455 is one that expresses a comparison operation on a single media 2456 feature tag. 2458 For example, consider the feature set predicate: 2460 (& (foo=A) 2461 (bar=B) 2462 (| (baz=C) (& (baz=D) (bif=E)))) 2464 This defines a function over four media features - foo, bar, baz and 2465 bif. Any point in feature space with foo equal to A, bar equal to B, 2466 and either baz equal to C, or baz equal to D and bif equal to E, is 2467 in the feature set defined by this feature set predicate. 2469 Note that the predicate doesn't say anything about the number of 2470 dimensions in feature space. The predicate operates on a feature 2471 space of any number of dimensions, but only those dimensions labeled 2472 foo, bar, baz and bif matter. The result is that values of other 2473 media features don't matter. The feature collection 2474 foo=A,bar=B,baz=C,bop=F is in the feature set described by the 2475 predicate, even though the media feature tag "bop" isn't mentioned. 2476 Feature set predicates are therefore inclusive by default. A feature 2477 collection is present unless the boolean predicate rules it out. This 2478 was a conscious design choice in RFC 2533. 2480 RFC 2533 also talks about matching a preference with a capability 2481 set. This is accomplished by representing both with a feature set. A 2482 preference is a feature set - its a specification of a number of 2483 feature collections, any one of which would satisfy the requirements 2484 of the sender. A capability is also a feature set - its a 2485 specification of the feature collections that the recipient supports. 2486 There is a match when the spaces defined by both feature sets 2487 overlap. When there is overlap, there exists at least one feature 2488 collection that exists in both feature sets, and therefore a modality 2489 or rendering desired by the sender which is supported by the 2490 recipient. 2492 This leads directly to the definition of a match. Two feature sets 2493 match if there exists at least one feature collection present in both 2494 feature sets. 2496 Computing a match for two general feature set predicates is not easy. 2497 Section 5 of RFC 2533 presents an algorithm for doing it by expanding 2498 an arbitrary expression into disjunctive normal form. However, the 2499 feature set predicates used by the caller preferences specification 2500 are constrained. They are always in conjunctive normal form, with 2501 each term in the conjunction describing values for different media 2502 features. This makes computation of a match easy. It is computed 2503 independently for each media feature, and then the feature sets 2504 overlap if media features specified in both sets overlap. Computing 2505 the overlap of a single media feature is very straightforward, and is 2506 a simple matter of computing whether two finite sets overlap. 2508 Intellectual Property Statement 2510 The IETF takes no position regarding the validity or scope of any 2511 intellectual property or other rights that might be claimed to 2512 pertain to the implementation or use of the technology described in 2513 this document or the extent to which any license under such rights 2514 might or might not be available; neither does it represent that it 2515 has made any effort to identify any such rights. Information on the 2516 IETF's procedures with respect to rights in standards-track and 2517 standards-related documentation can be found in BCP-11. Copies of 2518 claims of rights made available for publication and any assurances of 2519 licenses to be made available, or the result of an attempt made to 2520 obtain a general license or permission for the use of such 2521 proprietary rights by implementors or users of this specification can 2522 be obtained from the IETF Secretariat. 2524 The IETF invites any interested party to bring to its attention any 2525 copyrights, patents or patent applications, or other proprietary 2526 rights which may cover technology that may be required to practice 2527 this standard. Please address the information to the IETF Executive 2528 Director. 2530 Full Copyright Statement 2532 Copyright (c) The Internet Society (2003). All Rights Reserved. 2534 This document and translations of it may be copied and furnished to 2535 others, and derivative works that comment on or otherwise explain it 2536 or assist in its implementation may be prepared, copied, published 2537 and distributed, in whole or in part, without restriction of any 2538 kind, provided that the above copyright notice and this paragraph are 2539 included on all such copies and derivative works. However, this 2540 document itself may not be modified in any way, such as by removing 2541 the copyright notice or references to the Internet Society or other 2542 Internet organizations, except as needed for the purpose of 2543 developing Internet standards in which case the procedures for 2544 copyrights defined in the Internet Standards process must be 2545 followed, or as required to translate it into languages other than 2546 English. 2548 The limited permissions granted above are perpetual and will not be 2549 revoked by the Internet Society or its successors or assigns. 2551 This document and the information contained herein is provided on an 2552 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2553 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2554 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2555 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2556 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.