idnits 2.17.1 draft-ietf-sip-callee-caps-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (June 23, 2003) is 7611 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 2327 (ref. '8') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3265 (ref. '9') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2396 (ref. '10') (Obsoleted by RFC 3986) == Outdated reference: A later version (-10) exists of draft-ietf-sip-callerprefs-08 == Outdated reference: A later version (-04) exists of draft-ietf-sipping-mwi-02 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-00 == Outdated reference: A later version (-09) exists of draft-ietf-ldapbis-filter-04 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: December 22, 2003 H. Schulzrinne 5 Columbia University 6 P. Kyzivat 7 Cisco Systems 8 June 23, 2003 10 Indicating User Agent Capabilities in the Session Initiation Protocol 11 (SIP) 12 draft-ietf-sip-callee-caps-00 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-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 http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 22, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This specification defines mechanisms by which a Session Initiation 43 Protocol (SIP) user agent can convey its capabilities and 44 characteristics to other user agents. These capabilities are conveyed 45 as parameters of the Contact header field. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 52 4. Usage of the Content Negotiation Framework . . . . . . . . . 7 53 5. Computing Capabilities . . . . . . . . . . . . . . . . . . . 8 54 6. Expressing Capabilities in a Registration . . . . . . . . . 11 55 7. Indicating Feature Sets in Remote Target URIs . . . . . . . 13 56 8. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . . 14 57 9. Contact Header Field . . . . . . . . . . . . . . . . . . . . 15 58 10. Media Feature Tag Definitions . . . . . . . . . . . . . . . 17 59 10.1 Attendant . . . . . . . . . . . . . . . . . . . . . . . . . 17 60 10.2 Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 61 10.3 Application . . . . . . . . . . . . . . . . . . . . . . . . 18 62 10.4 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 10.5 Control . . . . . . . . . . . . . . . . . . . . . . . . . . 19 64 10.6 Automata . . . . . . . . . . . . . . . . . . . . . . . . . . 20 65 10.7 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 66 10.8 Duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 67 10.9 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 22 68 10.10 Description . . . . . . . . . . . . . . . . . . . . . . . . 23 69 10.11 Event Packages . . . . . . . . . . . . . . . . . . . . . . . 23 70 10.12 Priority . . . . . . . . . . . . . . . . . . . . . . . . . . 24 71 10.13 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 25 72 10.14 SIP Extensions . . . . . . . . . . . . . . . . . . . . . . . 25 73 10.15 Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 26 74 10.16 Video . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 75 10.17 Message Server . . . . . . . . . . . . . . . . . . . . . . . 27 76 10.18 Is Focus . . . . . . . . . . . . . . . . . . . . . . . . . . 27 77 10.19 URI User . . . . . . . . . . . . . . . . . . . . . . . . . . 28 78 10.20 URI Domain . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 11. Security Considerations . . . . . . . . . . . . . . . . . . 30 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 81 12.1 Media Feature Tags . . . . . . . . . . . . . . . . . . . . . 31 82 12.2 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . . 31 83 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32 84 Normative References . . . . . . . . . . . . . . . . . . . . 33 85 Informative References . . . . . . . . . . . . . . . . . . . 34 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 87 A. Overview of RFC 2533 . . . . . . . . . . . . . . . . . . . . 36 88 Intellectual Property and Copyright Statements . . . . . . . 39 90 1. Introduction 92 Session Initiation Protocol (SIP) [1] user agents vary widely in 93 their capabilities and in the types of devices they represent. 94 Frequently, it is important for another SIP element to learn the 95 capabilities and characteristics of a SIP UA. Some of the 96 applications of this information include: 98 o One user agent, a PC-based application, is communicating with 99 another that is embedded in a limited-function device. The PC 100 would like to be able to "grey out" those components of the user 101 interface that represent features or capabilities not supported by 102 its peer. To do that, there needs to be a way to exchange 103 capability information within a dialog. 105 o A user has two devices at their disposal. One is a videophone, and 106 the other, a voice-only wireless phone. A caller wants to interact 107 with the user using video. As such, they would like their call 108 preferentially routed to the device which supports video. To do 109 this, the INVITE request can contain parameters that express a 110 preference for routing to a device with the specified capabilities 111 [11]. 113 o A network application would like to asynchronously send 114 information to a user agent in a MESSAGE [15] request. However, 115 before sending it, they would like to know if the UA has the 116 capabilites necessary to receive the message. To do that, they 117 would ideally query a user database managed by the domain which 118 holds such information. Population of such a database would 119 require that a UA convey its capabilities as part of its 120 registration. Thus, there is a need for conveying capabilities in 121 REGISTER requests. 123 SIP has some support for expression of capabilities. The Allow, 124 Accept, Accept-Language and Supported header fields convey some 125 information about the capabilities of a user agent. However, these 126 header fields convey only a small part of the information that is 127 needed. They do not provide a general framework for expression of 128 capabilities. Furthermore, they only specify capabilities indirectly; 129 the header fields really indicate the capabilities of the UA as they 130 apply to this request. 132 As a result, this specification provides a more general framework for 133 indication of capabilities in SIP. Capability information about a UA 134 is carried as parameters of the Contact header field. These 135 capabilities can be used within REGISTER requests and responses, 136 OPTIONS responses, and requests and responses that create dialogs 137 (such as INVITE). 139 2. Terminology 141 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 142 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 143 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 144 indicate requirement levels for compliant implementations. 146 3. Definitions 148 Feature: As defined in RFC 2703 [16], a piece of information about 149 the media handling properties of a message passing system 150 component or of a data resource. For example, the SIP methods 151 supported by a UA represent a feature. 153 Feature Tag: As defined in RFC 2703 [16], a feature tag is a name 154 that identifies a feature. An example is ``methods''. 156 Media Feature: As defined in RFC 2703, [16], a media feature is 157 information that indicates facilities assumed to be available for 158 the message content to be properly rendered or otherwise 159 presented. Media features are not intended to include information 160 that affects message transmission. 162 In the context of this specification, a media feature is 163 information that indicates facilities for handling SIP 164 requests, rather than specifically for content. In that sense, 165 it is used synonymously with feature. 167 Feature Collection: As defined in RFC 2533 [4], a feature collection 168 is a collection of different media features and associated values. 169 This might be viewed as describing a specific rendering of a 170 specific instance of a document or resource by a specific 171 recipient. 173 Feature Set: As defined in RFC 2703 [16], a feature set is 174 Information about a sender, recipient or other participant in a 175 message transfer which describes the set of features that it can 176 handle. Where a 'feature' describes a single identified attribute 177 of a resource, a 'feature set' describes a full set of possible 178 attributes. 180 Feature Parameters: A set of SIP header field parameters that can 181 appear in the Contact header field. The feature parameters 182 represent an encoding of a feature set. Each set of feature 183 parameters maps to a feature set predicate. 185 Capability: As defined in RFC 2703 [16], a capability is an attribute 186 of a sender or receiver (often the receiver) which indicates an 187 ability to generate or process a particular type of message 188 content. 190 Filter: A single expression in a feature set predicate. 192 Simple Filter: An expression in a feature predicate which is a 193 comparison (equality or inequality) of a feature tag against a 194 feature value. 196 Disjunction: A boolean OR operation across some number of terms. 198 Conjunction: A boolean AND operation across some number of terms. 200 Predicate: A boolean expression. 202 Feature Set Predicate: From RFC 2533 [4], a feature set predicate is 203 a function of an arbitrary feature collection value which returns 204 a Boolean result. A TRUE result is taken to mean that the 205 corresponding feature collection belongs to some set of media 206 feature handling capabilities defined by this predicate. 208 Contact Predicate: The feature set predicate associated with a URI 209 registered in the Contact header field of a REGISTER request. The 210 contact predicate is derived from the feature parameters in the 211 Contact header field. 213 4. Usage of the Content Negotiation Framework 215 This specification makes heavy use of the terminology and concepts in 216 the content negotiation work carried out within the IETF, and 217 documented in several RFCs. The ones relevant to this specification 218 are RFC 2506 [3] which provides a template for registering media 219 feature tags, RFC 2533 [4] which presents a syntax and matching 220 algorithm for media feature sets, RFC 2738 [5], which provides a 221 minor update to RFC 2533, and RFC 2703 [16] which provides a general 222 framework for content negotiation. 224 In case the reader does not have the time to read those 225 specifications, Appendix A provides a brief overview of the concepts 226 and terminology in those documents that is critical for understanding 227 this specification. 229 Since the content negotiation work was primarily meant to apply to 230 documents or other resources with a set of possible renderings, it is 231 not immediately apparent how it is used to model SIP user agents. A 232 feature set is composed of a set of feature collections, each of 233 which represents a specific rendering supported by the entity 234 described by the feature set. In the context of a SIP user agent, a 235 feature collection represents an instantaneous modality. That is, if 236 you look at the run time processing of a SIP UA, and take a snapshot 237 in time, the feature collection describes what it is doing at that 238 very instant. 240 This model is important, since it provides guidance on how to 241 determine whether something is a value for a particular feature tag, 242 or a feature tag by itself. If two properties can be exhibited by a 243 UA simultaneously, so that both are present in an instantaneous 244 modality, they need to be represented by separate media feature tags. 245 For example, a UA may be able to support some number of media types - 246 audio, video, and control. Should each of these be different values 247 for a single "media-types" feature tag, or should each of them be a 248 separate boolean feature tag? The model provides the answer. Since, 249 at any instance of time, a UA could be handling both audio and video, 250 they need to be separate media feature tags. However, the SIP methods 251 supported by a UA can each be represented as different values for the 252 same media feature tag (the "methods" tag), because fundamentally, a 253 UA processes a single request at a time. It may be multi-threading, 254 so that it appears that this is not so, but at a purely functional 255 level, it is true. 257 Clearly, there are weaknesses in this model, but it serves as a 258 useful guideline for applying the concepts of RFC 2533 to the problem 259 at hand. 261 5. Computing Capabilities 263 To construct a set of Contact header field parameters which indicate 264 capabilities, a UA constructs a feature predicate for that contact. 265 This process is described in terms of RFC 2533 [4] (and its minor 266 update, RFC 2738 [5]) syntax and constructs, followed by a conversion 267 to the syntax used in this specification. However, this represents a 268 logical flow of processing. There is no requirement that an 269 implementation actually use RFC 2533 syntax as an intermediate step. 271 A UA MAY use any feature tags that are registered through IANA in the 272 IETF or global trees [3]; this document registers several that are 273 appropriate for SIP. The feature tags discussed in this specification 274 are referred to as base tags. While other tags can be used, in order 275 to identify them as feature parameters (as opposed to parameters for 276 another SIP extension) they are encoded with a leading "+" sign in 277 the Contact header field. It is also permissible to use the URI tree 278 [3] for expressing vendor-specific feature tags. Feature tags in any 279 other trees created through IANA MAY also be used. 281 When using the "methods" feature tag, a UA MUST NOT include values 282 that correspond to methods not standardized in IETF standards track 283 RFCs. When using the "events" feature tag, a UA MUST NOT include 284 values that correspond to event packages not standardized in IETF 285 standards track RFCs. When using the "schemes" feature tag, a UA MUST 286 NOT include values that correspond to schemes not standardized in 287 IETF standards track RFCs. When using the "sip-extensions" feature 288 tag, a UA MUST NOT include values that correspond to option tags not 289 standardized in IETF standards track RFCs. 291 A UA SHOULD include the "uri-user" and "uri-domain" feature tag in 292 its contact predicate. The value of those tags SHOULD be equal to the 293 user and domain part of the registered URI, respectively. Setting 294 them differently is likely to result in odd behavior, and should only 295 be done if some unforseen service neccesitates it. Note that the 296 "uri-user" feature tag is a quoted string (implying case sensitive 297 matching), and the "uri-domain" feature tag is a token, implying case 298 insensitive matching. 300 Note that the "schemes" feature tag is not a peer of the "uri-user" 301 and "uri-domain" feature tags. That is, it does not indicate the 302 scheme of the registered URI. Rather, it indicates schemes that a UA 303 is capable of sending requests to, should such a URI be received in a 304 web page or Contact header field of a redirect response. 306 It is RECOMMENDED that a UA provide complete information in its 307 contact predicate. That is, it SHOULD provide information on as many 308 feature tags as possible. The mechanisms in this specification work 309 best when user agents register complete feature sets. Furthermore, 310 when a UA registers values for a particular feature tag, it MUST list 311 all values that it supports. For example, when including the 312 "methods" feature tag, a UA MUST list all methods it supports. 314 The contact predicate constructed by a UA MUST be an AND of terms 315 (called a conjunction). Each term is either an OR (called a 316 disjunction) of simple filters or negations of simple filters , or a 317 single simple filter or negation of a single filter. In the case of a 318 disjunction, each filter in the disjunction MUST indicate feature 319 values for the same feature tag (i.e., the disjunction represents a 320 set of values for a particular feature tag), and each element of the 321 conjunction MUST be for a different feature tag. Each simple filter 322 can be an equality, or in the case of numeric feature tags, an 323 inequality or range. This contact predicate is then converted to a 324 list of feature parameters, following the procedure outlined below. 326 The contact predicate is a conjunction of terms. Each term indicates 327 constraints on a single feature tag, and each term is represented by 328 a separate feature parameter. The name of this parameter depends on 329 the feature tag. Any forward slashes in the feature tag are converted 330 to a single quote, and any colons are converted to an exclamation 331 point. If the feature tag name is not amongst the base tags specified 332 in Section 9, a plus sign is added to the front of the feature 333 parameter name. The plus sign MUST NOT be added if the feature tag 334 name is amongst the base tags. The result is the feature parameter 335 name. 337 The value of the feature parameter depends on the the term of the 338 conjunction. If the term is a boolean expression with value of true, 339 i.e., (audio=TRUE), the contact parameter has no value. If the term 340 of the conjunction is a disjunction, the value of the contact 341 parameter is a quoted string. The quoted string is a comma separated 342 list of strings, each one derived from one of the terms in the 343 disjunction. If the term of the conjunction is a negation, the value 344 of the contact parameter is a quoted string. The quoted string begins 345 with an exclamation point (!), and the remainder is constructed from 346 the expression being negated. 348 The remaining operation is to compute a string from a primitive 349 filter (i.e., no and, or, or nots). If the filter is a simple filter 350 that is performing a numeric comparison, the string starts with an 351 octothorpe (#), followed by the comparator in the filter (=, >, or 352 <), followed by the value from the filter. If the value from the 353 filter is expressed in rational form (X / Y), then X and Y are 354 divided, yielding a decimal number, and this decimal number is output 355 to the string. 357 RFC 2533 uses a fractional notation to describe rational numbers. 358 This specification use a decimal form. The above text merely 359 converts between the two representations. Practically speaking, 360 this conversion is not needed since the numbers are the same in 361 either case. However, it is described in case implementations wish 362 to directly plug the predicates generated by the rules in this 363 section into an RFC 2533 implementation. 365 If the filter is a range (foo=X..Y), the string is equal to X:Y, 366 where X and Y have been converted from fractional numbers (A / B) to 367 their decimal equivalent. 369 If the filter is an equality over a token or boolean, then that token 370 or boolean value ("TRUE" or "FALSE") is output to the string. 372 If the filter is an equality over a quoted string, the output is a 373 less than (<) followed by the quoted string, followed by a greater 374 than (>). 376 As an example, feature predicate: 378 (& (mobility=fixed) 379 (| (! (events=presence)) (events=winfo)) 380 (| (language=en) (language=de)) 381 (description="PC") 382 (newparam=TRUE) 383 (rangeparam=-4..5125/1000)) 385 would be converted into the following feature parameters: 387 mobility="fixed";events="!presence,winfo";language="en,de" 388 ;description="";+newparam;+rangeparam="#-4:+5.125" 390 6. Expressing Capabilities in a Registration 392 When a UA registers, it can choose to indicate a feature set 393 associated with a registered contact. Whether or not a UA does so 394 depends on what the registered URI represents. If the registered URI 395 represents a UA instance (the common case in registrations), a UA 396 compliant to this specification SHOULD indicate a feature set using 397 the mechanisms described here. If, however, the registered URI 398 represents an address-of-record, or some other resource that is not 399 representable by a single feature set, it SHOULD NOT include a 400 feature set. As an example, if a user wishes to forward calls from 401 sip:user1@example.com to sip:user2@example.org, it could generate a 402 registration that looks like, in part: 404 REGISTER sip:example.com SIP/2.0 405 To: sip:user1@example.com 406 Contact: sip:user2@example.org 408 In this case, the registered contact is not identifying a UA, but 409 rather, another address-of-record. In such a case, the registered 410 contact would not indicate a feature set. 412 However, in some cases a UA may wish to express feature parameters 413 for an address-of-record. One example is an AOR which represents a 414 mutliplicity of devices in a home network, and routes to a proxy 415 server in the user's home. Since all devices in the home are for 416 personal use, the AOR itself can be described with the 417 "class=personal" feature parameter. A registration that forwards 418 calls to this home AOR could make use of that feature parameter. 419 Generally speaking, a feature parameter can only be associated with 420 an address-of-record if all devices bound to that address-of-record 421 share the exact same set of values for that feature parameter. 423 The remainder of this section assumes that a UA would like to 424 associate a feature set with a contact that it is registering. This 425 feature set is constructed and converted to a series of Contact 426 header field parameters, as described in Section 5, and those feature 427 parameters are added to the the Contact header field value containing 428 the URI that the parameters apply to. 430 The REGISTER request MAY contain a Require header field with the 431 value "pref" if the client wants to be sure that the registrar 432 understands the extensions defined in this specification. This means 433 that the registrar will store the feature parameters, and make them 434 available to elements accessing the location service within the 435 domain. In absence of the Require header field, a registrar that does 436 not understand this extension will simply ignore the Contact header 437 field parameters. 439 If a UA registers against multiple separate addresses-of-record, and 440 the contacts registered for each have different capabilities, a UA 441 MUST use different URIs in each registration. This is so that the UA 442 can uniquely determine the feature set that is associated with the 443 request URI of an incoming request. 445 As an example, a UA that supports audio and video media types, is a 446 voicemail server, and is not mobile would construct a feature 447 predicate like this: 449 (& (audio=TRUE) 450 (video=TRUE) 451 (msgserver=TRUE) 452 (automata=TRUE) 453 (attendant=TRUE) 454 (mobility=fixed) 455 (| (methods=INVITE) (methods=BYE) (methods=OPTIONS) (methods=ACK) 456 (methods=CANCEL)) 457 (uri-user="user") 458 (uri-domain=host.example.com) 460 These would be converted into feature parameters and included in the 461 REGISTER request: 463 REGISTER sip:example.com SIP/2.0 464 From: sip:user@example.com;tag=asd98 465 To: sip:user@example.com 466 Call-ID: hh89as0d-asd88jkk@host.example.com 467 CSeq: 9987 REGISTER 468 Max-Forwards: 70 469 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 470 Contact: ;audio="TRUE";video="TRUE" 471 ;msgserver="TRUE";automata;attendant;mobility="fixed" 472 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 473 ;uri-user="" 474 ;uri-domain="host.example.com" 475 Content-Length: 0 477 Note that a voicemail server is usually an automata and an attendant, 478 as defined below. 480 7. Indicating Feature Sets in Remote Target URIs 482 Target refresh requests and responses are used to establish and 483 modify the remote target URI in a dialog. The remote target URI is 484 conveyed in the Contact header field. A UAC or UAS MAY add feature 485 parameters to the Contact header field value in target refresh 486 requests and responses, for the purpose of indicating the 487 capabilities of the UA. To do that, it constructs a set of feature 488 parameters according to the Section 5. These are then added as 489 Contact header field parameters in the request or response. 491 The feature parameters can be included in both initial requests and 492 mid-dialog requests, and MAY change mid-dialog to signal a change in 493 UA capabilities. 495 There is overlap in the caller preferences mechanism with the Allow, 496 Accept, Accept-Language, and Allow-Events [9] header fields, which 497 can also be used in target refresh requests. Specifically, the Allow 498 header field and "methods" feature tag indicate the same information. 499 The Accept header field and the "type" feature tag indicate the same 500 information. The Accept-Language header field and the "language" 501 feature tag indicate the same information. The Allow-Events header 502 field and the "events" feature tag indicate the same information. It 503 is possible that other header fields and feature tags defined in the 504 future may also overlap. When there exists a feature tag that 505 describes a capability that can also be represented with a SIP header 506 field, a UA MUST use the header field to describe the capability. A 507 UA receiving a message that contains both the header field and the 508 feature tag MUST use the header field, and not the feature tag. 510 8. OPTIONS Processing 512 When a UAS compliant to this specification receives an OPTIONS 513 request, it MAY add feature parameters to the Contact header field in 514 the OPTIONS response for the purpose of indicating the capabilities 515 of the UA. To do that, it constructs a set of feature parameters 516 according to Section 5. These are then added as Contact header field 517 parameters in OPTIONS response. Indeed, if feature parameters were 518 included in the registration generated by that UA, those same 519 parameters SHOULD be used in the OPTIONS response. 521 9. Contact Header Field 523 This specification extends the Contact header field. In particular, 524 it allows for the Contact header field parameters to include 525 feature-param. Feature-param is a feature parameter that describes a 526 feature of the UA associated with the URI in the Contact header 527 field. Feature parameters are identifiable because they either belong 528 to the well known set of base feature tags, or they begin with a plus 529 sign. 531 feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list 532 / string-value ) RDQUOT] 533 enc-feature-tag = base-tags / other-tags 534 base-tags = "attendant" / "audio" / "automata" / 535 "class" / "duplex" / "data" / 536 "control" / "mobility" / "description" / 537 "events" / "priority" / "methods" / 538 "schemes" / "application" / "video" / 539 "msgserver" / "language" / "type" / 540 "isfocus" / "uri-user" / "uri-domain" 541 other-tags = "+" ftag-name 542 ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / 543 "." / "-" / "%" ) 544 tag-value-list = tag-value *("," tag-value) 545 tag-value = ["!"] (token-nobang / boolean / numeric) 546 token-nobang = 1*(alphanum / "-" / "." / "%" / "*" 547 / "_" / "+" / "`" / "'" / "~" ) 548 boolean = "TRUE" / "FALSE" 549 numeric = "#" numeric-relation number 550 numeric-relation = ">=" / "<=" / "=" / (number ":") 551 number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] 552 string-value = "<" qdtext ">" 554 Note that the tag-value-list uses an actual comma instead of the 555 COMMA construction. Thats because it appears within a quoted string, 556 where line folding cannot take place. 558 The production for qdtext can be found in RFC 3261 [1]. 560 There are additional constraints on usage of feature-param that 561 cannot be represented in a BNF. There MUST only be one instance of 562 any feature tag in feature-param. Any numbers present in a feature 563 parameter MUST be representable using an ANSI C double. 565 The following production updates the one in RFC 3261 [1] for 566 contact-params: 568 contact-params = c-p-q / c-p-expires / feature-param 569 / contact-extension 571 10. Media Feature Tag Definitions 573 This specification defines an initial set of media feature tags for 574 use with this specification. New media feature tags SHOULD be 575 registered with IANA, based on the process defined for feature tag 576 registrations [3]. This section also serves as the IANA registration 577 for these feature tags. 579 Any registered feature tags MAY be used with this specification. 580 However, several existing ones appear to be particularly applicable. 581 These include the language feature tag [6], which can be used to 582 specify the language of the human or automata represented by the UA, 583 and the type feature tag [7], which can be used to specify the MIME 584 types of the media formats supported by the UA. However, the usage of 585 the audio, video, application, data and control feature tags (each of 586 which indicate a media type, as defined in RFC 2327 [8]) supported by 587 the UA are preferred to indicating support for specific media 588 formats. When the type feature tag is present, there SHOULD also be a 589 feature tag present for the its top-level MIME type with a value of 590 TRUE. In other words, if a UA indicates in a registration that it 591 supports the video/H263 MIME type, it should also indicate that it 592 supports video generally: 594 Contact: sip:192.0.2.1;type="video/H263";video="TRUE" 596 If a new SDP media type were to be defined, such as "message", a new 597 feature tag registration SHOULD be created for it. The name of the 598 feature tag MUST equal that of the media type, unless there is an 599 unlikely naming collision between the new media type and an existing 600 feature tag registration. As a result of this, implementations can 601 safely construct caller preferences and callee capabilities for the 602 new media type before it is registered, as long as there is no naming 603 conflict. 605 If a new media feature tag is registered with the intent of using 606 that tag with this specification, the registration is done for the 607 unencoded form of the tag (see Section Section 5). In other words, if 608 a new feature tag "foo" is registered, the IANA registration would be 609 for the tag "foo" and not "+foo". 611 10.1 Attendant 613 Media feature tag name: attendant 615 ASN.1 Identifier: New assignment by IANA. 617 Summary of the media feature indicated by this tag: This feature tag 618 indicates that the device is an automated or human attendant that 619 will answer if the actual user of the device is not available. 621 Values appropriate for use with this feature tag: Boolean. 623 The feature tag is intended primarily for use in the following 624 applications, protocols, services, or negotiation mechanisms: This 625 feature tag is most useful in a communications application, for 626 describing the capabilities of a device, such as a phone or PDA. 628 Examples of typical use: Routing a call to a phone that has an 629 auto-attendant feature. 631 Related standards or documents: RFC XXXX [[Note to IANA: Please 632 replace XXXX with the RFC number of this specification.]] 634 10.2 Audio 636 Media feature tag name: audio 638 ASN.1 Identifier: New assignment by IANA. 640 Summary of the media feature indicated by this tag: This feature tag 641 indicates that the device supports audio as a media type. 643 Values appropriate for use with this feature tag: Boolean. 645 The feature tag is intended primarily for use in the following 646 applications, protocols, services, or negotiation mechanisms: This 647 feature tag is most useful in a communications application, for 648 describing the capabilities of a device, such as a phone or PDA. 650 Examples of typical use: Routing a call to a phone that can support 651 audio. 653 Related standards or documents: RFC XXXX [[Note to IANA: Please 654 replace XXXX with the RFC number of this specification.]] 656 10.3 Application 658 Media feature tag name: application 660 ASN.1 Identifier: New assignment by IANA. 662 Summary of the media feature indicated by this tag: This feature tag 663 indicates that the device supports application as a media type. 664 This feature tag exists primarily for completeness. Since so many 665 MIME types are underneath application, indicating the ability to 666 support applications provides little useful information. In most 667 cases, the concrete MIME type is a better parameter to use in a 668 predicate representing a preference. 670 Values appropriate for use with this feature tag: Boolean. 672 The feature tag is intended primarily for use in the following 673 applications, protocols, services, or negotiation mechanisms: This 674 feature tag is most useful in a communications application, for 675 describing the capabilities of a device, such as a phone or PDA. 677 Examples of typical use: Routing a call to a phone that can supports 678 gaming application. 680 Related standards or documents: RFC XXXX [[Note to IANA: Please 681 replace XXXX with the RFC number of this specification.]] 683 10.4 Data 685 Media feature tag name: data 687 ASN.1 Identifier: New assignment by IANA. 689 Summary of the media feature indicated by this tag: This feature tag 690 indicates that the device supports data as a media type. 692 Values appropriate for use with this feature tag: Boolean. 694 The feature tag is intended primarily for use in the following 695 applications, protocols, services, or negotiation mechanisms: This 696 feature tag is most useful in a communications application, for 697 describing the capabilities of a device, such as a phone or PDA. 699 Examples of typical use: Routing a call to a phone that can supports 700 a data streaming application. 702 Related standards or documents: RFC XXXX [[Note to IANA: Please 703 replace XXXX with the RFC number of this specification.]] 705 10.5 Control 706 Media feature tag name: control 708 ASN.1 Identifier: New assignment by IANA. 710 Summary of the media feature indicated by this tag: This feature tag 711 indicates that the device supports control as a media type. 713 Values appropriate for use with this feature tag: Boolean. 715 The feature tag is intended primarily for use in the following 716 applications, protocols, services, or negotiation mechanisms: This 717 feature tag is most useful in a communications application, for 718 describing the capabilities of a device, such as a phone or PDA. 720 Examples of typical use: Routing a call to a phone that can supports 721 a floor control application. 723 Related standards or documents: RFC XXXX [[Note to IANA: Please 724 replace XXXX with the RFC number of this specification.]] 726 10.6 Automata 728 Media feature tag name: automata 730 ASN.1 Identifier: New assignment by IANA. 732 Summary of the media feature indicated by this tag: The automata 733 feature tag is a boolean value that indicates whether the UA 734 represents an automata (such as a voicemail server, conference 735 server, IVR, or recording device) or a human. 737 Values appropriate for use with this feature tag: Boolean. TRUE 738 indicates that the UA represents an automata. 740 The feature tag is intended primarily for use in the following 741 applications, protocols, services, or negotiation mechanisms: This 742 feature tag is most useful in a communications application, for 743 describing the capabilities of a device, such as a phone or PDA. 745 Examples of typical use: Choosing to communicate with a message 746 recording device instead of a user. 748 Related standards or documents: RFC XXXX [[Note to IANA: Please 749 replace XXXX with the RFC number of this specification.]] 751 10.7 Class 753 Media feature tag name: class 755 ASN.1 Identifier: New assignment by IANA. 757 Summary of the media feature indicated by this tag: This feature tag 758 indicates the setting, business or personal, in which a 759 communications device is used. 761 Values appropriate for use with this feature tag: Token with an 762 equality relationship. Typical values include: 764 business: The device is used for business communications. 766 personal: The device is used for personal communications. 768 The feature tag is intended primarily for use in the following 769 applications, protocols, services, or negotiation mechanisms: This 770 feature tag is most useful in a communications application, for 771 describing the capabilities of a device, such as a phone or PDA. 773 Examples of typical use: Choosing between a business phone and a home 774 phone. 776 Related standards or documents: RFC XXXX [[Note to IANA: Please 777 replace XXXX with the RFC number of this specification.]] 779 10.8 Duplex 781 Media feature tag name: duplex 783 ASN.1 Identifier: New assignment by IANA. 785 Summary of the media feature indicated by this tag: The duplex media 786 feature tag lists whether a communications device can 787 simultaneously send and receive media ("full"), alternate between 788 sending and receiving ("half"), can only receive ("receive-only") 789 or only send ("send-only"). 791 Values appropriate for use with this feature tag: Token with an 792 equality relationship. Typical values include: 794 full: The device can simultaneously send and receive media. 796 half: The device can alternate between sending and receiving 797 media. 799 receive-only: The device can only receive media. 801 send-only: The device can only send media. 803 The feature tag is intended primarily for use in the following 804 applications, protocols, services, or negotiation mechanisms: This 805 feature tag is most useful in a communications application, for 806 describing the capabilities of a device, such as a phone or PDA. 808 Examples of typical use: Choosing to communicate with a broadcast 809 server, as opposed to a regular phone, when making a call to hear 810 an announcement. 812 Related standards or documents: RFC XXXX [[Note to IANA: Please 813 replace XXXX with the RFC number of this specification.]] 815 10.9 Mobility 817 Media feature tag name: mobility 819 ASN.1 Identifier: New assignment by IANA. 821 Summary of the media feature indicated by this tag: The mobility 822 feature tag indicates whether the device is fixed (meaning that it 823 is associated with a fixed point of contact with the network), or 824 mobile (meaning that it is not associated with a fixed point of 825 contact). Note that cordless phones are fixed, not mobile, based 826 on this definition. 828 Values appropriate for use with this feature tag: Token with an 829 equality relationship. Typical values include: 831 fixed: The device is stationary. 833 mobile: The device can move around with the user. 835 The feature tag is intended primarily for use in the following 836 applications, protocols, services, or negotiation mechanisms: This 837 feature tag is most useful in a communications application, for 838 describing the capabilities of a device, such as a phone or PDA. 840 Examples of typical use: Choosing to communicate with a wireless 841 phone instead of a desktop phone. 843 Related standards or documents: RFC XXXX [[Note to IANA: Please 844 replace XXXX with the RFC number of this specification.]] 846 10.10 Description 848 Media feature tag name: description 850 ASN.1 Identifier: New assignment by IANA. 852 Summary of the media feature indicated by this tag: The description 853 feature tag provides a textual description of the device. 855 Values appropriate for use with this feature tag: String with an 856 equality relationship. 858 The feature tag is intended primarily for use in the following 859 applications, protocols, services, or negotiation mechanisms: This 860 feature tag is most useful in a communications application, for 861 describing the capabilities of a device, such as a phone or PDA. 863 Examples of typical use: Indicating that a device is of a certain 864 make and model. 866 Related standards or documents: RFC XXXX [[Note to IANA: Please 867 replace XXXX with the RFC number of this specification.]] 869 10.11 Event Packages 871 Media feature tag name: events 873 ASN.1 Identifier: New assignment by IANA. 875 Summary of the media feature indicated by this tag: The event 876 packages [9] supported by a SIP UA. The values for this tag equal 877 the event package names that are registered by each event package. 879 Values appropriate for use with this feature tag: Token with an 880 equality relationship. Values are taken from the IANA SIP Event 881 types namespace registry. 883 The feature tag is intended primarily for use in the following 884 applications, protocols, services, or negotiation mechanisms: This 885 feature tag is most useful in a communications application, for 886 describing the capabilities of a device, such as a phone or PDA. 888 Examples of typical use: Choosing to communicate with a server that 889 supports the message waiting event package, such as a voicemail 890 server [12]. 892 Related standards or documents: RFC XXXX [[Note to IANA: Please 893 replace XXXX with the RFC number of this specification.]] 895 10.12 Priority 897 Media feature tag name: priority 899 ASN.1 Identifier: New assignment by IANA. 901 Summary of the media feature indicated by this tag: The priority 902 feature tag indicates the call priorities the device is willing to 903 handle. A value of X means that the device is willing to take 904 requests with priority X and higher. 906 Values appropriate for use with this feature tag: An integer. Each 907 integral value corresponds to one of the possible values of the 908 Priority header field as specified in SIP [1]. The mapping is 909 defined as: 911 non-urgent: Integral value of 10. The device supports non-urgent 912 calls. 914 normal: Integral value of 20. The device supports normal calls. 916 urgent: Integral value of 30. The device supports urgent calls. 918 emergency: Integral value of 40. The device supports calls in the 919 case of an emergency situation. 921 The feature tag is intended primarily for use in the following 922 applications, protocols, services, or negotiation mechanisms: This 923 feature tag is most useful in a communications application, for 924 describing the capabilities of a device, such as a phone or PDA. 926 Examples of typical use: Choosing to communicate with the emergency 927 cell phone of a user. 929 Related standards or documents: RFC XXXX [[Note to IANA: Please 930 replace XXXX with the RFC number of this specification.]] 932 10.13 Methods 934 Media feature tag name: methods 936 ASN.1 Identifier: New assignment by IANA. 938 Summary of the media feature indicated by this tag: The methods (note 939 the plurality) feature tag indicates the SIP methods supported by 940 this UA. In this case, "supported" means that the UA can receive 941 requests with this method. In that sense, it has the same 942 connotation as the Allow header field. 944 Values appropriate for use with this feature tag: Token with an 945 equality relationship. Values are taken from the Methods table 946 defined in the IANA SIP parameters registry. 948 The feature tag is intended primarily for use in the following 949 applications, protocols, services, or negotiation mechanisms: This 950 feature tag is most useful in a communications application, for 951 describing the capabilities of a device, such as a phone or PDA. 953 Examples of typical use: Choosing to communicate with a presence 954 application on a PC, instead of a PC phone application. 956 Related standards or documents: RFC XXXX [[Note to IANA: Please 957 replace XXXX with the RFC number of this specification.]] 959 10.14 SIP Extensions 961 Media feature tag name: sip-extensions 963 ASN.1 Identifier: New assignment by IANA. 965 Summary of the media feature indicated by this tag: The 966 sip-extensions feature tag is a list of SIP extensions (each of 967 which is defined by an option-tag registered with IANA) that are 968 understood by the UA. Understood, in this context, means that the 969 option tag would be included in a Supported header field in a 970 request. 972 Values appropriate for use with this feature tag: Token with an 973 equality relationship. Values are taken from the option tags table 974 in the IANA SIP parameters registry. 976 The feature tag is intended primarily for use in the following 977 applications, protocols, services, or negotiation mechanisms: This 978 feature tag is most useful in a communications application, for 979 describing the capabilities of a device, such as a phone or PDA. 981 Examples of typical use: Choosing to communicate with a phone that 982 supports quality of service preconditions instead of one that does 983 not. 985 Related standards or documents: RFC XXXX [[Note to IANA: Please 986 replace XXXX with the RFC number of this specification.]] 988 10.15 Schemes 990 Media feature tag name: schemes 992 ASN.1 Identifier: New assignment by IANA. 994 Summary of the media feature indicated by this tag: The set of URI 995 schemes [10] that are supported by a UA. Supported implies, for 996 example, that the UA would know how to handle a URI of that scheme 997 in the Contact header field of a redirect response. 999 Values appropriate for use with this feature tag: Token with an 1000 equality relationship. Values are taken from the IANA URI scheme 1001 registry. 1003 The feature tag is intended primarily for use in the following 1004 applications, protocols, services, or negotiation mechanisms: This 1005 feature tag is most useful in a communications application, for 1006 describing the capabilities of a device, such as a phone or PDA. 1008 Examples of typical use: Choosing to get redirected to a phone number 1009 when a called party is busy, rather than a web page. 1011 Related standards or documents: RFC XXXX [[Note to IANA: Please 1012 replace XXXX with the RFC number of this specification.]] 1014 10.16 Video 1016 Media feature tag name: video 1018 ASN.1 Identifier: New assignment by IANA. 1020 Summary of the media feature indicated by this tag: This feature tag 1021 indicates that the device supports video as a media type. 1023 Values appropriate for use with this feature tag: Boolean. 1025 The feature tag is intended primarily for use in the following 1026 applications, protocols, services, or negotiation mechanisms: This 1027 feature tag is most useful in a communications application, for 1028 describing the capabilities of a device, such as a phone or PDA. 1030 Examples of typical use: Routing a call to a phone that can support 1031 video. 1033 Related standards or documents: RFC XXXX [[Note to IANA: Please 1034 replace XXXX with the RFC number of this specification.]] 1036 10.17 Message Server 1038 Media feature tag name: msgserver 1040 ASN.1 Identifier: New assignment by IANA. 1042 Summary of the media feature indicated by this tag: This feature tag 1043 indicates that the device is a messaging server which will record 1044 messages for a user. An example of such a device is a voicemail 1045 server. 1047 Values appropriate for use with this feature tag: Boolean. 1049 The feature tag is intended primarily for use in the following 1050 applications, protocols, services, or negotiation mechanisms: This 1051 feature tag is most useful in a communications application, for 1052 describing the capabilities of a device, such as a phone or PDA. 1054 Examples of typical use: Requesting that a call not be routed to 1055 voicemail. 1057 Related standards or documents: RFC XXXX [[Note to IANA: Please 1058 replace XXXX with the RFC number of this specification.]] 1060 10.18 Is Focus 1062 Media feature tag name: isfocus 1064 ASN.1 Identifier: New assignment by IANA. 1066 Summary of the media feature indicated by this tag: This feature tag 1067 indicates that the UA is a conference server, also known as a 1068 focus, and will mix together the media for all calls to the same 1069 URI [13]. 1071 Values appropriate for use with this feature tag: Boolean. 1073 The feature tag is intended primarily for use in the following 1074 applications, protocols, services, or negotiation mechanisms: This 1075 feature tag is most useful in a communications application, for 1076 describing the capabilities of a device, such as a phone or PDA. 1078 Examples of typical use: Indicating to a UA that the server it has 1079 connected to is a conference server. 1081 Related standards or documents: RFC XXXX [[Note to IANA: Please 1082 replace XXXX with the RFC number of this specification.]] 1084 10.19 URI User 1086 Media feature tag name: uri-user 1088 ASN.1 Identifier: New assignment by IANA. 1090 Summary of the media feature indicated by this tag: The uri-user 1091 feature tag provides the user part of the SIP URI that represents 1092 the device. 1094 Values appropriate for use with this feature tag: String with an 1095 equality relationship. 1097 The feature tag is intended primarily for use in the following 1098 applications, protocols, services, or negotiation mechanisms: This 1099 feature tag is most useful in a communications application, for 1100 describing the capabilities of a device, such as a phone or PDA. 1102 Examples of typical use: Requesting to route a call to a specific 1103 device, identified by a URI. 1105 Related standards or documents: RFC XXXX [[Note to IANA: Please 1106 replace XXXX with the RFC number of this specification.]] 1108 10.20 URI Domain 1110 Media feature tag name: uri-domain 1112 ASN.1 Identifier: New assignment by IANA. 1114 Summary of the media feature indicated by this tag: The uri-domain 1115 feature tag indicates the hostname of a device. 1117 Values appropriate for use with this feature tag: Token with a 1118 case-insensitive equality relationship. 1120 The feature tag is intended primarily for use in the following 1121 applications, protocols, services, or negotiation mechanisms: This 1122 feature tag is most useful in a communications application, for 1123 describing the capabilities of a device, such as a phone or PDA. 1125 Examples of typical use: Requesting to route a call to a specific 1126 device, identified by a URI. 1128 Related standards or documents: RFC XXXX [[Note to IANA: Please 1129 replace XXXX with the RFC number of this specification.]] 1131 11. Security Considerations 1133 Feature sets contained in REGISTER requests can reveal sensitive 1134 information about a user or UA (for example, the languages spoken). 1135 If this information is sensitive, confidentiality SHOULD be provided 1136 by using the SIPS URI scheme, as described in RFC 3261 [1]. 1138 12. IANA Considerations 1140 There are a number of IANA considerations associated with this 1141 specification. 1143 12.1 Media Feature Tags 1145 This specification registers a number of new Media feature tags 1146 according to the procedures of RFC 2506 [3]. Those registrations are 1147 contained in Section Section 10, and are meant to be placed into the 1148 IETF tree for media feature tags. 1150 12.2 SIP Option Tag 1152 This specification registers a single SIP option tag, pref. The 1153 required information for this registration, as specified in RFC 3261 1154 [1], is: 1156 Name: pref 1158 Description: This option tag is used in a Require header field of a 1159 registration to ensure that the registrar supports the caller 1160 preferences extensions. 1162 13. Acknowledgments 1164 The initial set of media feature tags used by this specification were 1165 influenced by Scott Petrack's CMA design. Jonathan Lennox, Bob 1166 Penfield, Ben Campbell, Mary Barnes, Rohan Mahy and John Hearty 1167 provided helpful comments. Graham Klyne provided assistance on the 1168 usage of RFC 2533. 1170 Normative References 1172 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1173 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1174 Session Initiation Protocol", RFC 3261, June 2002. 1176 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1177 Levels", BCP 14, RFC 2119, March 1997. 1179 [3] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag 1180 Registration Procedure", BCP 31, RFC 2506, March 1999. 1182 [4] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 1183 2533, March 1999. 1185 [5] Klyne, G., "Corrections to "A Syntax for Describing Media 1186 Feature Sets"", RFC 2738, December 1999. 1188 [6] Hoffman, P., "Registration of Charset and Languages Media 1189 Features Tags", RFC 2987, November 2000. 1191 [7] Klyne, G., "MIME Content Types in Media Feature Expressions", 1192 RFC 2913, September 2000. 1194 [8] Handley, M. and V. Jacobson, "SDP: Session Description 1195 Protocol", RFC 2327, April 1998. 1197 [9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1198 Notification", RFC 3265, June 2002. 1200 [10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1201 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1202 1998. 1204 Informative References 1206 [11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 1207 Preferences and Callee Capabilities for the Session Initiation 1208 Protocol (SIP)", draft-ietf-sip-callerprefs-08 (work in 1209 progress), March 2003. 1211 [12] Mahy, R., "A Message Summary and Message Waiting Indication 1212 Event Package for the Session Initiation Protocol (SIP)", 1213 draft-ietf-sipping-mwi-02 (work in progress), March 2003. 1215 [13] Rosenberg, J., "A Framework for Conferencing with the Session 1216 Initiation Protocol", 1217 draft-ietf-sipping-conferencing-framework-00 (work in 1218 progress), May 2003. 1220 [14] Howes, T. and M. Smith, "LDAP: String Representation of Search 1221 Filters", draft-ietf-ldapbis-filter-04 (work in progress), 1222 March 2003. 1224 [15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 1225 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1226 Instant Messaging", RFC 3428, December 2002. 1228 [16] Klyne, G., "Protocol-independent Content Negotiation 1229 Framework", RFC 2703, September 1999. 1231 Authors' Addresses 1233 Jonathan Rosenberg 1234 dynamicsoft 1235 600 Lanidex Plaza 1236 Parsippany, NJ 07054 1237 US 1239 Phone: +1 973 952-5000 1240 EMail: jdrosen@dynamicsoft.com 1241 URI: http://www.jdrosen.net 1242 Henning Schulzrinne 1243 Columbia University 1244 M/S 0401 1245 1214 Amsterdam Ave. 1246 New York, NY 10027 1247 US 1249 EMail: schulzrinne@cs.columbia.edu 1250 URI: http://www.cs.columbia.edu/~hgs 1252 Paul Kyzivat 1253 Cisco Systems 1254 Mail Stop LWL3/12/2 1255 900 Chelmsford St. 1256 Lowell, MA 01851 1257 US 1259 EMail: pkzivat@cisco.com 1261 Appendix A. Overview of RFC 2533 1263 This section provides a brief overview of RFC 2533 and related 1264 specifications that form the content negotiation framework. This 1265 section does not represent normative behavior. In the event of any 1266 conflict between the tutorial material here and the normative text in 1267 RFC 2533, RFC 2533 takes precedence. 1269 A critical concept in the framework is that of a feature set. A 1270 feature set is information about an entity (in our case, a UA), which 1271 describes a set of features it can handle. A feature set can be 1272 thought of as a region in N-dimensional space. Each dimension in this 1273 space is a different media feature, identified by a media feature 1274 tag. For example, one dimension (or axis) might represent languages, 1275 another might represent methods, and another, MIME types. A feature 1276 collection represents a single point in this space. It represents a 1277 particular rendering or instance of an entity (in our case, a UA). 1278 For example, a ``rendering'' of a UA would define an instantaneous 1279 mode of operation that it can support. One such rendering would be 1280 processing the INVITE method, which carried the application/sdp MIME 1281 type, sent to a UA for a user that is speaking English. 1283 A feature set can therefore be defined as a set of feature 1284 collections. In other words, a feature set is a region of 1285 N-dimensional feature-space, that region being defined by the set of 1286 points - feature collections - that make up the space. If a 1287 particular feature collection is in the space, it means that the 1288 rendering described by that feature collection is supported by the 1289 device with that feature set. 1291 How does one represent a feature set? There are many ways to describe 1292 an N-dimensional space. One way is to identify mathematical functions 1293 which identify its contours. Clearly, that is too complex to be 1294 useful. The solution taken in RFC 2533 is to define the space with a 1295 feature set predicate. A feature predicate defines a relation over 1296 an N-dimensional space; its input is any point in that space (i.e. a 1297 feature collection), and is true for all points that are in the 1298 region thus defined. 1300 RFC 2533 describes a syntax for writing down these N-dimensional 1301 boolean functions, borrowed from LDAP [14]. It uses a prolog-style 1302 syntax which is fairly self-explanatory. This representation is 1303 called a feature set predicate. The base unit of the predicate is a 1304 filter, which is a boolean expression encased in round brackets. A 1305 filter can be complex, where it contains conjunctions and 1306 disjunctions of other filters, or it can be simple. A simple filter 1307 is one that expresses a comparison operation on a single media 1308 feature tag. 1310 For example, consider the feature set predicate: 1312 (& (foo=A) 1313 (bar=B) 1314 (| (baz=C) (& (baz=D) (bif=E)))) 1316 This defines a function over four media features - foo, bar, baz and 1317 bif. Any point in feature space with foo equal to A, bar equal to B, 1318 and either baz equal to C, or baz equal to D and bif equal to E, is 1319 in the feature set defined by this feature set predicate. 1321 Note that the predicate doesn't say anything about the number of 1322 dimensions in feature space. The predicate operates on a feature 1323 space of any number of dimensions, but only those dimensions labeled 1324 foo, bar, baz and bif matter. The result is that values of other 1325 media features don't matter. The feature collection 1326 {foo=A,bar=B,baz=C,bop=F} is in the feature set described by the 1327 predicate, even though the media feature tag ``bop'' isn't mentioned. 1328 Feature set predicates are therefore inclusive by default. A feature 1329 collection is present unless the boolean predicate rules it out. This 1330 was a conscious design choice in RFC 2533. 1332 RFC 2533 also talks about matching a preference with a capability 1333 set. This is accomplished by representing both with a feature set. A 1334 preference is a feature set - its a specification of a number of 1335 feature collections, any one of which would satisfy the requirements 1336 of the sender. A capability is also a feature set - its a 1337 specification of the feature collections that the recipient supports. 1338 There is a match when the spaces defined by both feature sets 1339 overlap. When there is overlap, there exists at least one feature 1340 collection that exists in both feature sets, and therefore a modality 1341 or rendering desired by the sender which is supported by the 1342 recipient. 1344 This leads directly to the definition of a match. Two feature sets 1345 match if there exists at least one feature collection present in both 1346 feature sets. 1348 Computing a match for two general feature set predicates is not easy. 1349 Section 5 of RFC 2533 presents an algorithm for doing it by expanding 1350 an arbitrary expression into disjunctive normal form. However, the 1351 feature set predicates used by this specification are constrained. 1352 They are always in conjunctive normal form, with each term in the 1353 conjunction describing values for different media features. This 1354 makes computation of a match easy. It is computed independently for 1355 each media feature, and then the feature sets overlap if media 1356 features specified in both sets overlap. Computing the overlap of a 1357 single media feature is very straightforward, and is a simple matter 1358 of computing whether two finite sets overlap. 1360 Intellectual Property Statement 1362 The IETF takes no position regarding the validity or scope of any 1363 intellectual property or other rights that might be claimed to 1364 pertain to the implementation or use of the technology described in 1365 this document or the extent to which any license under such rights 1366 might or might not be available; neither does it represent that it 1367 has made any effort to identify any such rights. Information on the 1368 IETF's procedures with respect to rights in standards-track and 1369 standards-related documentation can be found in BCP-11. Copies of 1370 claims of rights made available for publication and any assurances of 1371 licenses to be made available, or the result of an attempt made to 1372 obtain a general license or permission for the use of such 1373 proprietary rights by implementors or users of this specification can 1374 be obtained from the IETF Secretariat. 1376 The IETF invites any interested party to bring to its attention any 1377 copyrights, patents or patent applications, or other proprietary 1378 rights which may cover technology that may be required to practice 1379 this standard. Please address the information to the IETF Executive 1380 Director. 1382 Full Copyright Statement 1384 Copyright (C) The Internet Society (2003). All Rights Reserved. 1386 This document and translations of it may be copied and furnished to 1387 others, and derivative works that comment on or otherwise explain it 1388 or assist in its implementation may be prepared, copied, published 1389 and distributed, in whole or in part, without restriction of any 1390 kind, provided that the above copyright notice and this paragraph are 1391 included on all such copies and derivative works. However, this 1392 document itself may not be modified in any way, such as by removing 1393 the copyright notice or references to the Internet Society or other 1394 Internet organizations, except as needed for the purpose of 1395 developing Internet standards in which case the procedures for 1396 copyrights defined in the Internet Standards process must be 1397 followed, or as required to translate it into languages other than 1398 English. 1400 The limited permissions granted above are perpetual and will not be 1401 revoked by the Internet Society or its successors or assignees. 1403 This document and the information contained herein is provided on an 1404 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1405 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1406 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1407 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1408 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1410 Acknowledgement 1412 Funding for the RFC Editor function is currently provided by the 1413 Internet Society.