idnits 2.17.1 draft-ietf-sip-callee-caps-03.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 (December 24, 2003) is 7426 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 (-04) exists of draft-ietf-sipping-mwi-03 == 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 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-01 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '18') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: June 23, 2004 H. Schulzrinne 5 Columbia University 6 P. Kyzivat 7 Cisco Systems 8 December 24, 2003 10 Indicating User Agent Capabilities in the Session Initiation Protocol 11 (SIP) 12 draft-ietf-sip-callee-caps-03 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 June 23, 2004. 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 and to the registrar for its 45 domain. This information is conveyed as parameters of the Contact 46 header field. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4. Usage of the Content Negotiation Framework . . . . . . . . . 8 54 5. Computing Capabilities . . . . . . . . . . . . . . . . . . . 9 55 6. Expressing Capabilities in a Registration . . . . . . . . . 12 56 7. Indicating Feature Sets in Remote Target URIs . . . . . . . 15 57 8. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . . 16 58 9. Contact Header Field . . . . . . . . . . . . . . . . . . . . 17 59 10. Media Feature Tag Definitions . . . . . . . . . . . . . . . 19 60 10.1 Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 61 10.2 Application . . . . . . . . . . . . . . . . . . . . . . . . 20 62 10.3 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 63 10.4 Control . . . . . . . . . . . . . . . . . . . . . . . . . . 21 64 10.5 Video . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 65 10.6 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 66 10.7 Automata . . . . . . . . . . . . . . . . . . . . . . . . . . 23 67 10.8 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 68 10.9 Duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 69 10.10 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 25 70 10.11 Description . . . . . . . . . . . . . . . . . . . . . . . . 26 71 10.12 Event Packages . . . . . . . . . . . . . . . . . . . . . . . 27 72 10.13 Priority . . . . . . . . . . . . . . . . . . . . . . . . . . 28 73 10.14 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 28 74 10.15 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 29 75 10.16 Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 30 76 10.17 Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 77 10.18 Is Focus . . . . . . . . . . . . . . . . . . . . . . . . . . 32 78 11. Security Considerations . . . . . . . . . . . . . . . . . . 33 79 11.1 Considerations for Media Feature Tags . . . . . . . . . . . 33 80 11.2 Considerations for Registrations . . . . . . . . . . . . . . 33 81 11.3 Considerations for OPTIONS Responses . . . . . . . . . . . . 34 82 11.4 Considerations for Dialog Initiating Messages . . . . . . . 34 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 84 12.1 SIP Media Feature Tag Registration Tree . . . . . . . . . . 35 85 12.2 Media Feature Tags . . . . . . . . . . . . . . . . . . . . . 35 86 12.3 SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . . 36 87 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 37 88 Normative References . . . . . . . . . . . . . . . . . . . . 38 89 Informative References . . . . . . . . . . . . . . . . . . . 39 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 91 A. Overview of RFC 2533 . . . . . . . . . . . . . . . . . . . . 41 92 Intellectual Property and Copyright Statements . . . . . . . 44 94 1. Introduction 96 Session Initiation Protocol (SIP) [1] user agents vary widely in 97 their capabilities and in the types of devices they represent. 98 Frequently, it is important for another SIP element to learn the 99 capabilities and characteristics of a SIP UA. Some of the 100 applications of this information include: 102 o One user agent, a PC-based application, is communicating with 103 another that is embedded in a limited-function device. The PC 104 would like to be able to "grey out" those components of the user 105 interface that represent features or capabilities not supported by 106 its peer. To do that, there needs to be a way to exchange 107 capability information within a dialog. 109 o A user has two devices at their disposal. One is a videophone, and 110 the other, a voice-only wireless phone. A caller wants to interact 111 with the user using video. As such, they would like their call 112 preferentially routed to the device which supports video. To do 113 this, the INVITE request can contain parameters that express a 114 preference for routing to a device with the specified capabilities 115 [11]. 117 o A network application would like to asynchronously send 118 information to a user agent in a MESSAGE [16] request. However, 119 before sending it, they would like to know if the UA has the 120 capabilites necessary to receive the message. To do that, they 121 would ideally query a user database managed by the domain which 122 holds such information. Population of such a database would 123 require that a UA convey its capabilities as part of its 124 registration. Thus, there is a need for conveying capabilities in 125 REGISTER requests. 127 SIP has some support for expression of capabilities. The Allow, 128 Accept, Accept-Language and Supported header fields convey some 129 information about the capabilities of a user agent. However, these 130 header fields convey only a small part of the information that is 131 needed. They do not provide a general framework for expression of 132 capabilities. Furthermore, they only specify capabilities indirectly; 133 the header fields really indicate the capabilities of the UA as they 134 apply to this request. SIP also has no ability to convey 135 characteristics; that is, information that describes a UA. 137 As a result, this specification provides a more general framework for 138 indication of capabilities and characteristics in SIP. Capability and 139 characteristic information about a UA is carried as parameters of the 140 Contact header field. These parameters can be used within REGISTER 141 requests and responses, OPTIONS responses, and requests and responses 142 that create dialogs (such as INVITE). 144 2. Terminology 146 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 147 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 148 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 149 indicate requirement levels for compliant implementations. 151 3. Definitions 153 Feature: As defined in RFC 2703 [17], a piece of information about 154 the media handling properties of a message passing system 155 component or of a data resource. For example, the SIP methods 156 supported by a UA represent a feature. 158 Feature Tag: As defined in RFC 2703 [17], a feature tag is a name 159 that identifies a feature. An example is ``sip.methods''. 161 Media Feature: As defined in RFC 2703, [17], a media feature is 162 information that indicates facilities assumed to be available for 163 the message content to be properly rendered or otherwise 164 presented. Media features are not intended to include information 165 that affects message transmission. 167 In the context of this specification, a media feature is 168 information that indicates facilities for handling SIP 169 requests, rather than specifically for content. In that sense, 170 it is used synonymously with feature. 172 Feature Collection: As defined in RFC 2533 [4], a feature collection 173 is a collection of different media features and associated values. 174 This might be viewed as describing a specific rendering of a 175 specific instance of a document or resource by a specific 176 recipient. 178 Feature Set: As defined in RFC 2703 [17], a feature set is 179 Information about a sender, recipient or other participant in a 180 message transfer which describes the set of features that it can 181 handle. Where a 'feature' describes a single identified attribute 182 of a resource, a 'feature set' describes a full set of possible 183 attributes. 185 Feature Parameters: A set of SIP header field parameters that can 186 appear in the Contact header field. The feature parameters 187 represent an encoding of a feature set. Each set of feature 188 parameters maps to a feature set predicate. 190 Capability: As defined in RFC 2703 [17], a capability is an attribute 191 of a sender or receiver (often the receiver) which indicates an 192 ability to generate or process a particular type of message 193 content. A capability is distinct from a characteristic in that a 194 capability may or may not be utilized in any particular call, 195 whereas a characteristic is a non-negotiable property of a UA. SIP 196 itself will often negotiate whether or not capabilities are used 197 in a call. 199 Characteristic: A characteristic is like a capability, but describes 200 an aspect of a UA which is not negotiable. As an example, whether 201 or not a UA is a mobile phone is a characteristic, not a 202 capability. The semantics of this specification do not 203 differentiate between capability and characteristic, but the 204 distinction is useful for illustrative purposes. Indeed, in the 205 text below, when we say "capability" it refers to both 206 capabilities and characteristics, unless the text explicitly says 207 otherwise. 209 Filter: A single expression in a feature set predicate. 211 Simple Filter: An expression in a feature predicate which is a 212 comparison (equality or inequality) of a feature tag against a 213 feature value. 215 Disjunction: A boolean OR operation across some number of terms. 217 Conjunction: A boolean AND operation across some number of terms. 219 Predicate: A boolean expression. 221 Feature Set Predicate: From RFC 2533 [4], a feature set predicate is 222 a function of an arbitrary feature collection value which returns 223 a Boolean result. A TRUE result is taken to mean that the 224 corresponding feature collection belongs to some set of media 225 feature handling capabilities defined by this predicate. 227 Contact Predicate: The feature set predicate associated with a URI 228 registered in the Contact header field of a REGISTER request. The 229 contact predicate is derived from the feature parameters in the 230 Contact header field. 232 4. Usage of the Content Negotiation Framework 234 This specification makes heavy use of the terminology and concepts in 235 the content negotiation work carried out within the IETF, and 236 documented in several RFCs. The ones relevant to this specification 237 are RFC 2506 [3] which provides a template for registering media 238 feature tags, RFC 2533 [4] which presents a syntax and matching 239 algorithm for media feature sets, RFC 2738 [5], which provides a 240 minor update to RFC 2533, and RFC 2703 [17] which provides a general 241 framework for content negotiation. 243 In case the reader does not have the time to read those 244 specifications, Appendix A provides a brief overview of the concepts 245 and terminology in those documents that is critical for understanding 246 this specification. 248 Since the content negotiation work was primarily meant to apply to 249 documents or other resources with a set of possible renderings, it is 250 not immediately apparent how it is used to model SIP user agents. A 251 feature set is composed of a set of feature collections, each of 252 which represents a specific rendering supported by the entity 253 described by the feature set. In the context of a SIP user agent, a 254 feature collection represents an instantaneous modality. That is, if 255 you look at the run time processing of a SIP UA, and take a snapshot 256 in time, the feature collection describes what it is doing at that 257 very instant. 259 This model is important, since it provides guidance on how to 260 determine whether something is a value for a particular feature tag, 261 or a feature tag by itself. If two properties can be exhibited by a 262 UA simultaneously, so that both are present in an instantaneous 263 modality, they need to be represented by separate media feature tags. 264 For example, a UA may be able to support some number of media types - 265 audio, video, and control. Should each of these be different values 266 for a single "media-types" feature tag, or should each of them be a 267 separate boolean feature tag? The model provides the answer. Since, 268 at any instance of time, a UA could be handling both audio and video, 269 they need to be separate media feature tags. However, the SIP methods 270 supported by a UA can each be represented as different values for the 271 same media feature tag (the "sip.methods" tag), because 272 fundamentally, a UA processes a single request at a time. It may be 273 multi-threading, so that it appears that this is not so, but at a 274 purely functional level, it is true. 276 Clearly, there are weaknesses in this model, but it serves as a 277 useful guideline for applying the concepts of RFC 2533 to the problem 278 at hand. 280 5. Computing Capabilities 282 To construct a set of Contact header field parameters which indicate 283 capabilities, a UA constructs a feature predicate for that contact. 284 This process is described in terms of RFC 2533 [4] (and its minor 285 update, RFC 2738 [5]) syntax and constructs, followed by a conversion 286 to the syntax used in this specification. However, this represents a 287 logical flow of processing. There is no requirement that an 288 implementation actually use RFC 2533 syntax as an intermediate step. 290 A UA MAY use any feature tags that are registered through IANA in the 291 SIP tree (Established in Section 12.1), IETF, or global trees [3]; 292 this document registers several into the SIP tree. The feature tags 293 discussed in this specification are referred to as base tags. While 294 other tags can be used, in order to identify them as feature 295 parameters (as opposed to parameters for another SIP extension) they 296 are encoded with a leading "+" sign in the Contact header field. It 297 is also permissible to use the URI tree [3] for expressing 298 vendor-specific feature tags. Feature tags in any other trees created 299 through IANA MAY also be used. 301 When using the "sip.methods" feature tag, a UA MUST NOT include 302 values that correspond to methods not standardized in IETF standards 303 track RFCs. When using the "sip.events" feature tag, a UA MUST NOT 304 include values that correspond to event packages not standardized in 305 IETF standards track RFCs. When using the "sip.schemes" feature tag, 306 a UA MUST NOT include values that correspond to schemes not 307 standardized in IETF standards track RFCs. When using the 308 "sip.extensions" feature tag, a UA MUST NOT include values that 309 correspond to option tags not standardized in IETF standards track 310 RFCs. 312 Note that the "sip.schemes" feature does not indicate the scheme of 313 the registered URI. Rather, it indicates schemes that a UA is capable 314 of sending requests to, should such a URI be received in a web page 315 or Contact header field of a redirect response. 317 It is RECOMMENDED that a UA provide complete information in its 318 contact predicate. That is, it SHOULD provide information on as many 319 feature tags as possible. The mechanisms in this specification work 320 best when user agents register complete feature sets. Furthermore, 321 when a UA registers values for a particular feature tag, it MUST list 322 all values that it supports. For example, when including the 323 "sip.methods" feature tag, a UA MUST list all methods it supports. 325 The contact predicate constructed by a UA MUST be an AND of terms 326 (called a conjunction). Each term is either an OR (called a 327 disjunction) of simple filters or negations of simple filters , or a 328 single simple filter or negation of a single filter. In the case of a 329 disjunction, each filter in the disjunction MUST indicate feature 330 values for the same feature tag (i.e., the disjunction represents a 331 set of values for a particular feature tag), and each element of the 332 conjunction MUST be for a different feature tag. Each simple filter 333 can be an equality, or in the case of numeric feature tags, an 334 inequality or range. This contact predicate is then converted to a 335 list of feature parameters, following the procedure outlined below. 337 The contact predicate is a conjunction of terms. Each term indicates 338 constraints on a single feature tag, and each term is represented by 339 a separate feature parameter. The name of this parameter depends on 340 the feature tag. Any forward slashes in the feature tag are converted 341 to a single quote, and any colons are converted to an exclamation 342 point. If the feature tag name is not amongst the base tags specified 343 in Section 9, a plus sign is added to the front of the feature 344 parameter name. The plus sign MUST NOT be added if the feature tag 345 name is amongst the base tags. If the feature tag name is amongst the 346 base tags, and it is present in the SIP registry, the leading "sip." 347 is removed from the name. The result is the feature parameter name. 349 The value of the feature parameter depends on the the term of the 350 conjunction. If the term is a boolean expression with value of true, 351 i.e., (audio=TRUE), the contact parameter has no value. If the term 352 of the conjunction is a disjunction, the value of the contact 353 parameter is a quoted string. The quoted string is a comma separated 354 list of strings, each one derived from one of the terms in the 355 disjunction. If the term of the conjunction is a negation, the value 356 of the contact parameter is a quoted string. The quoted string begins 357 with an exclamation point (!), and the remainder is constructed from 358 the expression being negated. 360 The remaining operation is to compute a string from a primitive 361 filter (i.e., no and, or, or nots). If the filter is a simple filter 362 that is performing a numeric comparison, the string starts with an 363 octothorpe (#), followed by the comparator in the filter (=, >=, or 364 <=), followed by the value from the filter. If the value from the 365 filter is expressed in rational form (X / Y), then X and Y are 366 divided, yielding a decimal number, and this decimal number is output 367 to the string. 369 RFC 2533 uses a fractional notation to describe rational numbers. 370 This specification use a decimal form. The above text merely 371 converts between the two representations. Practically speaking, 372 this conversion is not needed since the numbers are the same in 373 either case. However, it is described in case implementations wish 374 to directly plug the predicates generated by the rules in this 375 section into an RFC 2533 implementation. 377 If the filter is a range (foo=X..Y), the string is equal to X:Y, 378 where X and Y have been converted from fractional numbers (A / B) to 379 their decimal equivalent. 381 If the filter is an equality over a token or boolean, then that token 382 or boolean value ("TRUE" or "FALSE") is output to the string. 384 If the filter is an equality over a quoted string, the output is a 385 less than (<) followed by the quoted string, followed by a greater 386 than (>). 388 As an example, feature predicate: 390 (& (sip.mobility=fixed) 391 (| (! (sip.events=presence)) (sip.events=winfo)) 392 (| (language=en) (language=de)) 393 (sip.description="PC") 394 (sip.newparam=TRUE) 395 (rangeparam=-4..5125/1000)) 397 would be converted into the following feature parameters: 399 mobility="fixed";events="!presence,winfo";language="en,de" 400 ;description="";+sip.newparam;+rangeparam="#-4:+5.125" 402 6. Expressing Capabilities in a Registration 404 When a UA registers, it can choose to indicate a feature set 405 associated with a registered contact. Whether or not a UA does so 406 depends on what the registered URI represents. If the registered URI 407 represents a UA instance (the common case in registrations), a UA 408 compliant to this specification SHOULD indicate a feature set using 409 the mechanisms described here. If, however, the registered URI 410 represents an address-of-record, or some other resource that is not 411 representable by a single feature set, it SHOULD NOT include a 412 feature set. As an example, if a user wishes to forward calls from 413 sip:user1@example.com to sip:user2@example.org, it could generate a 414 registration that looks like, in part: 416 REGISTER sip:example.com SIP/2.0 417 To: sip:user1@example.com 418 Contact: sip:user2@example.org 420 In this case, the registered contact is not identifying a UA, but 421 rather, another address-of-record. In such a case, the registered 422 contact would not indicate a feature set. 424 However, in some cases a UA may wish to express feature parameters 425 for an address-of-record. One example is an AOR which represents a 426 mutliplicity of devices in a home network, and routes to a proxy 427 server in the user's home. Since all devices in the home are for 428 personal use, the AOR itself can be described with the 429 "sip.class=personal" feature parameter. A registration that forwards 430 calls to this home AOR could make use of that feature parameter. 431 Generally speaking, a feature parameter can only be associated with 432 an address-of-record if all devices bound to that address-of-record 433 share the exact same set of values for that feature parameter. 435 Similarly, in some cases, a UA can exhibit one characteristic or 436 another, but it is not known in advance which. For example, a UA 437 could represent a device that is a phone with an embedded answering 438 machine. The ideal way to treat such devices is to model them as if 439 they were actually a proxy fronting two devices - a phone (which is 440 never an answering machine), and an answering machine (which is never 441 a phone). The registration from this device would be constructed as 442 if it were an AOR, as per the procedures above. Generally, this means 443 that, unless the characteristic is identical between the logical 444 devices, that characteristic will not be present in any registration 445 generated by the actual device. 447 The remainder of this section assumes that a UA would like to 448 associate a feature set with a contact that it is registering. This 449 feature set is constructed and converted to a series of Contact 450 header field parameters, as described in Section 5, and those feature 451 parameters are added to the the Contact header field value containing 452 the URI that the parameters apply to. 454 The REGISTER request MAY contain a Require header field with the 455 value "pref" if the client wants to be sure that the registrar 456 understands the extensions defined in this specification. This means 457 that the registrar will store the feature parameters, and make them 458 available to elements accessing the location service within the 459 domain. In absence of the Require header field, a registrar that does 460 not understand this extension will simply ignore the Contact header 461 field parameters. 463 If a UA registers against multiple separate addresses-of-record, and 464 the contacts registered for each have different capabilities, a UA 465 MUST use different URIs in each registration. This is so that the UA 466 can uniquely determine the feature set that is associated with the 467 request URI of an incoming request. 469 As an example, a UA that supports audio and video media types, is a 470 voicemail server, and is not mobile would construct a feature 471 predicate like this: 473 (& (audio=TRUE) 474 (video=TRUE) 475 (sip.actor=msg-taker) 476 (sip.automata=TRUE) 477 (sip.mobility=fixed) 478 (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS) 479 (sip.methods=ACK) (sip.methods=CANCEL))) 481 These would be converted into feature parameters and included in the 482 REGISTER request: 484 REGISTER sip:example.com SIP/2.0 485 From: sip:user@example.com;tag=asd98 486 To: sip:user@example.com 487 Call-ID: hh89as0d-asd88jkk@host.example.com 488 CSeq: 9987 REGISTER 489 Max-Forwards: 70 490 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 491 Contact: ;audio;video 492 ;actor="msg-taker";automata;mobility="fixed" 493 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 494 Content-Length: 0 496 Note that a voicemail server is usually an automata and a message 497 taker. 499 7. Indicating Feature Sets in Remote Target URIs 501 Target refresh requests and responses are used to establish and 502 modify the remote target URI in a dialog. The remote target URI is 503 conveyed in the Contact header field. A UAC or UAS MAY add feature 504 parameters to the Contact header field value in target refresh 505 requests and responses, for the purpose of indicating the 506 capabilities of the UA. To do that, it constructs a set of feature 507 parameters according to the Section 5. These are then added as 508 Contact header field parameters in the request or response. 510 The feature parameters can be included in both initial requests and 511 mid-dialog requests, and MAY change mid-dialog to signal a change in 512 UA capabilities. 514 There is overlap in the callee capabilities mechanism with the Allow, 515 Accept, Accept-Language, and Allow-Events [9] header fields, which 516 can also be used in target refresh requests. Specifically, the Allow 517 header field and "sip.methods" feature tag indicate the same 518 information. The Accept header field and the "type" feature tag 519 indicate the same information. The Accept-Language header field and 520 the "language" feature tag indicate the same information. The 521 Allow-Events header field and the "sip.events" feature tag indicate 522 the same information. It is possible that other header fields and 523 feature tags defined in the future may also overlap. When there 524 exists a feature tag that describes a capability that can also be 525 represented with a SIP header field, a UA MUST use the header field 526 to describe the capability. A UA receiving a message that contains 527 both the header field and the feature tag MUST use the header field, 528 and not the feature tag. 530 8. OPTIONS Processing 532 When a UAS compliant to this specification receives an OPTIONS 533 request, it MAY add feature parameters to the Contact header field in 534 the OPTIONS response for the purpose of indicating the capabilities 535 of the UA. To do that, it constructs a set of feature parameters 536 according to Section 5. These are then added as Contact header field 537 parameters in OPTIONS response. Indeed, if feature parameters were 538 included in the registration generated by that UA, those same 539 parameters SHOULD be used in the OPTIONS response. 541 9. Contact Header Field 543 This specification extends the Contact header field. In particular, 544 it allows for the Contact header field parameters to include 545 feature-param. Feature-param is a feature parameter that describes a 546 feature of the UA associated with the URI in the Contact header 547 field. Feature parameters are identifiable because they either belong 548 to the well known set of base feature tags, or they begin with a plus 549 sign. 551 feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list 552 / string-value ) RDQUOT] 553 enc-feature-tag = base-tags / other-tags 554 base-tags = "audio" / "automata" / 555 "class" / "duplex" / "data" / 556 "control" / "mobility" / "description" / 557 "events" / "priority" / "methods" / 558 "schemes" / "application" / "video" / 559 "language" / "type" / "isfocus" / 560 "actor" / "text" 561 other-tags = "+" ftag-name 562 ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / 563 "." / "-" / "%" ) 564 tag-value-list = tag-value *("," tag-value) 565 tag-value = ["!"] (token-nobang / boolean / numeric) 566 token-nobang = 1*(alphanum / "-" / "." / "%" / "*" 567 / "_" / "+" / "`" / "'" / "~" ) 568 boolean = "TRUE" / "FALSE" 569 numeric = "#" numeric-relation number 570 numeric-relation = ">=" / "<=" / "=" / (number ":") 571 number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] 572 string-value = "<" qdtext ">" 574 Note that the tag-value-list uses an actual comma instead of the 575 COMMA construction. Thats because it appears within a quoted string, 576 where line folding cannot take place. 578 The production for qdtext can be found in RFC 3261 [1]. 580 There are additional constraints on usage of feature-param that 581 cannot be represented in a BNF. There MUST only be one instance of 582 any feature tag in feature-param. Any numbers present in a feature 583 parameter MUST be representable using an ANSI C double. 585 The following production updates the one in RFC 3261 [1] for 586 contact-params: 588 contact-params = c-p-q / c-p-expires / feature-param 589 / contact-extension 591 10. Media Feature Tag Definitions 593 This specification defines an initial set of media feature tags for 594 use with this specification. This section serves as the IANA 595 registration for these feature tags, which are made into the SIP 596 media feature tag tree. New media feature tags are registered in the 597 IETF or global trees based on the process defined for feature tag 598 registrations [3], or in the SIP tree based on the process defined in 599 Section 12.1. 601 Any registered feature tags MAY be used with this specification. 602 However, several existing ones appear to be particularly applicable. 603 These include the language feature tag [6], which can be used to 604 specify the language of the human or automata represented by the UA, 605 and the type feature tag [7], which can be used to specify the MIME 606 types that a SIP UA can receive in a SIP message. The audio, video, 607 application, data and control feature tags in the SIP tree (each of 608 which indicate a media type, as defined in RFC 2327 [8]) are 609 different. They do not indicate top level MIME types which can be 610 received in SIP requests. Rather, they indicate media types that can 611 be used in media streams, and as a result, match up with the types 612 defined in RFC 2327 [8]. 614 If a new SDP media type were to be defined, such as "message", a new 615 feature tag registration SHOULD be created for it in the SIP tree. 616 The name of the feature tag MUST equal that of the media type, unless 617 there is an unlikely naming collision between the new media type and 618 an existing feature tag registration. As a result of this, 619 implementations can safely construct caller preferences and callee 620 capabilities for the new media type before it is registered, as long 621 as there is no naming conflict. 623 If a new media feature tag is registered with the intent of using 624 that tag with this specification, the registration is done for the 625 unencoded form of the tag (see Section Section 5). In other words, if 626 a new feature tag "foo" is registered in the IETF tree, the IANA 627 registration would be for the tag "foo" and not "+foo". Similarly, if 628 a new feature tag "sip.gruu" is registered in the SIP tree, the IANA 629 registration would be for the tag "sip.gruu" and not "+sip.gruu". 631 The feature tags in this section are all registered into the SIP 632 media feature tag tree created by Section 12.1. 634 10.1 Audio 636 Media feature tag name: sip.audio 637 ASN.1 Identifier: New assignment by IANA. 639 Summary of the media feature indicated by this tag: This feature tag 640 indicates that the device supports audio as a streaming media 641 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 Security Considerations: Security considerations for this media 657 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 658 IANA: Please replace XXXX with the RFC number of this 659 specification.]] 661 10.2 Application 663 Media feature tag name: sip.application 665 ASN.1 Identifier: New assignment by IANA. 667 Summary of the media feature indicated by this tag: This feature tag 668 indicates that the device supports application as a streaming 669 media type. This feature tag exists primarily for completeness. 670 Since so many MIME types are underneath application, indicating 671 the ability to support applications provides little useful 672 information. 674 Values appropriate for use with this feature tag: Boolean. 676 The feature tag is intended primarily for use in the following 677 applications, protocols, services, or negotiation mechanisms: This 678 feature tag is most useful in a communications application, for 679 describing the capabilities of a device, such as a phone or PDA. 681 Examples of typical use: Routing a call to a phone that can supports 682 gaming application. 684 Related standards or documents: RFC XXXX [[Note to IANA: Please 685 replace XXXX with the RFC number of this specification.]] 687 Security Considerations: Security considerations for this media 688 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 689 IANA: Please replace XXXX with the RFC number of this 690 specification.]] 692 10.3 Data 694 Media feature tag name: sip.data 696 ASN.1 Identifier: New assignment by IANA. 698 Summary of the media feature indicated by this tag: This feature tag 699 indicates that the device supports data as a streaming media type. 701 Values appropriate for use with this feature tag: Boolean. 703 The feature tag is intended primarily for use in the following 704 applications, protocols, services, or negotiation mechanisms: This 705 feature tag is most useful in a communications application, for 706 describing the capabilities of a device, such as a phone or PDA. 708 Examples of typical use: Routing a call to a phone that can supports 709 a data streaming application. 711 Related standards or documents: RFC XXXX [[Note to IANA: Please 712 replace XXXX with the RFC number of this specification.]] 714 Security Considerations: Security considerations for this media 715 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 716 IANA: Please replace XXXX with the RFC number of this 717 specification.]] 719 10.4 Control 721 Media feature tag name: sip.control 723 ASN.1 Identifier: New assignment by IANA. 725 Summary of the media feature indicated by this tag: This feature tag 726 indicates that the device supports control as a streaming media 727 type. 729 Values appropriate for use with this feature tag: Boolean. 731 The feature tag is intended primarily for use in the following 732 applications, protocols, services, or negotiation mechanisms: This 733 feature tag is most useful in a communications application, for 734 describing the capabilities of a device, such as a phone or PDA. 736 Examples of typical use: Routing a call to a phone that can supports 737 a floor control application. 739 Related standards or documents: RFC XXXX [[Note to IANA: Please 740 replace XXXX with the RFC number of this specification.]] 742 Security Considerations: Security considerations for this media 743 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 744 IANA: Please replace XXXX with the RFC number of this 745 specification.]] 747 10.5 Video 749 Media feature tag name: sip.video 751 ASN.1 Identifier: New assignment by IANA. 753 Summary of the media feature indicated by this tag: This feature tag 754 indicates that the device supports video as a streaming media 755 type. 757 Values appropriate for use with this feature tag: Boolean. 759 The feature tag is intended primarily for use in the following 760 applications, protocols, services, or negotiation mechanisms: This 761 feature tag is most useful in a communications application, for 762 describing the capabilities of a device, such as a phone or PDA. 764 Examples of typical use: Routing a call to a phone that can support 765 video. 767 Related standards or documents: RFC XXXX [[Note to IANA: Please 768 replace XXXX with the RFC number of this specification.]] 770 Security Considerations: Security considerations for this media 771 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 772 IANA: Please replace XXXX with the RFC number of this 773 specification.]] 775 10.6 Text 777 Media feature tag name: sip.text 779 ASN.1 Identifier: New assignment by IANA. 781 Summary of the media feature indicated by this tag: This feature tag 782 indicates that the device supports text as a streaming media type. 784 Values appropriate for use with this feature tag: Boolean. 786 The feature tag is intended primarily for use in the following 787 applications, protocols, services, or negotiation mechanisms: This 788 feature tag is most useful in a communications application, for 789 describing the capabilities of a device, such as a phone or PDA. 791 Examples of typical use: Routing a call to a phone that can support 792 text. 794 Related standards or documents: RFC XXXX [[Note to IANA: Please 795 replace XXXX with the RFC number of this specification.]] 797 Security Considerations: Security considerations for this media 798 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 799 IANA: Please replace XXXX with the RFC number of this 800 specification.]] 802 10.7 Automata 804 Media feature tag name: sip.automata 806 ASN.1 Identifier: New assignment by IANA. 808 Summary of the media feature indicated by this tag: The sip.automata 809 feature tag is a boolean value that indicates whether the UA 810 represents an automata (such as a voicemail server, conference 811 server, IVR, or recording device) or a human. 813 Values appropriate for use with this feature tag: Boolean. TRUE 814 indicates that the UA represents an automata. 816 The feature tag is intended primarily for use in the following 817 applications, protocols, services, or negotiation mechanisms: This 818 feature tag is most useful in a communications application, for 819 describing the capabilities of a device, such as a phone or PDA. 821 Examples of typical use: Refusing to communicate with an automata 822 when it is known that automated services are unacceptable. 824 Related standards or documents: RFC XXXX [[Note to IANA: Please 825 replace XXXX with the RFC number of this specification.]] 827 Security Considerations: Security considerations for this media 828 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 829 IANA: Please replace XXXX with the RFC number of this 830 specification.]] 832 10.8 Class 834 Media feature tag name: sip.class 836 ASN.1 Identifier: New assignment by IANA. 838 Summary of the media feature indicated by this tag: This feature tag 839 indicates the setting, business or personal, in which a 840 communications device is used. 842 Values appropriate for use with this feature tag: Token with an 843 equality relationship. Typical values include: 845 business: The device is used for business communications. 847 personal: The device is used for personal communications. 849 The feature tag is intended primarily for use in the following 850 applications, protocols, services, or negotiation mechanisms: This 851 feature tag is most useful in a communications application, for 852 describing the capabilities of a device, such as a phone or PDA. 854 Examples of typical use: Choosing between a business phone and a home 855 phone. 857 Related standards or documents: RFC XXXX [[Note to IANA: Please 858 replace XXXX with the RFC number of this specification.]] 860 Security Considerations: Security considerations for this media 861 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 862 IANA: Please replace XXXX with the RFC number of this 863 specification.]] 865 10.9 Duplex 867 Media feature tag name: sip.duplex 869 ASN.1 Identifier: New assignment by IANA. 871 Summary of the media feature indicated by this tag: The sip.duplex 872 media feature tag indicates whether a communications device can 873 simultaneously send and receive media ("full"), alternate between 874 sending and receiving ("half"), can only receive ("receive-only") 875 or only send ("send-only"). 877 Values appropriate for use with this feature tag: Token with an 878 equality relationship. Typical values include: 880 full: The device can simultaneously send and receive media. 882 half: The device can alternate between sending and receiving 883 media. 885 receive-only: The device can only receive media. 887 send-only: The device can only send media. 889 The feature tag is intended primarily for use in the following 890 applications, protocols, services, or negotiation mechanisms: This 891 feature tag is most useful in a communications application, for 892 describing the capabilities of a device, such as a phone or PDA. 894 Examples of typical use: Choosing to communicate with a broadcast 895 server, as opposed to a regular phone, when making a call to hear 896 an announcement. 898 Related standards or documents: RFC XXXX [[Note to IANA: Please 899 replace XXXX with the RFC number of this specification.]] 901 Security Considerations: Security considerations for this media 902 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 903 IANA: Please replace XXXX with the RFC number of this 904 specification.]] 906 10.10 Mobility 908 Media feature tag name: sip.mobility 909 ASN.1 Identifier: New assignment by IANA. 911 Summary of the media feature indicated by this tag: The sip.mobility 912 feature tag indicates whether the device is fixed (meaning that it 913 is associated with a fixed point of contact with the network), or 914 mobile (meaning that it is not associated with a fixed point of 915 contact). Note that cordless phones are fixed, not mobile, based 916 on this definition. 918 Values appropriate for use with this feature tag: Token with an 919 equality relationship. Typical values include: 921 fixed: The device is stationary. 923 mobile: The device can move around with the user. 925 The feature tag is intended primarily for use in the following 926 applications, protocols, services, or negotiation mechanisms: This 927 feature tag is most useful in a communications application, for 928 describing the capabilities of a device, such as a phone or PDA. 930 Examples of typical use: Choosing to communicate with a wireless 931 phone instead of a desktop phone. 933 Related standards or documents: RFC XXXX [[Note to IANA: Please 934 replace XXXX with the RFC number of this specification.]] 936 Security Considerations: Security considerations for this media 937 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 938 IANA: Please replace XXXX with the RFC number of this 939 specification.]] 941 10.11 Description 943 Media feature tag name: sip.description 945 ASN.1 Identifier: New assignment by IANA. 947 Summary of the media feature indicated by this tag: The 948 sip.description feature tag provides a textual description of the 949 device. 951 Values appropriate for use with this feature tag: String with an 952 equality relationship. 954 The feature tag is intended primarily for use in the following 955 applications, protocols, services, or negotiation mechanisms: This 956 feature tag is most useful in a communications application, for 957 describing the capabilities of a device, such as a phone or PDA. 959 Examples of typical use: Indicating that a device is of a certain 960 make and model. 962 Related standards or documents: RFC XXXX [[Note to IANA: Please 963 replace XXXX with the RFC number of this specification.]] 965 Security Considerations: Security considerations for this media 966 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 967 IANA: Please replace XXXX with the RFC number of this 968 specification.]] 970 10.12 Event Packages 972 Media feature tag name: sip.events 974 ASN.1 Identifier: New assignment by IANA. 976 Summary of the media feature indicated by this tag: Each feature tag 977 value indicates a SIP event package [9] supported by a SIP UA. The 978 values for this tag equal the event package names that are 979 registered by each event package. 981 Values appropriate for use with this feature tag: Token with an 982 equality relationship. Values are taken from the IANA SIP Event 983 types namespace registry. 985 The feature tag is intended primarily for use in the following 986 applications, protocols, services, or negotiation mechanisms: This 987 feature tag is most useful in a communications application, for 988 describing the capabilities of a device, such as a phone or PDA. 990 Examples of typical use: Choosing to communicate with a server that 991 supports the message waiting event package, such as a voicemail 992 server [12]. 994 Related standards or documents: RFC XXXX [[Note to IANA: Please 995 replace XXXX with the RFC number of this specification.]] 997 Security Considerations: Security considerations for this media 998 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 999 IANA: Please replace XXXX with the RFC number of this 1000 specification.]] 1002 10.13 Priority 1004 Media feature tag name: sip.priority 1006 ASN.1 Identifier: New assignment by IANA. 1008 Summary of the media feature indicated by this tag: The sip.priority 1009 feature tag indicates the call priorities the device is willing to 1010 handle. A value of X means that the device is willing to take 1011 requests with priority X and higher. This does not imply that a 1012 phone has to reject calls of lower priority. As always, the 1013 decision on handling of such calls is a matter of local policy. 1015 Values appropriate for use with this feature tag: An integer. Each 1016 integral value corresponds to one of the possible values of the 1017 Priority header field as specified in SIP [1]. The mapping is 1018 defined as: 1020 non-urgent: Integral value of 10. The device supports non-urgent 1021 calls. 1023 normal: Integral value of 20. The device supports normal calls. 1025 urgent: Integral value of 30. The device supports urgent calls. 1027 emergency: Integral value of 40. The device supports calls in the 1028 case of an emergency situation. 1030 The feature tag is intended primarily for use in the following 1031 applications, protocols, services, or negotiation mechanisms: This 1032 feature tag is most useful in a communications application, for 1033 describing the capabilities of a device, such as a phone or PDA. 1035 Examples of typical use: Choosing to communicate with the emergency 1036 cell phone of a user. 1038 Related standards or documents: RFC XXXX [[Note to IANA: Please 1039 replace XXXX with the RFC number of this specification.]] 1041 Security Considerations: Security considerations for this media 1042 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 1043 IANA: Please replace XXXX with the RFC number of this 1044 specification.]] 1046 10.14 Methods 1047 Media feature tag name: sip.methods 1049 ASN.1 Identifier: New assignment by IANA. 1051 Summary of the media feature indicated by this tag: Each value of the 1052 sip.methods (note the plurality) feature tag indicates a SIP 1053 method supported by this UA. In this case, "supported" means that 1054 the UA can receive requests with this method. In that sense, it 1055 has the same connotation as the Allow header field. 1057 Values appropriate for use with this feature tag: Token with an 1058 equality relationship. Values are taken from the Methods table 1059 defined in the IANA SIP parameters registry. 1061 The feature tag is intended primarily for use in the following 1062 applications, protocols, services, or negotiation mechanisms: This 1063 feature tag is most useful in a communications application, for 1064 describing the capabilities of a device, such as a phone or PDA. 1066 Examples of typical use: Choosing to communicate with a presence 1067 application on a PC, instead of a PC phone application. 1069 Related standards or documents: RFC XXXX [[Note to IANA: Please 1070 replace XXXX with the RFC number of this specification.]] 1072 Security Considerations: Security considerations for this media 1073 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 1074 IANA: Please replace XXXX with the RFC number of this 1075 specification.]] 1077 10.15 Extensions 1079 Media feature tag name: sip.extensions 1081 ASN.1 Identifier: New assignment by IANA. 1083 Summary of the media feature indicated by this tag: Each value of the 1084 sip.extensions feature tag is a SIP extension (each of which is 1085 defined by an option-tag registered with IANA) that is understood 1086 by the UA. Understood, in this context, means that the option tag 1087 would be included in a Supported header field in a request. 1089 Values appropriate for use with this feature tag: Token with an 1090 equality relationship. Values are taken from the option tags table 1091 in the IANA SIP parameters registry. 1093 The feature tag is intended primarily for use in the following 1094 applications, protocols, services, or negotiation mechanisms: This 1095 feature tag is most useful in a communications application, for 1096 describing the capabilities of a device, such as a phone or PDA. 1098 Examples of typical use: Choosing to communicate with a phone that 1099 supports quality of service preconditions instead of one that does 1100 not. 1102 Related standards or documents: RFC XXXX [[Note to IANA: Please 1103 replace XXXX with the RFC number of this specification.]] 1105 Security Considerations: Security considerations for this media 1106 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 1107 IANA: Please replace XXXX with the RFC number of this 1108 specification.]] 1110 10.16 Schemes 1112 Media feature tag name: sip.schemes 1114 ASN.1 Identifier: New assignment by IANA. 1116 Summary of the media feature indicated by this tag: Each value of the 1117 sip.schemes (not the plurality) media feature tag indicates a URI 1118 scheme [10] that is supported by a UA. Supported implies, for 1119 example, that the UA would know how to handle a URI of that scheme 1120 in the Contact header field of a redirect response. 1122 Values appropriate for use with this feature tag: Token with an 1123 equality relationship. Values are taken from the IANA URI scheme 1124 registry. 1126 The feature tag is intended primarily for use in the following 1127 applications, protocols, services, or negotiation mechanisms: This 1128 feature tag is most useful in a communications application, for 1129 describing the capabilities of a device, such as a phone or PDA. 1131 Examples of typical use: Choosing to get redirected to a phone number 1132 when a called party is busy, rather than a web page. 1134 Related standards or documents: RFC XXXX [[Note to IANA: Please 1135 replace XXXX with the RFC number of this specification.]] 1137 Security Considerations: Security considerations for this media 1138 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 1139 IANA: Please replace XXXX with the RFC number of this 1140 specification.]] 1142 10.17 Actor 1144 Media feature tag name: sip.actor 1146 ASN.1 Identifier: New assignment by IANA. 1148 Summary of the media feature indicated by this tag: This feature tag 1149 indicates the type of entity that is available at this URI. 1151 Values appropriate for use with this feature tag: Token with an 1152 equality relationship. The following values are defined: 1154 principal: The device provides communication with the principal 1155 that is associated with the device. Often this will be a 1156 specific human being, but it can be an automata (for example, 1157 when calling a voice portal). 1159 attendant: The device provides communication with an automaton or 1160 person that will act as an intermediary in contacting the 1161 principal associated with the device, or a substitute. 1163 msg-taker: The device provides communication with an automaton or 1164 person that will take messages and deliver them to the 1165 principal. 1167 information: The device provides communication with an automaton 1168 or person that will provide information about the principal. 1170 The feature tag is intended primarily for use in the following 1171 applications, protocols, services, or negotiation mechanisms: This 1172 feature tag is most useful in a communications application, for 1173 describing the capabilities of a device, such as a phone or PDA. 1175 Examples of typical use: Requesting that a call not be routed to 1176 voicemail. 1178 Related standards or documents: RFC XXXX [[Note to IANA: Please 1179 replace XXXX with the RFC number of this specification.]] 1181 Security Considerations: Security considerations for this media 1182 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 1183 IANA: Please replace XXXX with the RFC number of this 1184 specification.]] 1186 10.18 Is Focus 1188 Media feature tag name: sip.isfocus 1190 ASN.1 Identifier: New assignment by IANA. 1192 Summary of the media feature indicated by this tag: This feature tag 1193 indicates that the UA is a conference server, also known as a 1194 focus, and will mix together the media for all calls to the same 1195 URI [13]. 1197 Values appropriate for use with this feature tag: Boolean. 1199 The feature tag is intended primarily for use in the following 1200 applications, protocols, services, or negotiation mechanisms: This 1201 feature tag is most useful in a communications application, for 1202 describing the capabilities of a device, such as a phone or PDA. 1204 Examples of typical use: Indicating to a UA that the server it has 1205 connected to is a conference server. 1207 Related standards or documents: RFC XXXX [[Note to IANA: Please 1208 replace XXXX with the RFC number of this specification.]] 1210 Security Considerations: Security considerations for this media 1211 feature tag are discussed in Section 11.1 of RFC XXXX . [[Note to 1212 IANA: Please replace XXXX with the RFC number of this 1213 specification.]] 1215 11. Security Considerations 1217 11.1 Considerations for Media Feature Tags 1219 This section discusses security considerations for the media feature 1220 tags, including, but not limited to, this specification. 1222 The media feature tags defined in Section 10 reveal sensitive 1223 information about a user or the user agent they are utilizing. Some 1224 of the feature tags convey capability information about the agent - 1225 for example, the media types it can support, the SIP methods it can 1226 support, and the SIP extensions it can support. This capability 1227 information might be used for industrial espionage, for example, and 1228 so its protection may be important. Other attributes, such as the 1229 mobility, priority and isfocus attributes, reveal characteristics of 1230 the user agent. These attributes are more sensitive than the 1231 capability information. They describe the way in which a user agent 1232 is utilized by a user, and thus reveal information about user 1233 preferences and the ways in which they want calls handled. Some 1234 feature tags, such as languages, reveal information about the user 1235 themself. As a result of this, applications which utilize these media 1236 feature tags SHOULD provide a means for ensuring their 1237 confidentiality. 1239 The media feature tags can be used in ways which affect application 1240 behaviors. For example, the SIP caller preferences extension [11] 1241 allows for call routing decisions to be based on the values of these 1242 parameters. Therefore, if an attacker can modify the values of these 1243 feature tags, they may be able to affect the behavior of 1244 applications. As a result of thihs, applications which utilize these 1245 media feature tags SHOULD provide a means for ensuring their 1246 integrity. Similarly, media feature tags should only be trusted as 1247 valid when they come from the user or user agent described by those 1248 feature tags. As a result, mechanisms for conveying feature tags 1249 SHOULD provide a mechanism for guaranteeing authenticity. 1251 11.2 Considerations for Registrations 1253 As per the general requirements in Section 11.1, when media feature 1254 tags are carried in a registration, authenticity, confidentiality and 1255 integrity need to be provided. To accomplish this, registrations 1256 containing capability information SHOULD be made by addressing the 1257 registration to a SIPS URI (in other words, the Request URI of the 1258 request would be sips:example.com when creating a registration in the 1259 example.com domain). Furthermore, the registrar SHOULD challenge the 1260 UA using digest over TLS, to verify its authenticity. The combination 1261 of TLS and digest provide integrity, confidentiality and 1262 authenticity, as required. 1264 It is not necessary for the Contact in the registration to itself 1265 contain a sips URI, since the feature tags are not carried in 1266 incoming requests sent to the UA. 1268 11.3 Considerations for OPTIONS Responses 1270 When including information on capabilities in a response to an 1271 OPTIONS request, a UA SHOULD verify with the user (either through a 1272 user interface or though aprior configuration) whether or not 1273 capability information should be divulged to the requestor. If the 1274 identity of the requestor cannot be cryptographically verified (using 1275 digest or the SIP identity enhancements [15]), the user SHOULD also 1276 be alerted to this fact, and be allowed to make a choice about 1277 whether such information should be divulged. 1279 If the user does wish to reveal capability information to the 1280 requestor, and wishes to guarantee its confidentiality, but the 1281 request did not arrive using SIPS, the UAS SHOULD redirect the 1282 request to a sips URI. This will cause the UAC to send the OPTIONS 1283 request using SIPS instead, and therefore provide confidentiality of 1284 any responses sent over the secure connections. 1286 Furthermore, S/MIME MAY be used in the OPTIONS response. In that 1287 case, the capability information would be contained only in the 1288 secured S/MIME body, and not in the header fields of the OPTIONS 1289 response. 1291 11.4 Considerations for Dialog Initiating Messages 1293 When a UAS generates a response that will initiate a dialog, and they 1294 wish to include capability information in the Contact header field, 1295 the same considerations as described in Section 11.3 apply. 1297 When a UAC generates a request that will initiate a dialog, it SHOULD 1298 obtain permission from the user (either through a user interface or 1299 apriori configuration) before including capability information in the 1300 Contact header field of the request. Confidentiality and integrity of 1301 the information SHOULD be provided using SIPS. S/MIME MAY be used. 1303 12. IANA Considerations 1305 There are a number of IANA considerations associated with this 1306 specification. 1308 12.1 SIP Media Feature Tag Registration Tree 1310 This specification serves to create a new media feature tag 1311 registration tree, per the guidelines of Section 3.1.4 of RFC2506 1312 [3]. The name of this tree is the "SIP Media Feature Tag Registration 1313 Tree", and its prefix is "sip.". It is used for registration of media 1314 feature tags that are applicable to the Session Initiation Protocol, 1315 and whose meaning is only defined within that usage. 1317 The addition of entries into this registry occurs through IETF 1318 consensus, as defined in RFC 2434 [18]. This requires publication of 1319 an RFC that contains the registration. The information required in 1320 the registration is identical to the IETF tree. As such, 1321 specifications adding entries to the registry should use the template 1322 provided in Section 3.4 of RFC 2506. 1324 12.2 Media Feature Tags 1326 This specification registers a number of new Media feature tags 1327 according to the procedures of RFC 2506 [3]. These registrations are 1328 all made into the newly created SIP tree for media feature tags. 1329 These registrations are: 1331 sip.audio: The information for registering the sip.audio media 1332 feature tag is contained in Section 10.1. 1334 sip.application: The information for registering the sip.application 1335 media feature tag is contained in Section 10.2. 1337 sip.data: The information for registering the sip.data media feature 1338 tag is contained in Section 10.3. 1340 sip.control: The information for registering the sip.control media 1341 feature tag is contained in Section 10.4. 1343 sip.video: The information for registering the sip.video media 1344 feature tag is contained in Section 10.5. 1346 sip.text: The information for registering the sip.text media feature 1347 tag is contained in Section 10.6. 1349 sip.automata: The information for registering the sip.automata media 1350 feature tag is contained in Section 10.7. 1352 sip.class: The information for registering the sip.class media 1353 feature tag is contained in Section 10.8. 1355 sip.duplex: The information for registering the sip.duplex media 1356 feature tag is contained in Section 10.9. 1358 sip.mobility: The information for registering the sip.mobility media 1359 feature tag is contained in Section 10.10. 1361 sip.description: The information for registering the sip.description 1362 media feature tag is contained in Section 10.11. 1364 sip.events: The information for registering the sip.events media 1365 feature tag is contained in Section 10.12. 1367 sip.priority: The information for registering the sip.priority media 1368 feature tag is contained in Section 10.13. 1370 sip.methods: The information for registering the sip.methods media 1371 feature tag is contained in Section 10.14. 1373 sip.extensions: The information for registering the sip.extensions 1374 media feature tag is contained in Section 10.15. 1376 sip.schemes: The information for registering the sip.schemes media 1377 feature tag is contained in Section 10.16. 1379 sip.actor: The information for registering the sip.actor media 1380 feature tag is contained in Section 10.17. 1382 sip.isfocus: The information for registering the sip.isfocus media 1383 feature tag is contained in Section 10.18. 1385 12.3 SIP Option Tag 1387 This specification registers a single SIP option tag, pref. The 1388 required information for this registration, as specified in RFC 3261 1389 [1], is: 1391 Name: pref 1393 Description: This option tag is used in a Require header field of a 1394 registration to ensure that the registrar supports the caller 1395 preferences extensions. 1397 13. Acknowledgments 1399 The initial set of media feature tags used by this specification were 1400 influenced by Scott Petrack's CMA design. Jonathan Lennox, Bob 1401 Penfield, Ben Campbell, Mary Barnes, Rohan Mahy and John Hearty 1402 provided helpful comments. Graham Klyne provided assistance on the 1403 usage of RFC 2533. Thanks to Allison Mankin for her comments and 1404 support, and to Ted Hardie for his guidance on usage of the media 1405 feature tags. 1407 Normative References 1409 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1410 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1411 Session Initiation Protocol", RFC 3261, June 2002. 1413 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1414 Levels", BCP 14, RFC 2119, March 1997. 1416 [3] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag 1417 Registration Procedure", BCP 31, RFC 2506, March 1999. 1419 [4] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 1420 2533, March 1999. 1422 [5] Klyne, G., "Corrections to "A Syntax for Describing Media 1423 Feature Sets"", RFC 2738, December 1999. 1425 [6] Hoffman, P., "Registration of Charset and Languages Media 1426 Features Tags", RFC 2987, November 2000. 1428 [7] Klyne, G., "MIME Content Types in Media Feature Expressions", 1429 RFC 2913, September 2000. 1431 [8] Handley, M. and V. Jacobson, "SDP: Session Description 1432 Protocol", RFC 2327, April 1998. 1434 [9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1435 Notification", RFC 3265, June 2002. 1437 [10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1438 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1439 1998. 1441 Informative References 1443 [11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 1444 Preferences for the Session Initiation Protocol (SIP)", 1445 draft-ietf-sip-callerprefs-10 (work in progress), October 2003. 1447 [12] Mahy, R., "A Message Summary and Message Waiting Indication 1448 Event Package for the Session Initiation Protocol (SIP)", 1449 draft-ietf-sipping-mwi-03 (work in progress), July 2003. 1451 [13] Rosenberg, J., "A Framework for Conferencing with the Session 1452 Initiation Protocol", 1453 draft-ietf-sipping-conferencing-framework-00 (work in 1454 progress), May 2003. 1456 [14] Howes, T. and M. Smith, "LDAP: String Representation of Search 1457 Filters", draft-ietf-ldapbis-filter-04 (work in progress), 1458 March 2003. 1460 [15] Peterson, J., "Enhancements for Authenticated Identity 1461 Management in the Session Initiation Protocol (SIP)", 1462 draft-ietf-sip-identity-01 (work in progress), March 2003. 1464 [16] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 1465 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1466 Instant Messaging", RFC 3428, December 2002. 1468 [17] Klyne, G., "Protocol-independent Content Negotiation 1469 Framework", RFC 2703, September 1999. 1471 [18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1472 Considerations Section in RFCs", BCP 26, RFC 2434, October 1473 1998. 1475 Authors' Addresses 1477 Jonathan Rosenberg 1478 dynamicsoft 1479 600 Lanidex Plaza 1480 Parsippany, NJ 07054 1481 US 1483 Phone: +1 973 952-5000 1484 EMail: jdrosen@dynamicsoft.com 1485 URI: http://www.jdrosen.net 1486 Henning Schulzrinne 1487 Columbia University 1488 M/S 0401 1489 1214 Amsterdam Ave. 1490 New York, NY 10027 1491 US 1493 EMail: schulzrinne@cs.columbia.edu 1494 URI: http://www.cs.columbia.edu/~hgs 1496 Paul Kyzivat 1497 Cisco Systems 1498 1414 Massachusetts Avenue 1499 BXB500 C2-2 1500 Boxboro, MA 01719 1501 US 1503 EMail: pkzivat@cisco.com 1505 Appendix A. Overview of RFC 2533 1507 This section provides a brief overview of RFC 2533 and related 1508 specifications that form the content negotiation framework. This 1509 section does not represent normative behavior. In the event of any 1510 conflict between the tutorial material here and the normative text in 1511 RFC 2533, RFC 2533 takes precedence. 1513 A critical concept in the framework is that of a feature set. A 1514 feature set is information about an entity (in our case, a UA), which 1515 describes a set of features it can handle. A feature set can be 1516 thought of as a region in N-dimensional space. Each dimension in this 1517 space is a different media feature, identified by a media feature 1518 tag. For example, one dimension (or axis) might represent languages, 1519 another might represent methods, and another, MIME types. A feature 1520 collection represents a single point in this space. It represents a 1521 particular rendering or instance of an entity (in our case, a UA). 1522 For example, a ``rendering'' of a UA would define an instantaneous 1523 mode of operation that it can support. One such rendering would be 1524 processing the INVITE method, which carried the application/sdp MIME 1525 type, sent to a UA for a user that is speaking English. 1527 A feature set can therefore be defined as a set of feature 1528 collections. In other words, a feature set is a region of 1529 N-dimensional feature-space, that region being defined by the set of 1530 points - feature collections - that make up the space. If a 1531 particular feature collection is in the space, it means that the 1532 rendering described by that feature collection is supported by the 1533 device with that feature set. 1535 How does one represent a feature set? There are many ways to describe 1536 an N-dimensional space. One way is to identify mathematical functions 1537 which identify its contours. Clearly, that is too complex to be 1538 useful. The solution taken in RFC 2533 is to define the space with a 1539 feature set predicate. A feature predicate defines a relation over 1540 an N-dimensional space; its input is any point in that space (i.e. a 1541 feature collection), and is true for all points that are in the 1542 region thus defined. 1544 RFC 2533 describes a syntax for writing down these N-dimensional 1545 boolean functions, borrowed from LDAP [14]. It uses a prolog-style 1546 syntax which is fairly self-explanatory. This representation is 1547 called a feature set predicate. The base unit of the predicate is a 1548 filter, which is a boolean expression encased in round brackets. A 1549 filter can be complex, where it contains conjunctions and 1550 disjunctions of other filters, or it can be simple. A simple filter 1551 is one that expresses a comparison operation on a single media 1552 feature tag. 1554 For example, consider the feature set predicate: 1556 (& (foo=A) 1557 (bar=B) 1558 (| (baz=C) (& (baz=D) (bif=E)))) 1560 This defines a function over four media features - foo, bar, baz and 1561 bif. Any point in feature space with foo equal to A, bar equal to B, 1562 and either baz equal to C, or baz equal to D and bif equal to E, is 1563 in the feature set defined by this feature set predicate. 1565 Note that the predicate doesn't say anything about the number of 1566 dimensions in feature space. The predicate operates on a feature 1567 space of any number of dimensions, but only those dimensions labeled 1568 foo, bar, baz and bif matter. The result is that values of other 1569 media features don't matter. The feature collection 1570 {foo=A,bar=B,baz=C,bop=F} is in the feature set described by the 1571 predicate, even though the media feature tag ``bop'' isn't mentioned. 1572 Feature set predicates are therefore inclusive by default. A feature 1573 collection is present unless the boolean predicate rules it out. This 1574 was a conscious design choice in RFC 2533. 1576 RFC 2533 also talks about matching a preference with a capability 1577 set. This is accomplished by representing both with a feature set. A 1578 preference is a feature set - its a specification of a number of 1579 feature collections, any one of which would satisfy the requirements 1580 of the sender. A capability is also a feature set - its a 1581 specification of the feature collections that the recipient supports. 1582 There is a match when the spaces defined by both feature sets 1583 overlap. When there is overlap, there exists at least one feature 1584 collection that exists in both feature sets, and therefore a modality 1585 or rendering desired by the sender which is supported by the 1586 recipient. 1588 This leads directly to the definition of a match. Two feature sets 1589 match if there exists at least one feature collection present in both 1590 feature sets. 1592 Computing a match for two general feature set predicates is not easy. 1593 Section 5 of RFC 2533 presents an algorithm for doing it by expanding 1594 an arbitrary expression into disjunctive normal form. However, the 1595 feature set predicates used by this specification are constrained. 1596 They are always in conjunctive normal form, with each term in the 1597 conjunction describing values for different media features. This 1598 makes computation of a match easy. It is computed independently for 1599 each media feature, and then the feature sets overlap if media 1600 features specified in both sets overlap. Computing the overlap of a 1601 single media feature is very straightforward, and is a simple matter 1602 of computing whether two finite sets overlap. 1604 Intellectual Property Statement 1606 The IETF takes no position regarding the validity or scope of any 1607 intellectual property or other rights that might be claimed to 1608 pertain to the implementation or use of the technology described in 1609 this document or the extent to which any license under such rights 1610 might or might not be available; neither does it represent that it 1611 has made any effort to identify any such rights. Information on the 1612 IETF's procedures with respect to rights in standards-track and 1613 standards-related documentation can be found in BCP-11. Copies of 1614 claims of rights made available for publication and any assurances of 1615 licenses to be made available, or the result of an attempt made to 1616 obtain a general license or permission for the use of such 1617 proprietary rights by implementors or users of this specification can 1618 be obtained from the IETF Secretariat. 1620 The IETF invites any interested party to bring to its attention any 1621 copyrights, patents or patent applications, or other proprietary 1622 rights which may cover technology that may be required to practice 1623 this standard. Please address the information to the IETF Executive 1624 Director. 1626 Full Copyright Statement 1628 Copyright (C) The Internet Society (2003). All Rights Reserved. 1630 This document and translations of it may be copied and furnished to 1631 others, and derivative works that comment on or otherwise explain it 1632 or assist in its implementation may be prepared, copied, published 1633 and distributed, in whole or in part, without restriction of any 1634 kind, provided that the above copyright notice and this paragraph are 1635 included on all such copies and derivative works. However, this 1636 document itself may not be modified in any way, such as by removing 1637 the copyright notice or references to the Internet Society or other 1638 Internet organizations, except as needed for the purpose of 1639 developing Internet standards in which case the procedures for 1640 copyrights defined in the Internet Standards process must be 1641 followed, or as required to translate it into languages other than 1642 English. 1644 The limited permissions granted above are perpetual and will not be 1645 revoked by the Internet Society or its successors or assignees. 1647 This document and the information contained herein is provided on an 1648 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1649 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1650 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1651 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1652 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1654 Acknowledgement 1656 Funding for the RFC Editor function is currently provided by the 1657 Internet Society.