idnits 2.17.1 draft-ietf-sip-callerprefs-07.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 9 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 954 has weird spacing: '... where proxy...' == Line 961 has weird spacing: '...Contact and...' == 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 (November 4, 2002) is 7844 days in the past. Is this intentional? 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 2806 (ref. '6') (Obsoleted by RFC 3966) ** 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 2396 (ref. '13') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2616 (ref. '14') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '19') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '27') (Obsoleted by RFC 9110) Summary: 8 errors (**), 0 flaws (~~), 4 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 draft-ietf-sip-callerprefs-07.txt 8 November 4, 2002 9 Expires: May 2003 11 Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 To view the list Internet-Draft Shadow Directories, see 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes a set of extensions to the Session Initiation 37 Protocol (SIP) which allow a caller to express preferences about 38 request handling in servers. These preferences include the ability to 39 select which URIs a request gets routed to, and to specify certain 40 request handling directives in proxies and redirect servers. It does 41 so by defining four new request headers, Accept-Contact, Reject- 42 Contact, Require-Contact and Request-Disposition, which specify the 43 caller's preferences. The extension also defines new parameters for 44 the Contact header that describe the capabilities and characteristics 45 of a UA. 47 Table of Contents 49 1 Introduction ........................................ 3 50 2 Terminology ......................................... 4 51 3 Definitions ......................................... 4 52 4 Overview of Operation ............................... 6 53 5 Usage of the Content Negotiation Framework .......... 7 54 6 UA Behavior ......................................... 8 55 6.1 Expressing Capabilities in a Registration ........... 8 56 6.2 Expressing Preferences in a Request ................. 10 57 6.2.1 Request Handling Preferences ........................ 11 58 6.2.2 Feature Set Preferences ............................. 11 59 6.3 Indicating Feature Sets in Remote Target URIs ....... 12 60 6.4 Request Handling and Feature Set Preferences ........ 13 61 7 Proxy Behavior ...................................... 14 62 7.1 Request-Disposition Processing ...................... 14 63 7.2 Preference and Capability Matching .................. 14 64 7.2.1 Extracting Explicit Preferences ..................... 14 65 7.2.2 Extracting Implicit Preferences ..................... 15 66 7.2.2.1 Priority ............................................ 15 67 7.2.2.2 Methods ............................................. 16 68 7.2.2.3 Event Packages ...................................... 16 69 7.2.2.4 Media Types ......................................... 17 70 7.2.2.5 Languages ........................................... 17 71 7.3 Constructing Contact Predicates ..................... 18 72 7.4 Matching ............................................ 19 73 8 Header Field Definitions ............................ 21 74 8.1 Request Disposition ................................. 21 75 8.2 Accept-Contact, Reject-Contact, and Require- 76 Contact Header Fields .......................................... 23 77 8.3 Contact Header Field ................................ 23 78 9 Media Feature Tag Definitions ....................... 24 79 9.1 Attendant ........................................... 24 80 9.2 Audio ............................................... 25 81 9.3 Automata ............................................ 25 82 9.4 Class ............................................... 26 83 9.5 Duplex .............................................. 26 84 9.6 Image ............................................... 27 85 9.7 Message ............................................. 28 86 9.8 Mobility ............................................ 28 87 9.9 Description ......................................... 29 88 9.10 Event Packages ...................................... 29 89 9.11 Priority ............................................ 30 90 9.12 Methods ............................................. 31 91 9.13 Schemes ............................................. 32 92 9.14 Text ................................................ 33 93 9.15 Video ............................................... 33 94 9.16 Voicemail ........................................... 34 95 10 Augmented BNF ....................................... 34 96 11 Mapping Feature Parameters and Feature Set 97 Predicates ..................................................... 35 98 12 Security Considerations ............................. 38 99 13 IANA Considerations ................................. 39 100 13.1 Media Feature Tags .................................. 39 101 13.2 SIP Header Fields ................................... 39 102 13.3 SIP Option Tags ..................................... 40 103 14 Acknowledgements .................................... 40 104 15 Author's Addresses .................................. 40 105 16 Normative References ................................ 41 106 17 Informative References .............................. 42 107 A Overview of RFC 2533 ................................ 43 109 1 Introduction 111 When a Session Initiation Protocol (SIP) [1] server receives a 112 request, there are a number of decisions it can make regarding 113 processing of the request. These include: 115 o whether to proxy or redirect the request 117 o which URIs to proxy or redirect to 119 o whether to fork or not 121 o whether to search recursively or not 123 o whether to search in parallel or sequentially 125 The server can base these decisions on any local policy. This policy 126 can be statically configured, or can be based on programmatic 127 execution or database access. 129 However, the administrator of the server is the not the only entity 130 with an interest in request processing. There are at least three 131 parties which have an interest: (1) the administrator of the server, 132 (2) the user that sent the request, and (3) the user to whom the 133 request is directed. The directives of the administrator are embedded 134 in the policy of the server. The preferences of the user to whom the 135 request is directed (referred to as the callee, even though the 136 request may not be INVITE) can be expressed most easily through a 137 script written in some type of scripting language, such as the Call 138 Processing Language (CPL) [16]. However, no mechanism exists to 139 incorporate the preferences of the user that sent the request (also 140 referred to as the caller, even though the request may not be 141 INVITE). For example, the caller might want to speak to a specific 142 user, but want to reach them only at work, because the call is a 143 business call. As another example, the caller might want to reach a 144 user, but not their voicemail, since it is important that the caller 145 talk to the called party. In both of these examples, the caller's 146 preference amounts to having a proxy make a particular routing choice 147 based on the preferences of the caller. 149 This extension allows the requestor to have these preferences met. It 150 does so by specifying mechanisms by which a caller can provide 151 preferences on processing of a request. There are two types of 152 preferences. One of them, called request handling preferences, are 153 encapsulated in the Request-Disposition header field. They provides 154 specific request handling directives for a server. The other, called 155 feature preferences, are present in the Accept-Contact, Reject- 156 Contact, and Require-Contact header fields. They allow the caller to 157 provide a feature set [2] that expresses its preferences on the 158 characteristics of the UA that is to be reached. These are matched 159 with a feature set carried in the Contact header of a REGISTER 160 request, which describes the capabilities of the UA represented by 161 the Contact URI. The extension is very general purpose, and not tied 162 to a particular service. Rather, it is a tool that can be used in the 163 development of many services. 165 Indeed, the feature sets uploaded to the server in REGISTER requests 166 can be used for a variety of purposes, not just meeting caller 167 preferences. Applications can use this information to tailor 168 information sent to a user as part of an instant message, for example 169 [17]. 171 2 Terminology 173 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 174 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 175 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 176 indicate requirement levels for compliant SIP implementations. 178 3 Definitions 180 Caller: Within the context of this specification, a caller 181 refers to the user on whose behalf a UAC is operating. It 182 is not limited to a user who's UAC sends the INVITE method. 184 Feature: As defined in RFC 2703 [18], a piece of information 185 about the media handling properties of a message passing 186 system component or of a data resource. For example, the 187 SIP methods supported by a UA represent a feature. 189 Feature Tag: As defined in RFC 2703 [18], a feature tag is a 190 name that identifies a feature. 192 Media Feature: As defined in RFC 2703, [18], a media feature is 193 information that indicates facilities assumed to be 194 available for the message content to be properly rendered 195 or otherwise presented. Media features are not intended to 196 include information that affects message transmission. 198 In the context of this specification, a media feature is 199 information that indicates facilities for handling SIP 200 requests, rather than specifically for content. In that 201 sense, it is used synonymously with feature. 203 Feature Collection: As defined in RFC 2533 [2], a feature 204 collection is a collection of different media features and 205 associated values. This might be viewed as describing a 206 specific rendering of a specific instance of a document or 207 resource by a specific recipient. 209 Feature Set: As defined in RFC 2703 [18], a feature set is 210 Information about a sender, recipient, data file or other 211 participant in a message transfer which describes the set 212 of features that it can handle. Where a 'feature' describes 213 a single identified attribute of a resource, a 'feature 214 set' describes full set of possible attributes. 216 Feature Preferences: Caller preferences that described desired 217 properties of a UA that the request is to be routed to. 218 These preferences are carried in the Accept-Contact, 219 Reject-Contact and Require-Contact header fields. 221 Request Handling Preferences: Caller preferences that describe 222 desired request treatment at a server. These preferences 223 are carried in the Request-Disposition header field. 225 Feature Parameters: A set of SIP header field parameters that 226 can appear in the Contact, Accept-Contact, Reject-Contact 227 and Require-Contact header fields. The feature parameters 228 represent an encoding of a feature set. There is a one-one 229 mapping between a set of feature parameters and a feature 230 set predicate, as both represent alternative encodings of a 231 feature set. 233 Capability: As defined in RFC 2703 [18], a capability is an 234 attribute of a sender or receiver (often the receiver) 235 which indicates an ability to generate or process a 236 particular type of message content. 238 Filter: A single expression in a feature predicate. 240 Simple Filter: An expression in a feature predicate which is a 241 comparison (equality or inequality) of a feature tag 242 against a feature value. 244 Disjunction: A boolean OR operation across some number of terms. 246 Predicate: A boolean expression. 248 Feature Set Predicate: From RFC 2533 [2], a feature set 249 predicate is a function of an arbitrary feature collection 250 value which returns a Boolean result. A TRUE result is 251 taken to mean that the corresponding feature collection 252 belongs to some set of media feature handling capabilities 253 defined by this predicate. 255 Contact Predicate: The feature set predicate associated with a 256 URI registered in the Contact header field of a REGISTER 257 request. The contact predicate is derived from the feature 258 parameters in the Contact header field. 260 4 Overview of Operation 262 This extension defines a set of additional parameters to the Contact 263 header field, called feature parameters. Each parameter name is a 264 feature tag, as defined in RFC 2703 [18], that defines a capability 265 for the UA associated with the Contact header field value. For 266 example, there is a parameter for the SIP methods supported by the 267 UA. Each feature parameter has a value; that value is the set of 268 feature values for that feature tag. Put together, all of the feature 269 parameters specify a feature set that is supported by the UA 270 associated with that Contact header field value. 272 When a UA registers, it places these parameters in the Contact header 273 field value to provide a feature set for each URI it is registering. 274 The feature parameters are also mirrored in the Contact header field 275 in a REGISTER response. The proxy can use this feature set to route 276 requests based on caller preferences. Furthermore, Contact header 277 fields in requests and responses that establish a dialog can contain 278 these parameters. That allows a UA in a dialog to indicate its 279 feature set to its peer. For example, by including the "voicemail" 280 feature tag with value "TRUE" in the 200 OK to an INVITE, the UAS can 281 indicate to the UAC that it is a voicemail server. This information 282 is useful for user interfaces, as well as automated call handling. 284 When a caller sends a request, it can optionally include new header 285 fields which request certain handling at a server. These preferences 286 fall into two categories. The first category, called request handling 287 preferences, are carried in the Request-Disposition header field. 288 They describe specific behavior that is desired at a server. Request 289 handling preferences include whether the caller wishes the server to 290 proxy or redirect, and whether sequential or parallel search is 291 desired. These preferences can be applied at every proxy or redirect 292 server on the call signaling path. 294 The second category of preferences, called feature preferences, are 295 carried in the Accept-Contact, Reject-Contact, and Require-Contact 296 header fields. These header fields also contain feature sets, 297 represented by the same feature parameters that are used in the 298 Contact header. Here, the feature parameters represent the caller's 299 preferences. The Accept-Contact header field contains feature sets 300 that describe UAs that the caller would like to reach. The Reject- 301 Contact header field contains feature sets which, if matched by a UA, 302 imply that the request should not be routed to that UA. The Require- 303 Contact header field contains feature sets which, if not matched by a 304 UA, imply that the request should not be routed to that UA. Require- 305 Contact and Accept-Contact are similar, but Require-Contact is more 306 forceful. Contacts which don't match are outright rejected, whereas 307 with Accept-Contact, they are tried as fallbacks. 309 Proxies use the information in the Accept-Contact, Reject-Contact and 310 Require-Contact header fields to select amongst registered contacts. 311 Proxies also compute implicit preferences from the request. These are 312 caller preferences that are not explicitly placed into the request, 313 but can be inferred from the presence of other message components. As 314 an example, if the request method is INVITE, this is an implicit 315 preference to route the call to a UA that supports the INVITE method. 317 Both request handling and feature preferences can appear in any 318 request, not just INVITE. However, they are only useful in requests 319 where proxies need to determine a request target. If the domain in 320 the request URI is not owned by any proxies along the request path, 321 those proxies will never access a location service, and therefore, 322 never have the opportunity to apply the caller preferences. This 323 makes sense; typically, the request URI will identify a UAS for mid- 324 dialog requests. In those cases, the routing decisions were already 325 made on the initial request, and it makes no sense to redo them for 326 subsequent requests in the dialog. 328 5 Usage of the Content Negotiation Framework 330 This specification makes heavy use of the terminology and concepts in 331 the content negotiation work carried out within the IETF, and 332 documented in several RFCs. The ones relevant to this specification 333 are RFC 2506 [4] which provides a template for registering media 334 feature tags, RFC 2533 [2] which presents a syntax and matching 335 algorithm for media feature sets, RFC 2738 [5], which provides a 336 minor update to RFC 2533, and RFC 2703 [18] which provides a general 337 framework for content negotiation. 339 In case the reader does not have the time to read those 340 specifications, Appendix A provides a brief overview of the concepts 341 and terminology in those documents that is critical for understanding 342 this specification. 344 Since the content negotiation work was primarily meant to apply to 345 documents or other resources with a set of possible renderings, it is 346 not immediately apparent how it is used to model the SIP entities at 347 hand. The goal of this specification is to allow a UA to express its 348 feature set, and for a caller to express a feature set that describes 349 properties of a desirable (or undesirable) UA. Therefore, we are 350 using feature sets to describe SIP user agents. 352 A feature set is composed of a set of feature collections, each of 353 which represents a specific rendering supported by the entity 354 described by the feature set. In the context of a SIP user agent, a 355 feature collection represents an instantaneous modality. That is, if 356 you look at the run time processing of a SIP UA, and take a snapshot 357 in time, the feature collection describes what it is doing at that 358 very instant. 360 This model is important, since it provides guidance on how to 361 determine whether something is a value for a particular feature tag, 362 or a feature tag by itself. If two properties can be exhibited by a 363 UA simultaneously, so that both are present in an instantaneous 364 modality, they need to be represented by separate media feature tags. 365 For example, a UA may be able to support some number of media types - 366 audio, video, and messaging. Should each of these be different values 367 for a single "media-types" feature tag, or should each of them be a 368 separate boolean feature tag? The model provides the answer. Since, 369 at any instant of time, a UA could be handling both audio and video, 370 they need to be separate media feature tags. However, the SIP methods 371 supported by a UA can each be represented as different values for the 372 same media feature tag (the "methods" tag), because fundamentally, a 373 UA processes a single request at a time. It may be multi-threading, 374 so that it appears that this is not so, but at a purely functional 375 level, it is true. 377 Clearly, there are weaknesses in this model, but it serves as a 378 useful guideline for applying the concepts of RFC 2533 to the problem 379 at hand. 381 6 UA Behavior 383 UA behavior covers four separate cases. The first is registration, 384 where a UA can declare its capabilities. The second is expression of 385 preferences, where a UA can tell a proxy how it wants the request to 386 be processed and routed. The third is expressing of capabilities, 387 through a feature set, in the Contact header field of a target 388 refresh request or response. The fourth is UAS processing of the 389 request handling and feature preferences. 391 6.1 Expressing Capabilities in a Registration 393 When a UA registers, it MAY construct a feature predicate for each 394 Contact URI it registers. In the text that follows, this process is 395 described in terms of RFC 2533 [2] (and its minor update, [5]) syntax 396 and constructs, followed by a conversion to the syntax used in this 397 specification. However, this represents a logical flow of processing. 398 There is no requirement that an implementation actually use RFC 2533 399 syntax as an intermediate step. 401 The feature predicate constructed by a UA MUST be an AND of terms. 402 Each term is either an OR of simple filters (called a disjunction), 403 or a single simple filter. In the case of an OR of simple filters, 404 each filter MUST indicate feature values for the same feature tag 405 (i.e., the disjunction represents a set of values for a particular 406 feature tag), and each element of the conjunction MUST be for a 407 different feature tag. Each filter can be an equality, the negation 408 of an equality, or in the case of numeric feature tags, an inequality 409 or range. This feature predicate is then converted to a list of 410 feature parameters using the procedure specified in Section 11. Those 411 feature parameters are added to the the Contact header field value 412 containing the URI that the parameters apply to. 414 A UA MAY use any feature tags that are registered through IANA in the 415 IETF or global trees [4]; this document registers several that are 416 appropriate for SIP. It is also permissible to use the URI tree [4] 417 for expressing vendor-specific feature tags. Feature tags in any 418 other trees created through IANA MAY also be used. 420 A UA MAY include the "schemes" feature tag in its feature parameters. 421 However, this tag MUST include a value that matches the scheme of the 422 URI being registered. For example, if a SIP URI is being registered, 423 the schemes parameter can include a SIP and TEL URI [6]. If this 424 feature tag is omitted, the proxy will assume an implicit value for 425 it, equal to the scheme of the registered URI. 427 It is RECOMMENDED that a UA provide complete information in its 428 feature parameters. That is, it SHOULD provide information on as many 429 feature tags as possible. The mechanisms in this specification work 430 best when user agents register complete feature sets. This includes 431 features that are supported, and those that are not. For example, if 432 a UA does not support video, it SHOULD include a 'video="FALSE"' 433 parameter in its registered Contact. Furthermore, when a UA registers 434 values for a particular feature tag, it MUST list all values that it 435 supports. For example, when including the methods feature tag, a UA 436 MUST list all methods it supports. The matching algorithms in this 437 specification assume that ommission of a value from a list means that 438 the value is not supported. 440 The REGISTER request MAY contain a Require header field with the 441 value "pref" if the client wants to be sure that the registrar 442 understands the extensions defined in this specification. In absence 443 of the Require header field, a server that does not understand this 444 extension will simply ignore the Contact header field parameters. 446 As an example, a UA that supports audio and video media types, is a 447 voicemail server, and is not mobile would construct a feature 448 predicate like this: 450 (& (audio=TRUE) 451 (video=TRUE) 452 (voicemail=TRUE) 453 (mobility=fixed) 454 (| (methods=INVITE) (methods=BYE) (methods=OPTIONS) (methods=ACK) 455 (methods=CANCEL))) 457 These would be converted into feature parameters and included in the 458 REGISTER request: 460 REGISTER sip:example.com SIP/2.0 461 From: sip:user@example.com;tag=asd98 462 To: sip:user@example.com 463 Call-ID: hh89as0d-asd88jkk@host.example.com 464 CSeq: 9987 REGISTER 465 Max-Forwards: 70 466 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 467 Contact: ;audio="TRUE";video="TRUE" 468 ;voicemail="TRUE";mobility="fixed" 469 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 470 Content-Length: 0 472 6.2 Expressing Preferences in a Request 474 A caller wishing to express preferences for a request includes 475 Accept-Contact, Reject-Contact, Require-Contact or Request- 476 Disposition header fields in the request, depending on their 477 particular preferences. No additional behavior is required after the 478 request is sent. 480 The Accept-Contact, Reject-Contact, Require-Contact and Request- 481 Disposition header fields in an ACK for a non-2xx final response, or 482 in a CANCEL request, MUST be equal to the values in the original 483 request being acknowledged or cancelled. This is to ensure proper 484 operation through stateless proxies. 486 If the UAC wants to be sure that servers understand the header fields 487 described in this specification, it MAY include a Proxy-Require 488 header field with a value of "pref". However, this is NOT 489 RECOMMENDED, as it leads to interoperability problems. In any case, 490 caller preferences can only be considered preferences - there is no 491 guarantee that the requested service or capability is executed. As 492 such, inclusion of a Proxy-Require header field does not mean the 493 preferences will be executed, just that the caller preferences 494 extension is understood by the proxies. 496 6.2.1 Request Handling Preferences 498 The Request-Disposition header field specifies caller preferences for 499 how a server should process a request. Its value is a list of tokens, 500 each of which specifies a particular processing directive. 502 The syntax of the header field can be found in Section 10, and the 503 semantics of the directives are described in Section 8.1. 505 6.2.2 Feature Set Preferences 507 A UAC can indicate caller preferences for the capabilities of a UA 508 that should be reached or not reached as a result of sending a SIP 509 request. To do that, it adds one or more Accept-Contact, Reject- 510 Contact, and Require-Contact header field values. Each header field 511 value is either a URI or the wildcard "*", along with feature 512 parameters that define a feature set. In the case of Accept-Contact, 513 each value can also have a q-value parameter. 515 Each feature set MUST follow the constraints of Section 6.1. That is, 516 when represented by a feature set predicate, each predicate MUST be a 517 conjunction of terms. Each term is either an OR of simple filters 518 (called a disjunction), or a single simple filter. In the case of an 519 OR of simple filters, each filter MUST indicate feature values for 520 the same feature tag (i.e., the disjunction represents a set of 521 values for a particular feature tag), and each element of the 522 conjunction MUST be for a different feature tag. Each filter can be 523 an equality, the negation of an equality, or in the case of numeric 524 feature tags, an inequality or range. 526 The feature sets placed into these header fields MAY overlap; that 527 is, a UA MAY indicate preferences for feature sets that match 528 according to the matching algorithm of RFC 2533 [2]. The UA MAY use 529 any feature tag in an IANA registry or in a vendor defined URI tree. 531 Note that the UAC can express explicit preferences for the methods, 532 event packages and priorities supported by a UA. As described in 533 Section 7.2.2, a proxy will compute implicit preferences from the 534 request if explicit ones are not provided. 536 The Reject-Contact header field allows the UAC to specify that a UA 537 should not be contacted if it matches any of the values of the header 538 field. Each value of the Reject-Contact header field contains a URI 539 or a "*" and is parameterized by a set of feature parameters. Any UA 540 whose capabilities match the feature set described by the feature 541 parameters, and whose URI matches the URI in the value (if 542 specified), matches the value. A value of "*" indicates a wildcard 543 operation on the URI, so that any URI matches. As with registrations, 544 it is not necessary for a UAC to construct the feature set in RFC 545 2533 syntax as an intermediate step. The only requirement is that the 546 feature parameters, if converted back to RFC 2533 format, meet the 547 requirements above. 549 The Require-Contact header field allows the UAC to specify that a UA 550 should not be contacted if it doesn't match all of the values of the 551 header field. Each value of the Require-Contact header field contains 552 a URI or a "*" and is parameterized by set of feature parameters. Any 553 UA whose capabilities match the feature set described by the feature 554 parameters, and whose URI matches the URI in the value (if 555 specified), matches the value. A value of "*" indicates a wildcard 556 operation on the URI, so that any URI matches. As with registrations, 557 it is not necessary for a UAC to construct the feature set in RFC 558 2533 syntax as an intermediate step. The only requirement is that the 559 feature parameters, if converted back to RFC 2533 format, meet the 560 requirements above. 562 The Accept-Contact header field allows the UAC to specify that a UA 563 should be contacted if it matches some or all of the values of the 564 header field. If a UA matches none of the values, it should be 565 contacted as a last resort. Each value of the Accept-Contact header 566 field contains a URI or a "*" and is parameterized by a set of 567 feature parameters. Any UA whose capabilities match the feature set 568 described by the feature parameters, and whose URI matches the URI in 569 the value (if specified), matches the value. A value of "*" indicates 570 a wildcard operation on the URI, so that any URI matches. The q-value 571 provides a weighting operation, allowing the UAC to request 572 preferential routing to UAs that match that value above other values. 573 As with registrations, it is not necessary for a UAC to construct the 574 feature set in RFC 2533 syntax as an intermediate step. The only 575 requirement is that the feature parameters, if converted back to RFC 576 2533 format, meet the requirements above. 578 6.3 Indicating Feature Sets in Remote Target URIs 580 Target refresh requests and responses are used to establish and 581 modify the remote target URI. The remote target URI is contained in 582 the Contact header field. A UAC or UAS MAY add feature parameters to 583 the Contact header field value in target refresh requests and 584 responses, for the purpose of indicating the capabilities of the UA. 585 To do that, it constructs a feature set predicate according to the 586 constraints of Section 6.1, and converts it to a set of feature 587 parameters using the rules in Section 11. These are then added as 588 Contact header field parameters in the request or response. 590 The feature parameters can be included in both initial requests and 591 mid-dialog request, and MAY change mid-dialog to signal a change in 592 UA capabilities. 594 There is overlap in the caller preferences mechanism with the Allow, 595 Accept, Accept-Language, and Allow-Events [7] header fields, which 596 can also be used in target refresh requests. Specifically, the Allow 597 header field and methods feature tag indicate the same information. 598 The Accept header field and the type feature tag indicate the same 599 information. The Accept-Language header field and the language 600 feature tag indicate the same information. The Allow-Events header 601 field and the events feature tag indicate the same information. It is 602 possible that other header fields and feature tags defined in the 603 future may also overlap. When there exists a feature tag that 604 describes a capability that can also be represented with a SIP header 605 field, a UA MUST use the header field to describe the capability. A 606 UA receiving a message that contains both the header field and the 607 feature tag MUST use the header field, and not the feature tag. 609 6.4 Request Handling and Feature Set Preferences 611 When a UAS compliant to this specification receives a request whose 612 request-URI correspods to one of its registered Contacts, it SHOULD 613 apply the behavior described in Section 7 as if it were a proxy for 614 the domain in the request-URI. The UAS acts as if its location 615 database contains a single request target for the request-URI. That 616 target is associated with a feature set. The feature set is the same 617 as the one placed in the registration of the URI in the request-URI. 618 It also adds the uri-user and uri-domain terms to the conjunction as 619 described in Section 7.2.1. 621 Having a UAS perform the matching operations as if it were 622 a proxy has many benefits. First, it allows caller 623 preferences to be honored even if the proxy doesn't support 624 the extension. Secondly, and perhaps more importantly, 625 feature set processing of preferences for the URI will only 626 occur at a UA, not at a proxy. Thats because the UA is the 627 only one that adds the uri-user and uri-domain terms to the 628 feature set describing a request target. 630 7 Proxy Behavior 632 Proxy behavior consists of two orthogonal sets of rules - one for 633 processing the Request-Disposition header field, and one for 634 processing the URI and feature set preferences in the Accept-Contact, 635 Reject-Contact, and Require-Contact header fields. 637 7.1 Request-Disposition Processing 639 If the request contains a Request-Disposition header field, the 640 server SHOULD execute the directives as described in Section 8.1, 641 unless it has local policy configured to direct it otherwise. 643 7.2 Preference and Capability Matching 645 A proxy compliant to this specification MUST NOT apply the 646 preferences matching operation described here to a request unless it 647 is the owner of the domain in the request URI, and accessing a 648 location service that has capabilities associated with request 649 targets. However, if it is the owner of the domain, and accessing a 650 location service that has capabilities associated wth request 651 targets, it SHOULD apply the processing described in this section. 652 Typically, this is a proxy that is using a registration database to 653 determine the request targets. However, if a proxy knows about 654 capabilities through some other means, it SHOULD apply the processing 655 defined here as well. 657 The processing is described through a conversion from the syntax 658 described in this specification to RFC 2533 syntax, followed by a 659 matching operation and a sorting of resulting contact values. The 660 usage of RFC 2533 syntax as an intermediate step is not required, it 661 only serves as a useful tool to describe the behavior required of the 662 proxy. A proxy can use any steps it likes so long as the results are 663 identical to the ones that would be achieved with the processing 664 described here. 666 7.2.1 Extracting Explicit Preferences 668 The first step in proxy processing is to extract explicit 669 preferences. To do that, it looks for the Accept-Contact, Reject- 670 Contact and Require-Contact header fields. 672 For each value of those header fields, it SHOULD convert all 673 parameters except for the q-value to the syntax of RFC 2533, based on 674 the rules in Section 11. If a value of the header field was not a 675 "*", it SHOULD take the URI in that value, and add two terms to the 676 top level conjunction: 678 (uri-user=) 680 and 682 (uri-domain=) 684 If the user part of the SIP URI is absent, the uri-user term is not 685 added, only the uri-domain one. No URI parameters are used. Note that 686 these are not "real" feature tags; they are not registered with IANA 687 and cannot appear anywhere in actual form. They are merely added in 688 order to perform the matching operation. 690 The result will be a set of feature set predicates in conjunctive 691 normal form, each of which is associated with one of the three 692 preference header fields. If there was a q parameter associated with 693 a header field value in the Accept-Contact header field, the feature 694 set predicate derived from that header field value is assigned a 695 preference equal to that q value. 697 7.2.2 Extracting Implicit Preferences 699 The proxy then applies any "implicit" preferences. These preferences 700 are ones not explicitly stated in the three header fields, but 701 implied by the presence of other header fields in the request. 703 7.2.2.1 Priority 705 The Priority header field is an indication of a caller preference - a 706 desire to be routed to a UA that can handle requests of the desired 707 priority. If the request contained a Priority header field, the proxy 708 looks for feature tags with the value "priority" in all feature set 709 predicates. If that feature tag is not used in any of the predicates, 710 the proxy creates a new feature set predicate, and associates it with 711 the Accept-Contact header field (note that there is no modification 712 of the message implied - only an association for the purposes of 713 processing). The new predicate looks like: 715 (& (priority>=[numeric value of the Priority header field])) 716 The numeric value of the Priority header field is obtained through 717 the procedures described in Section 9.11. For example, if the request 718 had a Priority header field with a value of urgent, the proxy would 719 create the following predicate: 721 (& (priority >= 3)) 723 7.2.2.2 Methods 725 Another implicit preference is the method. When a UAC sends a request 726 with a specific method, it is an implicit preference to have the 727 request routed only to UAs that support that method. To support this 728 implicit preference, the proxy looks for feature tags with the value 729 "methods" in all feature set predicates. If that feature tag is not 730 used in any of the predicates, the proxy examines the predicates 731 associated with the Require-Contact header field. If there are no 732 predicates associated with that header field, the proxy creates a new 733 empty feature set predicate, and associates it with the Require- 734 Contact header field (note that there is no modification of the 735 message implied - only an association for the purposes of 736 processing). In this case, an empty predicate is one with a 737 conjunction, but no terms in that conjunction yet. 739 For all predicates associated with the Require-Contact header field 740 (including the one which may have just been created), the proxy 741 SHOULD add a term to the conjunction of the following form: 743 (methods=[method of request]) 745 7.2.2.3 Event Packages 747 For requests that establish a subscription [7], the Event header 748 field is another expression of an implicit preference. It expresses a 749 desire for the request to be routed only to a server than supports 750 the given event package. To implement that implicit preference, the 751 proxy looks for feature tags with the value "events" in all feature 752 set predicates. If that feature tag is not used in any of the 753 predicates, the proxy examines the predicates associated with the 754 Require-Contact header field. If there are no predicates associated 755 with that header field, the proxy creates a new empty feature set 756 predicate, and associates it with the Require-Contact header field 757 (note that there is no modification of the message implied - only an 758 association for the purposes of processing). In this case, an empty 759 predicate is one with a conjunction, but no terms yet. 761 For all predicates associated with the Require-Contact header field 762 (including the one which may have just been created), the proxy 763 SHOULD add a term of the following form: 765 (events=[value of the Event header field]) 767 7.2.2.4 Media Types 769 Another implicit preference is for the sessions that are to be 770 established. If a UA generates an INVITE request with a session 771 description that includes video, this is an implicit preference to be 772 connected to a UA that supports video. To implement this implicit 773 preference, the proxy looks for feature tags with the values "audio", 774 "video", "application", "message", "text" or "image" in all feature 775 set predicates. If none of those feature tags are used in any of the 776 predicates, the proxy MAY create a new feature set predicate, and 777 associate it with the Accept-Contact header field (note that there is 778 no modification of the message implied - only an association for the 779 purposes of processing). This predicate has a term for each top-level 780 media type listed in the session description, with a value of TRUE. 781 For example, if the request is an INVITE request, with a Session 782 Description Protocol (SDP) [19] body, where the SDP contains an audio 783 and a video media description, the proxy would construct the 784 following predicate: 786 (& (audio=TRUE) 787 (video=TRUE)) 789 This implicit preference is added with MAY strength, and not SHOULD, 790 since it requires the proxy to examine the body of the request. This 791 can have performance implications, and won't always be possible. For 792 example, if the body is encrypted, the proxy cannot examine it. 794 7.2.2.5 Languages 795 The languages understood by the caller is another form of implicit 796 preference. The Accept-Language header field contains a list of the 797 languages that content should be returned in. It is reasonable to 798 imply that the caller would like the call to be routed to a user that 799 speaks those languages as well. To implement that implicit 800 preference, the proxy looks for feature tags with the value 801 "language" in all feature set predicates. If that feature tag is not 802 used in any of the predicates, the proxy creates a new feature set 803 predicate for each value in the Accept-Language header field, and 804 associates it with the Accept-Contact header field (note that there 805 is no modification of the message implied - only an association for 806 the purposes of processing). Each predicate is of the following form: 808 (& (language=[value of the Accept-Language header field])) 810 Furthermore, if an Accept-Language header field value had a q-value 811 associated with it, that q-value is associated with the corresponding 812 feature set predicate. 814 7.3 Constructing Contact Predicates 816 The proxy then takes each URI in the target set (the set of URI it is 817 going to proxy or redirect to), and obtains its capabilities as an 818 RFC 2533 formatted feature set predicate. This is called a contact 819 predicate. If target URI was obtained through a registration, the 820 proxy computes the contact predicate by taking all Contact URI 821 parameters except for the q and expires parameters, and converting 822 them to RFC 2533 syntax using the rules of Section 8.1. 824 If the contact predicate doesn't already contain a "schemes" feature 825 tag, the proxy SHOULD add a term containing one, whose value is equal 826 to the scheme of the URI. 828 The resulting predicate is associated with a q-value. If the contact 829 predicate was learned through a REGISTER request, the q-value is 830 equal to the q-value in the Contact header field parameter, else 831 "1.0" if not specified. 833 As an example, if a REGISTER request had the following Contact URI: 835 Contact: sip:1.2.3.4;mobility="fixed";q=0.8 836 The proxy would compute the following contact predicate, associating 837 it with a q-value of 0.8: 839 (& (mobility=fixed) 840 (schemes=sip)) 842 7.4 Matching 844 It is important to note that the proxy does not have to know anything 845 about the meaning of the feature tags that it is comparing in order 846 to perform the matching operation. The rules for performing the 847 comparison depend on syntactic hints present in the values of each 848 feature tag. For example, a predicate such as: 850 foo>=4 852 implies that the feature tag foo is a numeric value. The matching 853 rules in RFC 2533 only require to know whether the feature tag is a 854 numeric, token, quoted string, etc. 856 First, the proxy applies the predicates associated with the Reject- 857 Contact header field. 859 For each contact predicate, each Reject-Contact predicate (that is, 860 each predicate associated with the Reject-Contact header field) is 861 examined. If that Reject-Contact predicate contains a filter for a 862 feature tag, and that feature tag is not present anywhere in the 863 contact predicate, that Reject-Contact predicate is discarded for the 864 processing of that contact predicate. If the Reject-Contact predicate 865 is not discarded, it is matched to the contact predicate using the 866 matching operation of RFC 2533 [2]. If the result is a match, the URI 867 corresponding to that contact predicate is discarded from the target 868 set (and of course, its contact predicate is discarded as well). 870 The result is that Reject-Contact will only discard URIs where the UA 871 has explicitly indicated support for the features that are not 872 wanted. 874 Next, the proxy applies the predicates associated with the Require- 875 Contact header field. 877 For each contact predicate that remains, each Require-Contact 878 predicate is examined. The Require-Contact predicate is matched to 879 the contact predicate using the matching operation of RFC 2533 [2]. 880 If the result is not a match, the URI corresponding to that contact 881 predicate is discarded from the target set, as is the contact 882 predicate itself. 884 For each contact predicate that remains, each Accept-Contact 885 predicate is examined. The Accept-Contact predicate is matched to the 886 contact predicate using the matching operation of RFC 2533 [2]. If 887 the result is a match, the URI associated with the contact predicate 888 is considered a candidate URI. The set of Accept-Contact predicates 889 which matched the contact predicate is called its matching set. 891 The q-value of URIs from the target set are then modified for this 892 transaction only, in order to incorporate the caller's preferences. 893 If the URI in the target set is not a candidate URI, its q-value is 894 set to zero. If the URI is a candidate URI, its q-value is combined 895 with those from the matching set. This document does not prescribe a 896 specific algorithm for combining q-values. Among many possibilities, 897 a server MAY set the q-value to the average of the original value 898 specified in the registration, and the average q-value amongst the 899 predicates in the matching set. This gives equal weight to caller and 900 callee preferences. The only requirement for the combining process is 901 that if a target URI has a q-value of q1, and the q values amongst 902 the predicates in the matching set are q2,q3,..qn, the combined q 903 value, qm, must satisfy: 905 MIN(q1,q2,q3,..qn) <= qm <= MAX(q1,q2,q3,..,qn) 907 Note that this preference computation only determines the 908 ordering of request attempts, so that the properties of the 909 preference computation are of secondary importance. The q- 910 value ordering provides only limited flexibility to 911 indicate, for example, that a particular parameter is more 912 important than another one or that combinations of two 913 parameters should be weighed heavily. 915 If the server proxies, the target set is then sorted according to the 916 updated q-value. Processing from this point depends on the 917 configuration and policy of the server. If the server elects to do a 918 sequential proxy, it SHOULD try the highest q-value contact entry 919 first, trying addresses with decreasing q-values as each attempt 920 fails. If the server elects to do a parallel proxy, it SHOULD group 921 contact entries with "close" q-values together, and try the group 922 with the highest q-value first, then the group with the next lowest 923 q-values, and so on. The precise method of the grouping is left to 924 the implementor. A reasonable choice is to round each q-value to the 925 nearest tenth, and group those with the same rounded value. 927 If a proxy server is recursing, it SHOULD apply the caller 928 preferences to the Contact header fields returned in the redirect 929 responses. Any target URI remaining after the application of caller 930 preferences SHOULD be added to the list of untried addresses. This 931 list is then resorted based on q values. The server uses this list 932 for subsequent proxy operations. 934 If the server is redirecting, it SHOULD return all entries in the 935 target set, including a q-value for each as obtained through the 936 combining process. This SHOULD include any URI with a zero q-value. 938 If the server is executing any other type of policy, as a general 939 guideline, it SHOULD prefer target URI with higher q values than 940 those with lower q values. 942 8 Header Field Definitions 944 This specification defines four new header fields - Accept-Contact, 945 Reject-Contact, Require-Contact and Request-Disposition. 947 Table 1 is an extension of Tables 2 and 3 in [1] for the Accept- 948 Contact, Reject-Contact, Require-Contact and Request-Disposition 949 header fields. The column "INF" is for the INFO method [8], "PRA" is 950 for the PRACK method [9], "UPD" is for the UPDATE method [10], "SUB" 951 is for the SUBSCRIBE method [7], and "NOT" is for the NOTIFY method 952 [7]. 954 Header field where proxy ACK BYE CAN INV OPT REG PRA UPD SUB NOT INF 955 _____________________________________________________________________________ 956 Accept-Contact R r o o o o o - o o o o o 957 Reject-Contact R r o o o o o - o o o o o 958 Require-Contact R r o o o o o - o o o o o 959 Request-Disposition R r o o o o o o o o o o o 961 Table 1: Accept-Contact, Reject-Contact, Require-Contact and 962 Request-Disposition header fields 964 8.1 Request Disposition 965 The Request-Disposition header field specifies caller preferences for 966 how a server should process a request. Its value is a list of tokens, 967 each of which specifies a particular directive. Its syntax is 968 specified in Section 10. Note that a compact form, using the letter 969 d, has been defined. There can only be one value of a directive per 970 header field (i.e., you can't have both "proxy" and "redirect" in the 971 same Request-Disposition header field). 973 When the caller specifies a directive, the server SHOULD treat it as 974 a hint, not as a requirement and MAY ignore the directive. 976 The directives have the following semantics: 978 proxy-directive: This directive indicates whether the caller 979 would like each server to proxy or redirect. If the server 980 is incapable of performing the requested directive, it 981 SHOULD ignore it. 983 cancel-directive: This directive indicates whether the caller 984 would like each proxy server to send a CANCEL request 985 downstream in response to a 200 OK from the downstream 986 server (which is the normal mode of operation, making it 987 somewhat redundant), or whether this function should be 988 left to the caller. If a proxy receives a request with this 989 parameter set to "no-cancel", it SHOULD NOT CANCEL any 990 outstanding branches on receipt of a 2xx. However, it would 991 still send CANCEL on any outstanding branches on receipt of 992 a 6xx. 994 fork-directive: This directive indicates whether a proxy should 995 fork a request, or proxy to only a single address. If the 996 server is requested not to fork, the server SHOULD proxy 997 the request to the "best" address (generally the one with 998 the highest q value). The directive is ignored if 999 "redirect" has been requested. 1001 recurse-directive: This directive indicates whether a proxy 1002 server receiving a 3xx response should send requests to the 1003 addresses listed in the response (i.e., recurse), or 1004 forward the list of addresses upstream towards the caller. 1005 The directive is ignored if "redirect" has been requested. 1007 parallel-directive: For a forking proxy server, this directive 1008 indicates whether the caller would like the proxy server to 1009 proxy the request to all known addresses at once, or go 1010 through them sequentially, contacting the next address only 1011 after it has received a non-2xx or non-6xx final response 1012 for the previous one. The directive is ignored if 1013 "redirect" has been requested. 1015 queue-directive: If the called party is temporarily unreachable, 1016 e.g., because it is in another call, the caller can 1017 indicate that it wants to have its call queued rather than 1018 rejected immediately. If the call is queued, the server 1019 returns "182 Queued". A queued call can be terminated as 1020 described in [1]. 1022 Example: 1024 Request-Disposition: proxy, recurse, parallel 1026 The set of request disposition directives is purposefully not 1027 extensible. This is to avoid a proliferation of new extensions to SIP 1028 that are "tunnelled" through this header field. 1030 8.2 Accept-Contact, Reject-Contact, and Require-Contact Header Fields 1032 The syntax for these header fields is described in Section 10. A 1033 compact form, with the letter a, has been defined for the Accept- 1034 Contact header field, and with the letter j for the Reject-Contact 1035 header field. 1037 The feature-tag is any valid feature tag, a number of which are 1038 applicable to SIP, and defined in Section 9. Note that string-value 1039 uses the qdtext production from RFC 3261. This production allows 1040 UTF-8 characters. This is in contrast to RFC 2533, which only allows 1041 ASCII characters in quoted strings. Usage of UTF-8 here is 1042 permissible since these values are never compared except using case 1043 sensitive matching rules. 1045 8.3 Contact Header Field 1047 This specification extends the Contact header field. In particular, 1048 it allows for the Contact header field parameter to include tag-set, 1049 whose BNF is described in Section 10. Tag-set is a set of feature 1050 parameters that describes the feature set of the UA associated with 1051 the URI in the Contact header field. 1053 It is important to note that there is no way to differentiate, by 1054 syntax, Contact parameters that are part of tag-set or just other 1055 extensions. It turns out that this does not matter. If a proxy should 1056 mistakenly take a contact parameter used by another extension, and 1057 assume it is a feature parameter when its not, it will be ignored by 1058 the matching algorithm unless the same parameter appears in the 1059 Accept-Contact or Reject-Contact header fields. However, it won't 1060 ever appear in these header fields, since those header fields only 1061 ever contain feature parameters, and the parameter is not actually a 1062 feature parameter. 1064 9 Media Feature Tag Definitions 1066 This specification defines an initial set of media feature tags for 1067 use with this specification. New media feature tags MAY be registered 1068 with IANA, based on the process defined for feature tag registrations 1069 [4]. This section also serves as the IANA registration for these 1070 feature tags. 1072 Any registered feature tags MAY be used with this specification. 1073 However, several existing ones appear to be particularly applicable. 1074 These include the language feature tag [11], which can be used to 1075 specify the language of the human or automata represented by the UA, 1076 and the type feature tag [12], which can be used to specify the MIME 1077 types of the media formats supported by the UA. However, the usage of 1078 the audio, video, application, message, text and image feature tags 1079 (each of which indicate a top level media type supported by the UA) 1080 are preferred to indicating support for specific media formats. When 1081 the type feature tag is present, there SHOULD also be a feature tag 1082 present for the its top-level MIME type with a value of TRUE. In 1083 other words, if a UA indicates in a registration that it supports the 1084 video/H263 MIME type, it should also indicate that it supports video 1085 generally: 1087 Contact: sip:1.2.3.4;type="video/H263";video="TRUE" 1089 9.1 Attendant 1091 Media feature tag name: attendant 1093 ASN.1 Identifier: New assignment by IANA. 1095 Summary of the media feature indicated by this tag: This feature 1096 tag indicates that the device is an automated or human 1097 attendant that will answer if the actual user of the device 1098 is not available. 1100 Values appropriate for use with this feature tag: Boolean. 1102 The feature tag is intended primarily for use in the following 1103 applications, protocols, services, or negotiation 1104 mechanisms: This feature tag is most useful in a 1105 communications application, for describing the capabilities 1106 of a device, such as a phone or PDA. 1108 Examples of typical use: Routing a call to a phone that has an 1109 auto-attendant feature. 1111 Related standards or documents: RFC XXXX [[Note to IANA: Please 1112 replace XXXX with the RFC number of this specification.]] 1114 9.2 Audio 1116 Media feature tag name: audio 1118 ASN.1 Identifier: New assignment by IANA. 1120 Summary of the media feature indicated by this tag: This feature 1121 tag indicates that the device supports audio as a MIME 1122 media type. 1124 Values appropriate for use with this feature tag: Boolean. 1126 The feature tag is intended primarily for use in the following 1127 applications, protocols, services, or negotiation 1128 mechanisms: This feature tag is most useful in a 1129 communications application, for describing the capabilities 1130 of a device, such as a phone or PDA. 1132 Examples of typical use: Routing a call to a phone that can 1133 support audio. 1135 Related standards or documents: RFC XXXX [[Note to IANA: Please 1136 replace XXXX with the RFC number of this specification.]] 1138 9.3 Automata 1140 Media feature tag name: automata 1142 ASN.1 Identifier: New assignment by IANA. 1144 Summary of the media feature indicated by this tag: The automata 1145 feature tag is a boolean value that indicates whether the 1146 UA represents an automata (such as a voicemail server, 1147 conference server, or recording device) or a human. 1149 Values appropriate for use with this feature tag: Boolean. TRUE 1150 indicates that the UA represents an automata. 1152 The feature tag is intended primarily for use in the following 1153 applications, protocols, services, or negotiation 1154 mechanisms: This feature tag is most useful in a 1155 communications application, for describing the capabilities 1156 of a device, such as a phone or PDA. 1158 Examples of typical use: Choosing to communicate with a message 1159 recording device instead of a user. 1161 Related standards or documents: RFC XXXX [[Note to IANA: Please 1162 replace XXXX with the RFC number of this specification.]] 1164 9.4 Class 1166 Media feature tag name: class 1168 ASN.1 Identifier: New assignment by IANA. 1170 Summary of the media feature indicated by this tag: This feature 1171 tag indicates the setting, business or personal, in which a 1172 communications device is used. 1174 Values appropriate for use with this feature tag: Token with an 1175 equality relationship. Typical values include: 1177 business: The device is used for business communications. 1179 personal: The device is used for personal communications. 1181 The feature tag is intended primarily for use in the following 1182 applications, protocols, services, or negotiation 1183 mechanisms: This feature tag is most useful in a 1184 communications application, for describing the capabilities 1185 of a device, such as a phone or PDA. 1187 Examples of typical use: Choosing between a business phone and a 1188 home phone. 1190 Related standards or documents: RFC XXXX [[Note to IANA: Please 1191 replace XXXX with the RFC number of this specification.]] 1193 9.5 Duplex 1195 Media feature tag name: duplex 1197 ASN.1 Identifier: New assignment by IANA. 1199 Summary of the media feature indicated by this tag: The duplex 1200 media feature tag lists whether a communications device can 1201 simultaneously send and receive media ("full"), alternate 1202 between sending and receiving ("half"), can only receive 1203 ("receive-only") or only send ("send-only"). 1205 Values appropriate for use with this feature tag: Token with an 1206 equality relationship. Typical values include: 1208 full: The device can simultaneously send and receive media. 1210 half: The device can alternate between sending and 1211 receiving media. 1213 receive-only: The device can only receive media. 1215 send-only: The device can only send media. 1217 The feature tag is intended primarily for use in the following 1218 applications, protocols, services, or negotiation 1219 mechanisms: This feature tag is most useful in a 1220 communications application, for describing the capabilities 1221 of a device, such as a phone or PDA. 1223 Examples of typical use: Choosing to communicate with a 1224 broadcast server, as opposed to a regular phone, when 1225 making a call to hear an announcement. 1227 Related standards or documents: RFC XXXX [[Note to IANA: Please 1228 replace XXXX with the RFC number of this specification.]] 1230 9.6 Image 1232 Media feature tag name: image 1234 ASN.1 Identifier: New assignment by IANA. 1236 Summary of the media feature indicated by this tag: This feature 1237 tag indicates that the device supports image as a MIME 1238 media type. 1240 Values appropriate for use with this feature tag: Boolean. 1242 The feature tag is intended primarily for use in the following 1243 applications, protocols, services, or negotiation 1244 mechanisms: This feature tag is most useful in a 1245 communications application, for describing the capabilities 1246 of a device, such as a phone or PDA. 1248 Examples of typical use: Routing a call to a phone that can 1249 support image transfer. 1251 Related standards or documents: RFC XXXX [[Note to IANA: Please 1252 replace XXXX with the RFC number of this specification.]] 1254 9.7 Message 1256 Media feature tag name: message 1258 ASN.1 Identifier: New assignment by IANA. 1260 Summary of the media feature indicated by this tag: This feature 1261 tag indicates that the device supports message as a MIME 1262 media type. 1264 Values appropriate for use with this feature tag: Boolean. 1266 The feature tag is intended primarily for use in the following 1267 applications, protocols, services, or negotiation 1268 mechanisms: This feature tag is most useful in a 1269 communications application, for describing the capabilities 1270 of a device, such as a phone or PDA. 1272 Examples of typical use: Routing a call to a phone that can 1273 support messaging. 1275 Related standards or documents: RFC XXXX [[Note to IANA: Please 1276 replace XXXX with the RFC number of this specification.]] 1278 9.8 Mobility 1280 Media feature tag name: mobility 1282 ASN.1 Identifier: New assignment by IANA. 1284 Summary of the media feature indicated by this tag: The mobility 1285 feature tag indicates whether the device is fixed, 1286 wireless, or somewhere in-between. 1288 Values appropriate for use with this feature tag: Token with an 1289 equality relationship. Typical values include: 1291 fixed: The device is wired. 1293 mobile: The device is wireless. 1295 The feature tag is intended primarily for use in the following 1296 applications, protocols, services, or negotiation 1297 mechanisms: This feature tag is most useful in a 1298 communications application, for describing the capabilities 1299 of a device, such as a phone or PDA. 1301 Examples of typical use: Choosing to communicate with a wireless 1302 phone instead of a desktop phone. 1304 Related standards or documents: RFC XXXX [[Note to IANA: Please 1305 replace XXXX with the RFC number of this specification.]] 1307 9.9 Description 1309 Media feature tag name: description 1311 ASN.1 Identifier: New assignment by IANA. 1313 Summary of the media feature indicated by this tag: The 1314 description feature tag provides a textual description of 1315 the device. 1317 Values appropriate for use with this feature tag: String with an 1318 equality relationship. 1320 The feature tag is intended primarily for use in the following 1321 applications, protocols, services, or negotiation 1322 mechanisms: This feature tag is most useful in a 1323 communications application, for describing the capabilities 1324 of a device, such as a phone or PDA. 1326 Examples of typical use: Indicating that a device is of a 1327 certain make and model. 1329 Related standards or documents: RFC XXXX [[Note to IANA: Please 1330 replace XXXX with the RFC number of this specification.]] 1332 9.10 Event Packages 1334 Media feature tag name: events 1336 ASN.1 Identifier: New assignment by IANA. 1338 Summary of the media feature indicated by this tag: The event 1339 packages [7] supported by a SIP UA. The values for this tag 1340 equal the event package names that are registered by each 1341 event package. 1343 Values appropriate for use with this feature tag: Token with an 1344 equality relationship. Typical values include: 1346 presence: SIP event package for for user presence [20]. 1348 winfo: SIP event package for watcher information [21]. 1350 refer: The SIP REFER event package [22]. 1352 dialog: The SIP dialog event package [23]. 1354 conference: The SIP conference event package [24]. 1356 reg: The SIP registration event package [25]. 1358 message-summary: The SIP message summary event package 1359 [26]. 1361 The feature tag is intended primarily for use in the following 1362 applications, protocols, services, or negotiation 1363 mechanisms: This feature tag is most useful in a 1364 communications application, for describing the capabilities 1365 of a device, such as a phone or PDA. 1367 Examples of typical use: Choosing to communicate with a server 1368 that supports the message waiting event package, such as a 1369 voicemail server [26]. 1371 Related standards or documents: RFC XXXX [[Note to IANA: Please 1372 replace XXXX with the RFC number of this specification.]] 1374 9.11 Priority 1376 Media feature tag name: priority 1378 ASN.1 Identifier: New assignment by IANA. 1380 Summary of the media feature indicated by this tag: The priority 1381 feature tag indicates the call priorities the device is 1382 willing to handle. 1384 Values appropriate for use with this feature tag: An integer. 1385 Each integral value corresponds to one of the possible 1386 values of the Priority header field as specified in SIP 1387 [1]. The mapping is defined as: 1389 non-urgent: Integral value of 1. The device supports non- 1390 urgent calls. 1392 normal: Integral value of 2. The device supports normal 1393 calls. 1395 urgent: Integral value of 3. The device supports urgent 1396 calls. 1398 emergency: Integral value of 4. The device supports 1399 emergency calls. 1401 The feature tag is intended primarily for use in the following 1402 applications, protocols, services, or negotiation 1403 mechanisms: This feature tag is most useful in a 1404 communications application, for describing the capabilities 1405 of a device, such as a phone or PDA. 1407 Examples of typical use: Choosing to communicate with a the 1408 emergency cell phone of a user, instead of their regular 1409 phone. 1411 Related standards or documents: RFC XXXX [[Note to IANA: Please 1412 replace XXXX with the RFC number of this specification.]] 1414 9.12 Methods 1416 Media feature tag name: methods 1418 ASN.1 Identifier: New assignment by IANA. 1420 Summary of the media feature indicated by this tag: The methods 1421 (note the plurality) feature tag indicates the SIP methods 1422 supported by this UA. In this case, "supported" means that 1423 the UA can receive requests with this method. In that 1424 sense, it has the same connotation as the Allow header 1425 field. 1427 Values appropriate for use with this feature tag: Token with an 1428 equality relationship. Typical values include: 1430 INVITE: The SIP INVITE method [1]. 1432 ACK: The SIP ACK method [1]. 1434 BYE: The SIP BYE method [1]. 1436 CANCEL: The SIP CANCEL method [1]. 1438 OPTIONS: The SIP OPTIONS method [1]. 1440 REGISTER: The SIP REGISTER method [1]. 1442 INFO: The SIP INFO method [8]. 1444 UPDATE: The SIP UPDATE method [10]. 1446 SUBSCRIBE: The SIP SUBSCRIBE method [7]. 1448 NOTIFY: The SIP NOTIFY method [7]. 1450 PRACK: The SIP PRACK method [9]. 1452 MESSAGE: The SIP MESSAGE method [17]. 1454 The feature tag is intended primarily for use in the following 1455 applications, protocols, services, or negotiation 1456 mechanisms: This feature tag is most useful in a 1457 communications application, for describing the capabilities 1458 of a device, such as a phone or PDA. 1460 Examples of typical use: Choosing to communicate with a presence 1461 application on a PC, instead of a PC phone application. 1463 Related standards or documents: RFC XXXX [[Note to IANA: Please 1464 replace XXXX with the RFC number of this specification.]] 1466 9.13 Schemes 1468 Media feature tag name: schemes 1470 ASN.1 Identifier: New assignment by IANA. 1472 Summary of the media feature indicated by this tag: The set of 1473 URI schemes [13] that are supported by a UA. 1475 Values appropriate for use with this feature tag: Token with an 1476 equality relationship. Typical values include: 1478 sip: The SIP URI scheme [1]. 1480 sips: The SIPS URI scheme [1]. 1482 tel: The tel URI scheme [6]. 1484 http: The HTTP URI scheme [14]. 1486 https: The HTTPS URI scheme [27]. 1488 cid: The CID URI scheme [15]. 1490 The feature tag is intended primarily for use in the following 1491 applications, protocols, services, or negotiation 1492 mechanisms: This feature tag is most useful in a 1493 communications application, for describing the capabilities 1494 of a device, such as a phone or PDA. 1496 Examples of typical use: Choosing get redirected to a phone 1497 number when a called party is busy, rather than a web page. 1499 Related standards or documents: RFC XXXX [[Note to IANA: Please 1500 replace XXXX with the RFC number of this specification.]] 1502 9.14 Text 1504 Media feature tag name: text 1506 ASN.1 Identifier: New assignment by IANA. 1508 Summary of the media feature indicated by this tag: This feature 1509 tag indicates that the device supports text as a MIME media 1510 type. 1512 Values appropriate for use with this feature tag: Boolean. 1514 The feature tag is intended primarily for use in the following 1515 applications, protocols, services, or negotiation 1516 mechanisms: This feature tag is most useful in a 1517 communications application, for describing the capabilities 1518 of a device, such as a phone or PDA. 1520 Examples of typical use: Routing a call to a phone that can 1521 support text. 1523 Related standards or documents: RFC XXXX [[Note to IANA: Please 1524 replace XXXX with the RFC number of this specification.]] 1526 9.15 Video 1528 Media feature tag name: video 1530 ASN.1 Identifier: New assignment by IANA. 1532 Summary of the media feature indicated by this tag: This feature 1533 tag indicates that the device supports video as a MIME 1534 media type. 1536 Values appropriate for use with this feature tag: Boolean. 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: Routing a call to a phone that can 1545 support video. 1547 Related standards or documents: RFC XXXX [[Note to IANA: Please 1548 replace XXXX with the RFC number of this specification.]] 1550 9.16 Voicemail 1552 Media feature tag name: voicemail 1554 ASN.1 Identifier: New assignment by IANA. 1556 Summary of the media feature indicated by this tag: This feature 1557 tag indicates that the device is a voicemail system which 1558 will record messages for a user. 1560 Values appropriate for use with this feature tag: Boolean. 1562 The feature tag is intended primarily for use in the following 1563 applications, protocols, services, or negotiation 1564 mechanisms: This feature tag is most useful in a 1565 communications application, for describing the capabilities 1566 of a device, such as a phone or PDA. 1568 Examples of typical use: Requesting that a call not be routed to 1569 voicemail. 1571 Related standards or documents: RFC XXXX [[Note to IANA: Please 1572 replace XXXX with the RFC number of this specification.]] 1574 10 Augmented BNF 1576 Request-Disposition = ( "Request-Disposition" | "d" ) HCOLON 1577 directive *(COMMA directive) 1578 directive = proxy-directive / cancel-directive / 1579 fork-directive / recurse-directive / 1580 parallel-directive / queue-directive) 1581 proxy-directive = "proxy" / "redirect" 1582 cancel-directive = "cancel" / "no-cancel" 1583 fork-directive = "fork" / "no-fork" 1584 recurse-directive = "recurse" / "no-recurse" 1585 parallel-directive = "parallel" / "sequential" 1586 queue-directive = "queue" / "no-queue" 1588 Accept-Contact = ("Accept-Contact" / "a") HCOLON feature-set 1589 *(COMMA feature-set) 1590 Reject-Contact = ("Reject-Contact" / "j") HCOLON feature-set-noq 1591 *(COMMA feature-set-noq) 1592 Require-Contact = "Require-Contact" 1593 HCOLON feature-set-noq *(COMMA feature-set-noq) 1594 feature-set = ( name-addr / addr-spec / "*") 1595 *(SEMI tag-set) [q-param] 1596 feature-set-noq = ( name-addr / addr-spec / "*") 1597 *(SEMI tag-set) 1598 tag-set = feature-tag EQUAL LDQUOT (tag-value-list 1599 / string-value / boolean / numeric) RDQUOT 1600 feature-tag = ftag ; From RFC 2533 1601 tag-value-list = tag-value *("," tag-value) 1602 tag-value = ["!"] token-nobang 1603 token-nobang = 1*(alphanum / "-" / "." / "%" / "*" 1604 / "_" / "+" / "`" / "'" / "~" ) 1605 boolean = "TRUE" / "FALSE" 1606 numeric = "#" (lessthan / greaterthan / equality / 1607 range) 1608 lessthan = ">=" number 1609 greaterthan = "<=" number 1610 equality = "=" number 1611 range = "R" number ".." number 1612 number = integer / rational 1613 integer = [ "+" / "-" ] 1*DIGIT 1614 rational = [ "+" / "-" ] 1*DIGIT "/" 1*DIGIT 1615 string-value = LDQUOT "<" qdtext ">" RDQUOT 1616 q-param = "q" EQUAL qvalue 1618 contact-params = c-p-q / c-p-expires / tag-set 1619 = / contact-extension 1621 11 Mapping Feature Parameters and Feature Set Predicates 1622 Mapping between feature parameters and feature set predicates, 1623 formatted according to the syntax of RFC 2533 [2] is trivial. 1625 Starting from a set of feature parameters, the procedure is as 1626 follows. Construct a conjunction. Each term in the conjunction 1627 derives from one feature parameter. If the feature parameter value is 1628 a comma separated list, the element of the conjunction is a 1629 disjunction. There is one term in the disjunction for each value in 1630 the comma separated list. Call each value a "phrase". If the feature 1631 parameter value was not a comma separate list, the term in the 1632 conjunction is obtained from the value. That value is also a 1633 "phrase". 1635 Consider now the construction of a filter from the phrase. If the 1636 phrase starts with a bang (!), the filter is of the form: 1638 (! (name=remainder)) 1640 where name is the name of the feature parameter, and remainder is the 1641 remainder of the text in the phrase after the bang. 1643 If the phrase starts with an octothorpe (#), the filter is a numeric 1644 comparison. The comparator is either =, >= or <= based on the next 1645 characters in the phrase. In this case, the filter is of the form: 1647 (name comparator remainder) 1649 where name is the name of the feature parameter, comparator is either 1650 =, >= or <=, and remainder is the remainder of the text in the phrase 1651 after the equal. 1653 If the value after the octothorpe is R, the filter is a range. The 1654 format of the filter is: 1656 (name=[remainder]) 1657 where name is the name of the feature parameter, and remainder is the 1658 remainder of the text in the phrase after the R. According to the 1659 BNF, this will be of the form "value..value", which specifies the 1660 range. 1662 If the phrase begins with a left angle bracket ("<") and ends with a 1663 right angle bracket (">"), this implies that the value is a string, 1664 rather than a token. This is converted to a filter of the form: 1666 (name="bracketed") 1668 where name is the name of the feature parameter, and bracketed is the 1669 text from the phrase between the left and right angle brackets. Note 1670 the explicit usage of quotes, which indicate that the value is a 1671 string. In RFC 2533, strings are compared using case sensitive rules, 1672 and tokens, case insensitive. 1674 In RFC 2533, when an feature tag value is unquoted, its a 1675 token, and when quoted, its a string. The comparison rules 1676 are case insensitive for the latter, and sensitive for the 1677 former. The presence of quotes, or lack thereof, is the 1678 means by which an implementation can tell whether to apply 1679 sensitive or insensitive comparison rules. In the syntax 1680 described here, we cannot use quoted strings, since there 1681 is already a quoted string around each contact parameter 1682 value. So, we use an angle bracket to signify that the 1683 value is to be interpreted as a case sensitive string. If 1684 no brackets are present, the proxy would perform matching 1685 operations in a case insensitive manner, and if they are 1686 present, case sensitive. 1688 Otherwise, the filter is of the following form: 1690 (name=phrase) 1692 where name is the name of the feature parameter, and phrase is the 1693 phrase. 1695 As an example, the Contact header: 1697 Contact:*;mobility="fixed";events="!presence,winfo";language="en,de" 1698 ;description="" 1700 would be converted to the following feature predicate: 1702 (& (mobility=fixed) 1703 (| (! (events=presence)) (events=winfo)) 1704 (| (language=en) (language=de)) 1705 (description="PC")) 1707 As another example, the following Accept-Contact header field: 1709 Accept-Contact: *;methods="SUBSCRIBE";resolution="#R5..100" 1711 would be converted to the following feature set predicate: 1713 (& (methods=SUBSCRIBE) 1714 (resolution=[5..100])) 1716 The conversion of an RFC 2533 formatted feature set to a set of 1717 feature parameters proceeds in the same way, but in reverse. The 1718 conversion can only be done for feature sets constrained as described 1719 in Section 6.1. 1721 12 Security Considerations 1723 The presence of caller preferences in a request has a significant 1724 effect on the ways in which the request is handled at a server. As a 1725 result, is is especially important that requests with caller 1726 preferences be authenticated and integrity-protected. The same holds 1727 true for registrations with feature parameters in the Contact header 1728 field. 1730 Processing of caller preferences requires set operations and searches 1731 which can require some amount of computation. This enables a DOS 1732 attack whereby a user can send requests with substantial numbers of 1733 caller preferences, in the hopes of overloading the server. To 1734 counter this, servers SHOULD reject requests with too many rules. A 1735 reasonable number is around 20. 1737 Feature sets contained in REGISTER requests can reveal sensitive 1738 information about a user or UA (for example, the languages spoken). 1739 If this information is sensitive, confidentiality SHOULD be provided 1740 by using S/MIME or the SIPS URI scheme, as described in RFC 3261 [1]. 1742 13 IANA Considerations 1744 There are a number of IANA considerations associated with this 1745 specification. 1747 13.1 Media Feature Tags 1749 This specification registers a number of new Media feature tags 1750 according to the procedures of RFC 2506 [4]. Those registrations are 1751 contained in Section 9, and are meant to be placed into the IETF tree 1752 for media feature tags. 1754 13.2 SIP Header Fields 1756 This specification registers four new SIP header fields, according to 1757 the process of RFC 3261 [1]. 1759 The following is the registration for the Accept-Contact header 1760 field: 1762 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number 1763 of this specification.] 1765 Header Field Name: Accept-Contact 1767 Compact Form: a 1769 The following is the registration for the Reject-Contact header 1770 field: 1772 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number 1773 of this specification.] 1775 Header Field Name: Reject-Contact 1777 Compact Form: j 1779 The following is the registration for the Require-Contact header 1780 field: 1782 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number 1783 of this specification.] 1785 Header Field Name: Require-Contact 1787 Compact Form: none defined 1789 The following is the registration for the Request-Disposition header 1790 field: 1792 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number 1793 of this specification.] 1795 Header Field Name: Request-Disposition 1797 Compact Form: d 1799 13.3 SIP Option Tags 1801 This specification registers a single SIP option tag, pref. The 1802 required information for this registration, as specified in RFC 3261, 1803 is: 1805 Name: pref 1807 Description: This option tag is used in a Proxy-Require header 1808 field by a UAC to ensure that caller preferences are 1809 honored at each proxy along the path. However, this usage 1810 is discouraged. It can also be used in the Require header 1811 field of a registration to ensure that the registrar 1812 supports the caller preferences extensions. 1814 14 Acknowledgements 1816 The initial set of media feature tags used by this specification were 1817 influenced by Scott Petrack's CMA design. Jonathan Lennox, and John 1818 Hearty provided helpful comments. Graham Klyne provided assistance on 1819 the usage of RFC 2533. Paul Kyzivat contributed significantly to this 1820 work, assisting in the generation of use cases, and poking holes in 1821 past versions of the document. 1823 15 Author's Addresses 1824 Jonathan Rosenberg 1825 dynamicsoft 1826 72 Eagle Rock Avenue 1827 First Floor 1828 East Hanover, NJ 07936 1829 email: jdrosen@dynamicsoft.com 1831 Henning Schulzrinne 1832 Columbia University 1833 M/S 0401 1834 1214 Amsterdam Ave. 1835 New York, NY 10027-7003 1836 email: schulzrinne@cs.columbia.edu 1838 16 Normative References 1840 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1841 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 1842 initiation protocol," RFC 3261, Internet Engineering Task Force, June 1843 2002. 1845 [2] G. Klyne, "A syntax for describing media feature sets," RFC 2533, 1846 Internet Engineering Task Force, Mar. 1999. 1848 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 1849 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 1851 [4] K. Holtman, A. Mutz, and T. Hardie, "Media feature tag 1852 registration procedure," RFC 2506, Internet Engineering Task Force, 1853 Mar. 1999. 1855 [5] G. Klyne, "Corrections to "A syntax for describing media feature 1856 sets"," RFC 2738, Internet Engineering Task Force, Dec. 1999. 1858 [6] A. Vaha-Sipila, "URLs for telephone calls," RFC 2806, Internet 1859 Engineering Task Force, Apr. 2000. 1861 [7] A. B. Roach, "Session initiation protocol (sip)-specific event 1862 notification," RFC 3265, Internet Engineering Task Force, June 2002. 1864 [8] S. Donovan, "The SIP INFO method," RFC 2976, Internet Engineering 1865 Task Force, Oct. 2000. 1867 [9] J. Rosenberg and H. Schulzrinne, "Reliability of provisional 1868 responses in session initiation protocol (SIP)," RFC 3262, Internet 1869 Engineering Task Force, June 2002. 1871 [10] J. Rosenberg, "The session initiation protocol (SIP) UPDATE 1872 method," RFC 3311, Internet Engineering Task Force, Oct. 2002. 1874 [11] P. Hoffman, "Registration of charset and languages media 1875 features tags," RFC 2987, Internet Engineering Task Force, Nov. 2000. 1877 [12] G. Klyne, "MIME content types in media feature expressions," RFC 1878 2913, Internet Engineering Task Force, Sept. 2000. 1880 [13] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 1881 identifiers (URI): generic syntax," RFC 2396, Internet Engineering 1882 Task Force, Aug. 1998. 1884 [14] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1885 Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," 1886 RFC 2616, Internet Engineering Task Force, June 1999. 1888 [15] E. Levinson, "Content-id and message-id uniform resource 1889 locators," RFC 2392, Internet Engineering Task Force, Aug. 1998. 1891 17 Informative References 1893 [16] J. Lennox and H. Schulzrinne, "Call processing language 1894 framework and requirements," RFC 2824, Internet Engineering Task 1895 Force, May 2000. 1897 [17] B. Campbell and J. Rosenberg, "Session initiation protocol 1898 extension for instant messaging," Internet Draft, Internet 1899 Engineering Task Force, Sept. 2002. Work in progress. 1901 [18] G. Klyne, "Protocol-independent content negotiation framework," 1902 RFC 2703, Internet Engineering Task Force, Sept. 1999. 1904 [19] M. Handley and V. Jacobson, "SDP: session description protocol," 1905 RFC 2327, Internet Engineering Task Force, Apr. 1998. 1907 [20] J. Rosenberg, "Session initiation protocol (SIP) extensions for 1908 presence," Internet Draft, Internet Engineering Task Force, May 2002. 1909 Work in progress. 1911 [21] J. Rosenberg, "A session initiation protocol (SIP)event 1912 template-package for watcher information," Internet Draft, Internet 1913 Engineering Task Force, May 2002. Work in progress. 1915 [22] R. Sparks, "The SIP refer method," Internet Draft, Internet 1916 Engineering Task Force, July 2002. Work in progress. 1918 [23] J. Rosenberg and H. Schulzrinne, "A session initiation protocol 1919 (SIP) event package for dialog state," Internet Draft, Internet 1920 Engineering Task Force, June 2002. Work in progress. 1922 [24] J. Rosenberg and H. Schulzrinne, "A session initiation protocol 1923 (SIP) event package for conference state," Internet Draft, Internet 1924 Engineering Task Force, June 2002. Work in progress. 1926 [25] J. Rosenberg, "A sip event package for registration state," 1927 Internet Draft, Internet Engineering Task Force, Oct. 2002. Work in 1928 progress. 1930 [26] R. Mahy, "A message summary and message waiting indication event 1931 package for the session initiation protocol (SIP)," Internet Draft, 1932 Internet Engineering Task Force, June 2002. Work in progress. 1934 [27] E. Rescorla, "HTTP over TLS," RFC 2818, Internet Engineering 1935 Task Force, May 2000. 1937 A Overview of RFC 2533 1939 This section provides a brief overview of RFC 2533 and related 1940 specifications that form the content negotiation framework. 1942 A critical concept in the framework is that of a feature set. A 1943 feature set is information about an entity (in our case, a UA), which 1944 describes a set of features it can handle. A feature set can be 1945 thought of as a region in N-dimensional space. Each dimension in this 1946 space is a different media feature, identified by a media feature 1947 tag. For example, one dimension (or axis) might represent languages, 1948 another might represent methods, and another, MIME types. A feature 1949 collection represents a single point in this space. It represents a 1950 particular rendering or instance of an entity (in our case, a UA). 1951 For example, a "rendering" of a UA would define an instantaneous mode 1952 of operation that it can support. One such rendering would be 1953 processing the INVITE method, which carried the application/sdp MIME 1954 type, sent to a UA for a user that is speaking English. 1956 A feature set can therefore be defined as a set of feature 1957 collections. In other words, a feature set is a region of N- 1958 dimensional feature-space, that region being defined by the union of 1959 points - feature collections - that make up the space. If a 1960 particular feature collection is in the space, it means that the 1961 rendering described by that feature collection is supported by the 1962 device with that feature set. 1964 How does one represent a feature set? There are many ways to describe 1965 an N-dimensional space. One way is to identify mathematical functions 1966 which identify its contours. Clearly, that is too complex to be 1967 useful. The solution taken in RFC 2533 is to define the space with a 1968 feature set predicate. A feature set predicate is a boolean function 1969 over an N-dimensional space. The input to the function is a point in 1970 that space - a feature collection. If the result of the boolean 1971 function is TRUE, the feature collection is a member of the space. If 1972 the result of the boolean function is FALSE, the feature collection 1973 is not in the space. 1975 RFC 2533 describes a syntax for writing down these N-dimensional 1976 boolean functions. It uses a prolog-style syntax which is fairly 1977 self-explanatory. This representation is called a feature set 1978 predicate. The base unit of the predicate is a filter, which is a 1979 boolean expression encased in round brackets. A filter can be 1980 complex, where it contains conjunctions and disjunctions of other 1981 filters, or it can be simple. A simple filter is one that expresses a 1982 comparison operation on a single media feature tag. 1984 For example, consider the feature set predicate: 1986 (& (foo=A) 1987 (bar=B) 1988 (| (baz=C) (& (baz=D) (bif=E)))) 1990 This defines a function over four media features - foo, bar, baz and 1991 bif. Any point in feature space with foo equal to A, bar equal to B, 1992 and either baz equal to C, or baz equal to D and bif equal to E, is 1993 in the feature set defined by this feature set predicate. 1995 Note that the predicate doesn't say anything about the number of 1996 dimensions in feature space. The predicate operates on a feature 1997 space of any number of dimensions, but only those dimensions labeled 1998 foo, bar, baz and bif matter. The result is that values of other 1999 media features don't matter. The feature collection 2000 foo=A,bar=B,baz=C,bop=F is in the feature set described by the 2001 predicate, even though the media feature tag "bop" isn't mentioned. 2002 Feature set predicates are therefore inclusive by default. A feature 2003 collection is present unless the boolean predicate rules it out. This 2004 was a conscious design choice in RFC 2533. 2006 RFC 2533 also talks about matching a preference with a capability 2007 set. This is accomplished by representing both with a feature set. A 2008 preference is a feature set - its a specification of a number of 2009 feature collections, any one of which would satisfy the requirements 2010 of the sender. A capability is also a feature set - its a 2011 specification of the feature collections that the recipient supports. 2012 There is a match when the spaces defined by both feature sets 2013 overlap. When there is overlap, there exists at least one feature 2014 collection that exists in both feature sets, and therefore a modality 2015 or rendering desired by the sender which is supported by the 2016 recipient. 2018 This leads directly to the definition of a match. Two feature sets 2019 match if there exists at least one feature collection present in both 2020 feature sets. 2022 Computing a match for two general feature set predicates is not easy. 2023 Section 5 of RFC 2533 presents an algorithm for doing it by expanding 2024 an arbitrary expression into disjunctive normal form. However, the 2025 feature set predicates used by this specification are constrained. 2026 They are always in conjunctive normal form, with each term in the 2027 conjunction describing values for different media features. This 2028 makes computation of a match easy. It is computed independently for 2029 each media feature, and then the feature sets overlap if media 2030 features specified in both sets overlap. Computing the overlap of a 2031 single media feature is very straightforward, and is a simple matter 2032 of computing whether two finite sets overlap. 2034 Full Copyright Statement 2036 Copyright (c) The Internet Society (2002). All Rights Reserved. 2038 This document and translations of it may be copied and furnished to 2039 others, and derivative works that comment on or otherwise explain it 2040 or assist in its implementation may be prepared, copied, published 2041 and distributed, in whole or in part, without restriction of any 2042 kind, provided that the above copyright notice and this paragraph are 2043 included on all such copies and derivative works. However, this 2044 document itself may not be modified in any way, such as by removing 2045 the copyright notice or references to the Internet Society or other 2046 Internet organizations, except as needed for the purpose of 2047 developing Internet standards in which case the procedures for 2048 copyrights defined in the Internet Standards process must be 2049 followed, or as required to translate it into languages other than 2050 English. 2052 The limited permissions granted above are perpetual and will not be 2053 revoked by the Internet Society or its successors or assigns. 2055 This document and the information contained herein is provided on an 2056 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2057 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2058 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2059 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2060 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.