idnits 2.17.1 draft-ietf-sip-callerprefs-10.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 784 has weird spacing: '...g-value start...' == Line 877 has weird spacing: '... where proxy...' == Line 879 has weird spacing: '... ar o ...' == Line 880 has weird spacing: '... ar o ...' == Line 881 has weird spacing: '... ar o ...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2003) is 7491 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-ietf-sip-callee-caps-00 ** Obsolete normative reference: RFC 3265 (ref. '5') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2976 (ref. '6') (Obsoleted by RFC 6086) == Outdated reference: A later version (-09) exists of draft-ietf-sip-guidelines-06 Summary: 4 errors (**), 0 flaws (~~), 11 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: April 21, 2004 H. Schulzrinne 5 Columbia University 6 P. Kyzivat 7 Cisco Systems 8 October 22, 2003 10 Caller Preferences for the Session Initiation Protocol (SIP) 11 draft-ietf-sip-callerprefs-10 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 21, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document describes a set of extensions to the Session Initiation 42 Protocol (SIP) which allow a caller to express preferences about 43 request handling in servers. These preferences include the ability to 44 select which Uniform Resource Identifiers (URI) a request gets routed 45 to, and to specify certain request handling directives in proxies and 46 redirect servers. It does so by defining three new request header 47 fields, Accept-Contact, Reject-Contact, and Request-Disposition, 48 which specify the caller's preferences. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 55 4. Overview of Operation . . . . . . . . . . . . . . . . . . 7 56 5. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 57 5.1 Request Handling Preferences . . . . . . . . . . . . . . . 8 58 5.2 Feature Set Preferences . . . . . . . . . . . . . . . . . 8 59 6. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 60 7. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 12 61 7.1 Request-Disposition Processing . . . . . . . . . . . . . . 12 62 7.2 Preference and Capability Matching . . . . . . . . . . . . 12 63 7.2.1 Extracting Explicit Preferences . . . . . . . . . . . . . 13 64 7.2.2 Extracting Implicit Preferences . . . . . . . . . . . . . 13 65 7.2.2.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 7.2.2.2 Event Packages . . . . . . . . . . . . . . . . . . . . . . 14 67 7.2.3 Constructing Contact Predicates . . . . . . . . . . . . . 14 68 7.2.4 Matching . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 7.2.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 8. Mapping Feature Parameters to a Predicate . . . . . . . . 21 71 9. Header Field Definitions . . . . . . . . . . . . . . . . . 24 72 9.1 Request Disposition . . . . . . . . . . . . . . . . . . . 24 73 9.2 Accept-Contact and Reject-Contact Header Fields . . . . . 26 74 10. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 27 75 11. Security Considerations . . . . . . . . . . . . . . . . . 28 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . 29 77 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 30 78 Normative References . . . . . . . . . . . . . . . . . . . 31 79 Informative References . . . . . . . . . . . . . . . . . . 32 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 32 81 Intellectual Property and Copyright Statements . . . . . . 33 83 1. Introduction 85 When a Session Initiation Protocol (SIP) [1] server receives a 86 request, there are a number of decisions it can make regarding 87 processing of the request. These include: 89 o whether to proxy or redirect the request 91 o which URIs to proxy or redirect to 93 o whether to fork or not 95 o whether to search recursively or not 97 o whether to search in parallel or sequentially 99 The server can base these decisions on any local policy. This policy 100 can be statically configured, or can be based on programmatic 101 execution or database access. 103 However, the administrator of the server is the not the only entity 104 with an interest in request processing. There are at least three 105 parties which have an interest: (1) the administrator of the server, 106 (2) the user that sent the request, and (3) the user to whom the 107 request is directed. The directives of the administrator are 108 embedded in the policy of the server. The preferences of the user to 109 whom the request is directed (referred to as the callee, even though 110 the request may not be INVITE) can be expressed most easily through a 111 script written in some type of scripting language, such as the Call 112 Processing Language (CPL) [11]. However, no mechanism exists to 113 incorporate the preferences of the user that sent the request (also 114 referred to as the caller, even though the request may not be 115 INVITE). For example, the caller might want to speak to a specific 116 user, but want to reach them only at work, because the call is a 117 business call. As another example, the caller might want to reach a 118 user, but not their voicemail, since it is important that the caller 119 talk to the called party. In both of these examples, the caller's 120 preference amounts to having a proxy make a particular routing choice 121 based on the preferences of the caller. 123 This extension allows the caller to have these preferences met. It 124 does so by specifying mechanisms by which a caller can provide 125 preferences on processing of a request. There are two types of 126 preferences. One of them, called request handling preferences, are 127 encapsulated in the Request-Disposition header field. They provide 128 specific request handling directives for a server. The other, called 129 feature preferences, are present in the Accept-Contact and 130 Reject-Contact header fields. They allow the caller to provide a 131 feature set [2] that expresses its preferences on the characteristics 132 of the UA that is to be reached. These are matched with a feature 133 sets provided by a UA to its registrar [3]. The extension is very 134 general purpose, and not tied to a particular service. Rather, it is 135 a tool that can be used in the development of many services. 137 One example of the a service enabled by caller preferences is a "one 138 number" service. A user can have a single identity (their SIP URI) 139 for all of their devices - their cell phone, PDA, work phone, home 140 phone, and so on. If the caller wants to reach the user at their 141 business phone, they simply select "business phone" from a pull-down 142 menu of options when calling that URI. Users would no longer need to 143 maintain and distribute separate identities for each device. 145 2. Terminology 147 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 148 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 149 and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and 150 indicate requirement levels for compliant implementations. 152 3. Definitions 154 Much of the terminology used in this specification is presented in 155 [3]. This specification defines the following additional terms: 157 Caller: Within the context of this specification, a caller refers to 158 the user on whose behalf a UAC is operating. It is not limited to 159 a user who's UAC sends the INVITE method. 161 Feature Preferences: Caller preferences that describe desired 162 properties of a UA that the request is to be routed to. Feature 163 preferences can be made explicitly with the Accept-Contact and 164 Reject-Contact header fields. 166 Request Handling Preferences: Caller preferences that describe 167 desired request treatment at a server. These preferences are 168 carried in the Request-Disposition header field. 170 Target Set: A target set is a set of candidate URIs that a proxy or 171 redirect server can send or redirect a request to. Frequently, 172 target sets are obtained from a registration, but they need not 173 be. 175 Explicit Preference: A caller preference indicated explicitly in the 176 Accept-Contact or Reject-Contact header fields. 178 Implicit Preference: A caller preference that is implied through the 179 presence of other aspects of a request. For example, if the 180 request method is INVITE, it represents an implicit caller 181 preference to route the request to a UA that supports the INVITE 182 method. 184 4. Overview of Operation 186 When a caller sends a request, it can optionally include new header 187 fields which request certain handling at a server. These preferences 188 fall into two categories. The first category, called request handling 189 preferences, are carried in the Request-Disposition header field. 190 They describe specific behavior that is desired at a server. Request 191 handling preferences include whether the caller wishes the server to 192 proxy or redirect, and whether sequential or parallel search is 193 desired. These preferences can be applied at every proxy or redirect 194 server on the call signaling path. 196 The second category of preferences, called feature preferences, are 197 carried in the Accept-Contact and Reject-Contact header fields. These 198 header fields contain feature sets, represented by the same feature 199 parameters that are used to indicate capabilities [3]. Here, the 200 feature parameters represent the caller's preferences. The 201 Accept-Contact header field contains feature sets that describe UAs 202 that the caller would like to reach. The Reject-Contact header field 203 contains feature sets which, if matched by a UA, imply that the 204 request should not be routed to that UA. 206 Proxies use the information in the Accept-Contact and Reject-Contact 207 header fields to select amongst contacts in their target set. When 208 neither of those header fields are present, the proxy computes 209 implicit preferences from the request. These are caller preferences 210 that are not explicitly placed into the request, but can be inferred 211 from the presence of other message components. As an example, if the 212 request method is INVITE, this is an implicit preference to route the 213 call to a UA that supports the INVITE method. 215 Both request handling and feature preferences can appear in any 216 request, not just INVITE. However, they are only useful in requests 217 where proxies need to determine a request target. If the domain in 218 the request URI is not owned by any proxies along the request path, 219 those proxies will never access a location service, and therefore, 220 never have the opportunity to apply the caller preferences. This 221 makes sense; typically, the request URI will identify a UAS for 222 mid-dialog requests. In those cases, the routing decisions were 223 already made on the initial request, and it makes no sense to redo 224 them for subsequent requests in the dialog. 226 5. UAC Behavior 228 A caller wishing to express preferences for a request includes 229 Accept-Contact, Reject-Contact or Request-Disposition header fields 230 in the request, depending on their particular preferences. No 231 additional behavior is required after the request is sent. 233 The Accept-Contact, Reject-Contact and Request-Disposition header 234 fields in an ACK for a non-2xx final response, or in a CANCEL 235 request, MUST be equal to the values in the original request being 236 acknowledged or cancelled. This is to ensure proper operation through 237 stateless proxies. 239 If the UAC wants to determine whether servers along the path 240 understand the header fields described in this specification, it 241 includes a Proxy-Require header field with a value of "pref" [3] in 242 its request. If the request should fail with a 420, the UAC knows 243 that the extension is not supported. In that case, it SHOULD retry, 244 and may decide whether or not to use caller preferences. A UA should 245 only use Proxy-Require if knowledge about support is essential for 246 handling of the request. Note that, in any case, caller preferences 247 can only be considered preferences - there is no guarantee that the 248 requested service is executed. As such, inclusion of a Proxy-Require 249 header field does not mean the preferences will be executed, just 250 that the caller preferences extension is understood by the proxies. 252 5.1 Request Handling Preferences 254 The Request-Disposition header field specifies caller preferences for 255 how a server should process a request. Its value is a list of tokens, 256 each of which specifies a particular processing directive. 258 The syntax of the header field can be found in Section 10, and the 259 semantics of the directives are described in Section 9.1. 261 5.2 Feature Set Preferences 263 A UAC can indicate caller preferences for the capabilities of a UA 264 that should be reached or not reached as a result of sending a SIP 265 request. To do that, it adds one or more Accept-Contact and 266 Reject-Contact header field values. Each header field value contains 267 a set of feature parameters that define a feature set. The syntax of 268 the header field can be found in Section 10, and a discussion of 269 their usage in Section 9.2. 271 Each feature set is constructed as described in Section 5 of [3]. The 272 feature sets placed into these header fields MAY overlap; that is, a 273 UA MAY indicate preferences for feature sets that match according to 274 the matching algorithm of RFC 2533 [2]. 276 A UAC can express explicit preferences for the methods and event 277 packages supported by a UA. It is RECOMMENDED that a UA include a 278 term in an Accept-Contact feature set with the "sip.methods" feature 279 tag (note, however, that even though the name of this feature tag is 280 sip.methods, it would be encoded into the Accept-Contact header field 281 as just "methods"), whose value includes the method of the request. 282 When a UA sends a SUBSCRIBE request, it is RECOMMENDED that a UA 283 include a term in an Accept-Contact feature set with the "sip.events" 284 feature tag, whose value includes the event package of the request. 285 Whether these terms are placed into a new feature set, or whether 286 they are included in each feature set, is at the discretion of the 287 implementor. In most cases, the right effect is achieved by including 288 a term in each feature set. 290 As an example, the following Accept-Contact header field expresses a 291 desire to route a call to a mobile device: 293 Accept-Contact: *;mobility="mobile";methods="INVITE" 295 The Reject-Contact header field allows the UAC to specify that a UA 296 should not be contacted if it matches any of the values of the header 297 field. Each value of the Reject-Contact header field contains a "*", 298 purely to align the syntax with guidelines for SIP extensions [12], 299 and is parameterized by a set of feature parameters. Any UA whose 300 capabilities match the feature set described by the feature 301 parameters matches the value. 303 The Accept-Contact header field allows the UAC to specify that a UA 304 should be contacted if it matches some or all of the values of the 305 header field. Each value of the Accept-Contact header field contains 306 a "*" and is parameterized by a set of feature parameters. Any UA 307 whose capabilities match the feature set described by the feature 308 parameters matches the value. The precise behavior depends heavily on 309 whether the "require" and "explicit" feature parameters are present. 310 When both of them are present, a proxy will only forward the request 311 to contacts which have explicitly indicated that they support the 312 desired feature set. Any others are discarded. As such, a UAC should 313 only use "require" and "explicit" together when it wishes the call to 314 fail unless a contact definitively matches. It's possible that a UA 315 supports a desired feature, but did not indicate it in its 316 registration. When a UAC uses both "explicit" and "require", such a 317 contact would not be reached. As a result, this combination is often 318 not the one a UAC will want. 320 When only "require" is present, it means that a contact will not be 321 used if it doesn't match. If it does match, or if its not known 322 whether its a complete match, the contact is still used. A UAC would 323 use "require" alone when a non-matching contact is useless. This is 324 common for services where the request simply can't be serviced 325 without the neccesary features. An example is support for specific 326 methods or event packages. When only "require" is present, the proxy 327 will also preferentially route the request to the UA which represents 328 the "best" match. Here, "best" means that the UA has explicitly 329 indicated it supports more of the desired features than any other. 330 Note, however, that this preferential routing will never override an 331 ordering providing by the called party. The preferential routing will 332 only choose amongst contacts of equal q-value. 334 When only "explicit" is present, it means that all contacts provided 335 by the callee will be used. However, if the contact isn't an explicit 336 match, it is tried last amongst all other contacts with the same 337 q-value. The principle difference, therefore, between this 338 configuration and the usage of both "require" and "explicit" is the 339 fallback behavior for contacts that don't match explicitly. Here, 340 they are tried as a last resort. If "require" is also present, they 341 are never tried. 343 Finally, if neither "require" nor "explicit" are present, it means 344 that all contacts provided by the callee will be used. However, if 345 the contact doesn't match, it is tried last amongst all other 346 contacts with the same q-value. If it does match, the request is 347 routed preferentially to the "best" match. This is a common 348 configuration for preferences that, if not honored, will still allow 349 for a successful call, and the greater the match, the better. 351 6. UAS Behavior 353 When a UAS compliant to this specification receives a request whose 354 request-URI corresponds to one of its registered Contacts, it SHOULD 355 apply the behavior described in Section 7 as if it were a proxy for 356 the domain in the request-URI. The UAS acts as if its location 357 database contains a single request target for the request-URI. That 358 target is associated with a feature set. The feature set is the same 359 as the one placed in the registration of the URI in the request-URI. 360 If a UA had registered against multiple separate adresses-of-record, 361 and the contacts registered for each had different capabilities, it 362 will have used a different URI in each registration, so it can 363 determine which feature set to use. 365 This processing occurs after the client authenticates and authorizes 366 the request, but before the remainder of the general UAS processing 367 described in Section 8.2.1 of RFC 3261. 369 If, after performing this processing, there are no URI left in the 370 target set, the UA SHOULD reject the request with a 480 response. If 371 there is a URI remaining (there was only one to begin with), the UA 372 proceeeds with request processing as per RFC 3261. 374 Having a UAS perform the matching operations as if it were a proxy 375 allows certain caller preferences to be honored even if the proxy 376 doesn't support the extension. 378 7. Proxy Behavior 380 Proxy behavior consists of two orthogonal sets of rules - one for 381 processing the Request-Disposition header field, and one for 382 processing the URI and feature set preferences in the Accept-Contact 383 and Reject-Contact header fields. 385 In addition to processing these headers, a proxy MAY add one if not 386 present, or add a value to an existing header field, as if it were a 387 UAC. This is useful for a proxy to request processing in downstream 388 proxies in the implementation of a feature. However a proxy MUST NOT 389 modify or remove an existing header field value. This is particularly 390 important when S/MIME is used. The message signature could include 391 the caller preferences header fields, allowing the UAS to verify 392 that, even though proxies may have added header fields, the original 393 caller preferences were still present. 395 7.1 Request-Disposition Processing 397 If the request contains a Request-Disposition header field, the 398 server SHOULD execute the directives as described in Section 9.1, 399 unless it has local policy configured to direct it otherwise. 401 7.2 Preference and Capability Matching 403 A proxy compliant to this specification MUST NOT apply the 404 preferences matching operation described here to a request unless it 405 is the owner of the domain in the request URI, and accessing a 406 location service that has capabilities associated with request 407 targets. However, if it is the owner of the domain, and accessing a 408 location service that has capabilities associated with request 409 targets, it SHOULD apply the processing described in this section. 410 Typically, this is a proxy that is using a registration database to 411 determine the request targets. However, if a proxy knows about 412 capabilities through some other means, it SHOULD apply the processing 413 defined here as well. If it does perform the processing, it MUST do 414 so as described below. 416 The processing is described through a conversion from the syntax 417 described in this specification to RFC 2533 [2] syntax, followed by a 418 matching operation and a sorting of resulting contact values. The 419 usage of RFC 2533 syntax as an intermediate step is not required, it 420 only serves as a useful tool to describe the behavior required of the 421 proxy. A proxy can use any steps it likes so long as the results are 422 identical to the ones that would be achieved with the processing 423 described here. 425 7.2.1 Extracting Explicit Preferences 427 The first step in proxy processing is to extract explicit 428 preferences. To do that, it looks for the Accept-Contact and 429 Reject-Contact header fields. 431 For each value of those header fields, it extracts the feature 432 parameters. These are the header field parameters whose name is one 433 of the base-tags, or whose name begins with a plus (+) [3]. The proxy 434 converts all of those parameters to the syntax of RFC 2533, based on 435 the rules in Section 8. 437 The result will be a set of feature set predicates in conjunctive 438 normal form, each of which is associated with one of the two 439 preference header fields. If there was a req-parameter associated 440 with a header field value in the Accept-Contact header field, the 441 feature set predicate derived from that header field value is said to 442 have its require flag set. Similarly, if there was an explicit-param 443 associated with a header field value in the Accept-Contact header 444 field, the feature set predicate derived from that header field value 445 is said to have its explicit flag set. 447 7.2.2 Extracting Implicit Preferences 449 If, and only if, the proxy did not find any explicit preferences in 450 the request (because there was no Accept-Contact or Reject-Contact 451 header field), the proxy extracts implicit preferences. These 452 preferences are ones implied by the presence of other information in 453 the request. 455 First, the proxy creates a conjunction with no terms. This 456 conjunction represents a feature set that will be associated with the 457 Accept-Contact header field, as if it were included there. Note that 458 there is no modification of the message implied - only an association 459 for the purposes of processing. Furthermore, this feature set has 460 its require flag set, but not its explicit flag. 462 The proxy then adds terms to the conjunction for the two implicit 463 preference types below. 465 7.2.2.1 Methods 467 One implicit preference is the method. When a UAC sends a request 468 with a specific method, it is an implicit preference to have the 469 request routed only to UAs that support that method. To support this 470 implicit preference, the proxy adds a term to the conjunction of the 471 following form: 473 (sip.methods=[method of request]) 475 7.2.2.2 Event Packages 477 For requests that establish a subscription [5], the Event header 478 field is another expression of an implicit preference. It expresses a 479 desire for the request to be routed only to a server than supports 480 the given event package. To support this implicit preference, the 481 proxy adds a term to the conjunction of the following form: 483 (sip.events=[value of the Event header field]) 485 7.2.3 Constructing Contact Predicates 487 The proxy then takes each URI in the target set (the set of URI it is 488 going to proxy or redirect to), and obtains its capabilities as an 489 RFC 2533 formatted feature set predicate. This is called a contact 490 predicate. If the target URI was obtained through a registration, the 491 proxy computes the contact predicate by extracting the feature 492 parameters from the Contact header field [3] and the converting them 493 to a feature predicate. To extract the feature parameters, the proxy 494 follows these steps: 496 1. Create an initial, empty list of feature parameters. 498 2. If the Contact URI parameters included the "audio", "automata", 499 "class", "duplex", "data", "control", "mobility", "description", 500 "events", "priority", "methods", "schemes", "application", 501 "video", "actor", "language", "isfocus" or "type" parameters, 502 those are copied into the list. 504 3. If any Contact URI parameter name begins with a "+", it is copied 505 into the list if the list does not already contain that name with 506 the plus removed. In other words, if the "video" feature 507 parameter is in the list, the "+video" parameter would not be 508 placed into the list. This conflict should never arise if the 509 client were compliant to this specification, since it is illegal 510 to use the + form for encoding of a feature tag in the base set. 512 If the URI in the target set had no feature parameters, it is said to 513 be immune to caller preference processing. This means that the URI is 514 removed from the target set temporarily, the caller preferences 515 processing described below is executed, and then the URI is added 516 back in. 518 Assuming the URI has feature parameters, they are converted to RFC 519 2533 syntax using the rules of Section 8. 521 The resulting predicate is associated with a q-value. If the contact 522 predicate was learned through a REGISTER request, the q-value is 523 equal to the q-value in the Contact header field parameter, else 524 "1.0" if not specified. 526 As an example, consider the following registered Contact header 527 field: 529 Contact: ;audio;video;mobility="fixed"; 530 +message="TRUE";other-param=66372; 531 methods="INVITE,OPTIONS,BYE,CANCEL,ACK";schemes="sip,http" 533 This would be converted into the following predicate: 535 (& (audio=TRUE) 536 (video=TRUE) 537 (sip.mobility=fixed) 538 (message=TRUE) 539 (| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE) 540 (sip.methods=CANCEL) (sip.methods=ACK)) 541 (| (sip.schemes=sip) (sip.schemes=http))) 543 Note that "other-param" was not considered a feature parameter, since 544 it is neither a base tag nor did it begin with a leading +. 546 7.2.4 Matching 548 It is important to note that the proxy does not have to know anything 549 about the meaning of the feature tags that it is comparing in order 550 to perform the matching operation. The rules for performing the 551 comparison depend on syntactic hints present in the values of each 552 feature tag. For example, a predicate such as: 554 (foo>=4) 556 implies that the feature tag "foo" is a numeric value. The matching 557 rules in RFC 2533 only require an implementation to know whether the 558 feature tag is a numeric, token, or quoted string (booleans can be 559 treated as tokens). Quoted strings are always matched using a 560 case-sensitive matching operation. Tokens are matched using 561 case-insensitive matching. Numerics are matched using normal 562 mathematical comparisons. 564 First, the proxy applies the predicates associated with the 565 Reject-Contact header field. 567 For each contact predicate, each Reject-Contact predicate (that is, 568 each predicate associated with the Reject-Contact header field) is 569 examined. If that Reject-Contact predicate contains a filter for a 570 feature tag, and that feature tag is not present anywhere in the 571 contact predicate, that Reject-Contact predicate is discarded for the 572 processing of that contact predicate. If the Reject-Contact predicate 573 is not discarded, it is matched to the contact predicate using the 574 matching operation of RFC 2533 [2]. If the result is a match, the URI 575 corresponding to that contact predicate is discarded from the target 576 set. 578 The result is that Reject-Contact will only discard URIs where the UA 579 has explicitly indicated support for the features that are not 580 wanted. 582 Next, the proxy applies the predicates associated with the 583 Accept-Contact header field. For each contact that remains in the 584 target set, the proxy constructs a matching set, Ms. Initially, this 585 set contains all of the Accept-Contact predicates. Each of those 586 predicates is examined. It is matched to the contact predicate using 587 the matching operation of RFC 2533 [2]. If the result is not a match, 588 and the Accept-Contact predicate had its require flag set, the URI 589 corresponding to that contact predicate is discarded from the target 590 set. If the result is not a match, but the Accept-Contact predicate 591 did not have its require flag set, that contact URI is not discarded 592 from the target set, however, the Accept-Contact predicate is removed 593 from the matching set for that contact. 595 For each contact that remains in the target set, the proxy computes a 596 score for that contact against each predicate in the contact's 597 matching set. Let the number of terms in the Accept-Contact predicate 598 conjunction be equal to N. Each term in that predicate contains a 599 single feature tag. If the contact predicate has a term containing 600 that same feature tag, the score is incremented by 1/N. If the 601 feature tag was not present in the contact predicate, the score 602 remains unchanged. Based on these rules, the score can range between 603 zero and one. 605 T 606 +----------> DROP Contact 607 | 608 | 609 / \ 610 / \ 611 T / \ F 612 +---->/require\------> Set score=0 613 | \ / 614 | \ / 615 / \ \ / 616 / \ \/ 617 score<1 / \ 618 +-------> /explicit----> Score unchanged 619 | \ / F 620 | \ / 621 / \ \ / 622 / \ \/ 623 +--------+ / \ 624 -->|Compute |--> /Score \ --------> Score unchanged 625 | Score | \ / score=1 626 +--------+ \ / 627 \ / 628 \/ 630 Figure 7: Applying the Score 632 The require and explicit tags are then applied, resulting in 633 potential modification of the score and the target set. This process 634 is summarized in Figure 7. If the score for the contact predicate 635 against that Accept-Contact predicate was less than one, and the 636 Accept-Contact predicate had an explicit tag, if the predicate also 637 had a require tag, the Contact URI corresponding to that contact 638 predicate is dropped. If, however, the predicate did not have a 639 require tag, the score is set to zero. If there was no explicit tag, 640 the score is unchanged. 642 The next step is to combine the scores and the q-values associated 643 with the predicates in the matching set, to arrive at an overall 644 caller preference, Qa. For those URIs in the target set which remain, 645 there will be a score which indicates its match against each 646 Accept-Contact predicate in the matching set. If there are M 647 Accept-Contact predicates in the matching set, there will be M scores 648 S1 through SM, for each contact. The overall caller preference, Qa, 649 is the arithmetic average of S1 through SM. 651 At this point, any URIs that were removed from the target set because 652 they were immune from caller preferences are added back in, and Qa 653 for that URI is set to 1.0. 655 The purpose of the caller preference Qa is to provide an ordering for 656 any contacts remaining in the target set, if the callee has not 657 provided an ordering. To do this, the contacts remaining in the 658 target set are sorted by the q-value provided by the callee. Once 659 sorted, they are grouped into equivalence classes, such that all 660 contacts with the same q-value are in the same equivalence class. 661 Within each equivalence class, the contacts are then ordered based on 662 their values of Qa. The result is an ordered list of contacts that is 663 used by the proxy. 665 If there were no URIs in the target set after the application of the 666 processing in this section, and the caller preferences were based on 667 implicit preferences (Section 7.2.2), the processing in this section 668 is discarded, and the original target set, ordered by their original 669 q-values, is used. 671 This handles the case where implicit preferences for the method or 672 event packages resulted in the elimination of all potential 673 targets. By going back to the original target set, those URIs will 674 be tried, and result in the generation of a 405 or 489. The UAC 675 can then use this information to try again, or report the error to 676 the user. Without reverting to the original target set, the UAC 677 would see a 480 response, and have no knowledge of why their 678 request failed. Of course, the target set can also be empty after 679 the application of explicit preferences. This will result in the 680 generation of a 480 by the proxy. This behavior is acceptable, and 681 indeed, desirable in the case of explicit preferences. When the 682 caller makes an explicit preference, it is agreeing that its 683 request might fail because of a preference mismatch. One might try 684 to return an error indicating the capabilities of the callee, so 685 that the caller could perhaps try again. However, doing so results 686 in the leaking of potentially sensitive information to the caller 687 without authorization from the callee, and therefore this 688 specification does not provide a means for it. 690 If a proxy server is recursing, it adds the Contact header fields 691 returned in the redirect responses to the target set, and re-applies 692 the caller preferences algorithm. 694 If the server is redirecting, it returns all entries in the target 695 set. It assigns q-values to those entries arbitrarily, so that the 696 ordering is identical to the ordering determined by the processing 697 above. However, it MUST NOT include the feature parameters for the 698 entries in the target set. If it did, the upstream proxy server would 699 apply the same caller preferences once more, resulting in a double 700 application of those preferences. If the redirect server does wish to 701 include the feature parameters in the Contact header field, it MUST 702 redirect using the original target set and original q-values, before 703 the application of caller preferences. 705 7.2.5 Example 707 Consider the following example, which is contrived but illustrative 708 of the various components of the matching process. There are five 709 registered Contacts for sip:user@example.com. They are: 711 Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.2 712 Contact: sip:u2@h.example.com;audio="FALSE"; 713 methods="INVITE";actor="msg-taker";q=0.2 714 Contact: sip:u3@h.example.com;audio;actor="msg-taker"; 715 methods="INVITE";video;q=0.3 716 Contact: sip:u4@h.example.com;audio;methods="INVITE,OPTIONS";q=0.2 717 Contact: sip:u5@h.example.com;q=0.5 719 An INVITE sent to sip:user@example.com contained the following caller 720 preferences header fields: 722 Reject-Contact: *;actor="msg-taker";video 723 Accept-Contact: *;audio;require 724 Accept-Contact: *;video;explicit 725 Accept-Contact: *;methods="BYE";class="business";q=1.0 727 There are no implicit preferences in this example, because explicit 728 preferences are provided. 730 The proxy first removes u5 from the target set, since it is immune 731 from caller preferences processing. 733 Next, the proxy processes the Reject-Contact header field. It is a 734 match for all four remaining contacts, but only an explicit match for 735 u3. Thats because u3 is the only one that explicitly indicated 736 support for video, and explicitly indicated it is a message taker. 737 So, u3 gets discarded, and the others remain. 739 Next, each of the remaining three contacts is compared against each 740 of the three Accept-Contact predicates. u1 is a match to all three, 741 earning a score of 1.0 for the first two predicates, and 0.5 for the 742 third (the methods feature tag was present in the contact predicate, 743 but the class tag was not). u2 doesn't match the first predicate. 744 Because that predicate has a require tag, u2 is discarded. u4 matches 745 the first predicate, earning a score of 1.0. u4 does match the second 746 predicate, but since the match is not explicit (the score is 0.0, in 747 fact), the score is set to zero (it was already zero, so nothing 748 changes). u4 does not match the third predicate. 750 At this point, u1 and u4 remain. u1 matched all three Accept-Contact 751 predicates, so that its matching set contains all three, with scores 752 of 1, 1, and 0.5. u4 matches the first two predicates, with scores of 753 1.0 and 0.0. Qa for u1 is 0.83 and Qa for u4 is 0.5. u5 is added back 754 in with a Qa of 1.0. 756 Next, the remaining contacts in the target set are sorted by q-value. 757 u5 has a value of 0.5, u1 has a q-value of 0.2 and so does u4. There 758 are two equivalnce classes. The first has a q-value of 0.5, and 759 consists of just u5. Since there is only one member of the class, 760 sorting within the class has no impact. The second equivalence class 761 as a q-value of 0.2. Within that class, the two contacts, u1 and u4, 762 are ordered based on their values of Qa. u1 has a Qa of 0.83, and u4, 763 a Qa of 0.5. Thus, u1 comes first, followed by u4. The resulting 764 overall ordered set of contacts in the target set is u5, u1 and then 765 u4. 767 8. Mapping Feature Parameters to a Predicate 769 Mapping between feature parameters and a feature set predicate, 770 formatted according to the syntax of RFC 2533 [2] is trivial. It is 771 just the opposite of the process described in Section 5 of [3]. 773 Starting from a set of feature-param, the procedure is as follows. 774 Construct a conjunction. Each term in the conjunction derives from 775 one feature-param. If the feature-param has no value, it is 776 equivalent, in terms of the processing which follows, as if it had a 777 value of "TRUE". 779 If the feature-param value is a tag-value-list, the element of the 780 conjunction is a disjunction. There is one term in the disjunction 781 for each tag-value in the tag-value-list. 783 Consider now the construction of a filter from a tag-value. If the 784 tag-value starts with a bang (!), the filter is of the form: 786 (! ) 788 where "filter from remainder" refers to the filter that would be 789 constructed from the tag-value if the bang had not been present. 791 If the tag-value starts with an octothorpe (#), the filter is a 792 numeric comparison. The comparator is either =, >=, <= or a range 793 based on the next characters in the phrase. If the next characters 794 are =. >= or <=, the filter is of the form: 796 (name comparator compare-value) 798 where name is the name of the feature parameter after it has been 799 decoded (see below), and comparator is either =, >= or <= depending 800 of the initial characters in the phrase. If the remainder of the text 801 in the tag-value after the equal contains a decimal point (implying a 802 rational number), the decimal point is shifted right N times until it 803 is an integer, I. Compare-value above is then set to "I / 10**N", 804 where 10**N is the result of computing the number 10 to the Nth 805 power. 807 If the value after the octothorpe is a number, the filter is a range. 808 The format of the filter is: 810 (name=[remainder]) 812 where name is the feature-tag after it has been decoded (see below), 813 and remainder is the remainder of the text in the tag-value after the 814 #, with any decimal numbers converted to a rational form, and the 815 colon replaced by a double dot (..). 817 If the tag-value does not begin with an octothorpe (it is a 818 token-nobang or boolean), the filter is of the form: 820 (name=tag-value) 822 where name is the feature-tag after it has been decoded (see below). 824 If the feature-param contains a string-value (based on the fact that 825 it begins with a left angle bracket ("<") and ends with a right angle 826 bracket (">")), the filter is of the form: 828 (name="qdtext") 830 Note the explicit usage of quotes around the qdtext, which indicate 831 that the value is a string. In RFC 2533, strings are compared using 832 case sensitive rules, and tokens, case insensitive. 834 Feature tags, as specified in RFC 2506, cannot be directly 835 represented as header field parameters in the Contact, Accept-Contact 836 and Reject-Contact header fields. This is due to an inconsistency in 837 the grammars, and in the need to differentiate feature parameters 838 from parameters used by other extensions. As such, feature tag values 839 are encoded from RFC 2506 format to yield an enc-feature-tag, and 840 then are decoded into RFC 2506 format. The decoding process is 841 simple. If there is a leading plus (+) sign, it is removed. Any 842 exclamation point (!) is converted to a colon (:) and any single 843 quote (') is converted to a forward slash (/). If there was no 844 leading plus sign, and the remainder of the encoded name was 845 "automata", "class", "duplex", "mobility", "description", "events", 846 "priority", "methods", "schemes", "isfocus" or "actor", the prefix 847 "sip." is added to remainder of the encoded name to compute the 848 feature tag name. 850 As an example, the Accept-Contact header: 852 Accept-Contact:*;mobility="fixed";events="!presence,winfo";language="en,de" 853 ;description="";+sip.newparam;+rangeparam="#-4:+5.125" 855 would be converted to the following feature predicate: 857 (& (sip.mobility=fixed) 858 (| (! (sip.events=presence)) (sip.events=winfo)) 859 (| (language=en) (language=de)) 860 (sip.description="PC") 861 (sip.newparam=TRUE) 862 (rangeparam=-4..5125/1000)) 864 9. Header Field Definitions 866 This specification defines three new header fields - Accept-Contact, 867 Reject-Contact, and Request-Disposition. 869 Figure 17 and Figure 18 are an extension of Tables 2 and 3 in RFC 870 3261 [1] for the Accept-Contact, Reject-Contact and 871 Request-Disposition header fields. The column "INF" is for the INFO 872 method [6], "PRA" is for the PRACK method [7], "UPD" is for the 873 UPDATE method [8], "SUB" is for the SUBSCRIBE method [5], "NOT" is 874 for the NOTIFY method [5], "MSG" is for the MESSAGE method [9], and 875 "REF" is for the REFER method [10]. 877 Header field where proxy ACK BYE CAN INV OPT REG 879 Accept-Contact R ar o o o o o - 880 Reject-Contact R ar o o o o o - 881 Request-Disposition R ar o o o o o o 883 Figure 17: Accept-Contact, Reject-Contact and Request-Disposition 884 header fields 886 Header field where proxy PRA UPD SUB NOT INF MSG REF 888 Accept-Contact R ar o o o o o o o 889 Reject-Contact R ar o o o o o o o 890 Request-Disposition R ar o o o o o o o 892 Figure 18: Accept-Contact, Reject-Contact and Request-Disposition 893 header fields 895 9.1 Request Disposition 897 The Request-Disposition header field specifies caller preferences for 898 how a server should process a request. Its value is a list of tokens, 899 each of which specifies a particular directive. Its syntax is 900 specified in Section 10. Note that a compact form, using the letter 901 d, has been defined. The directives are grouped into types. There can 902 only be one directive of each type per request (i.e., you can't have 903 both "proxy" and "redirect" in the same Request-Disposition header 904 field). 906 When the caller specifies a directive, the server SHOULD honor that 907 directive. 909 The following types of directives are defined: 911 proxy-directive: This type of directive indicates whether the caller 912 would like each server to proxy ("proxy") or redirect 913 ("redirect"). 915 cancel-directive: This type of directive indicates whether the caller 916 would like each proxy server to send a CANCEL request downstream 917 ("cancel") in response to a 200 OK from the downstream server 918 (which is the normal mode of operation, making it somewhat 919 redundant), or whether this function should be left to the caller 920 ("no-cancel"). If a proxy receives a request with this parameter 921 set to "no-cancel", it SHOULD NOT CANCEL any outstanding branches 922 on receipt of a 2xx. However, it would still send CANCEL on any 923 outstanding branches on receipt of a 6xx. 925 fork-directive: This type of directive indicates whether a proxy 926 should fork a request ("fork"), or proxy to only a single address 927 ("no-fork"). If the server is requested not to fork, the server 928 SHOULD proxy the request to the "best" address (generally the one 929 with the highest q-value). The directive is ignored if "redirect" 930 has been requested. 932 recurse-directive: This type of directive indicates whether a proxy 933 server receiving a 3xx response should send requests to the 934 addresses listed in the response ("recurse"), or forward the list 935 of addresses upstream towards the caller ("no-recurse"). The 936 directive is ignored if "redirect" has been requested. 938 parallel-directive: For a forking proxy server, this type of 939 directive indicates whether the caller would like the proxy server 940 to proxy the request to all known addresses at once ("parallel"), 941 or go through them sequentially, contacting the next address only 942 after it has received a non-2xx or non-6xx final response for the 943 previous one ("sequential"). The directive is ignored if 944 "redirect" has been requested. 946 queue-directive: If the called party is temporarily unreachable, 947 e.g., because it is in another call, the caller can indicate that 948 it wants to have its call queued ("queue") or rejected immediately 949 ("no-queue"). If the call is queued, the server returns "182 950 Queued". A queued call can be terminated as described in [1]. 952 Example: 954 Request-Disposition: proxy, recurse, parallel 956 The set of request disposition directives is purposefully not 957 extensible. This is to avoid a proliferation of new extensions to SIP 958 that are "tunneled" through this header field. 960 9.2 Accept-Contact and Reject-Contact Header Fields 962 The syntax for these header fields is described in Section 10. A 963 compact form, with the letter a, has been defined for the 964 Accept-Contact header field, and with the letter j for the 965 Reject-Contact header field. 967 10. Augmented BNF 969 The BNF for the Request-Disposition header field is: 971 Request-Disposition = ( "Request-Disposition" / "d" ) HCOLON 972 directive *(COMMA directive) 973 directive = proxy-directive / cancel-directive / 974 fork-directive / recurse-directive / 975 parallel-directive / queue-directive) 976 proxy-directive = "proxy" / "redirect" 977 cancel-directive = "cancel" / "no-cancel" 978 fork-directive = "fork" / "no-fork" 979 recurse-directive = "recurse" / "no-recurse" 980 parallel-directive = "parallel" / "sequential" 981 queue-directive = "queue" / "no-queue" 983 The BNF for the Accept-Contact and Reject-Contact header fields is: 985 Accept-Contact = ("Accept-Contact" / "a") HCOLON ac-value 986 *(COMMA ac-value) 987 Reject-Contact = ("Reject-Contact" / "j") HCOLON rc-value 988 *(COMMA rc-value) 989 ac-value = "*" *(SEMI ac-params) 990 rc-value = "*" *(SEMI rc-params) 991 ac-params = feature-param / req-param 992 / explicit-param / generic-param 993 ;;feature param from RFC XXXX 994 ;;generic-param from RFC 3261 995 rc-params = feature-param / generic-param 996 req-param = "require" 997 explicit-param = "explicit" 999 Despite the BNF, there MUST NOT be more than one req-param or 1000 explicit-param in an acrc-params. Furthermore, there can only be one 1001 instance of any feature tag in feature-param. 1003 11. Security Considerations 1005 The presence of caller preferences in a request has an effect on the 1006 ways in which the request is handled at a server. As a result, it is 1007 especially important that requests with caller preferences be 1008 integrity-protected. 1010 Processing of caller preferences requires set operations and searches 1011 which can require some amount of computation. This enables a DOS 1012 attack whereby a user can send requests with substantial numbers of 1013 caller preferences, in the hopes of overloading the server. To 1014 counter this, servers SHOULD reject requests with too many rules. A 1015 reasonable number is around 20. 1017 12. IANA Considerations 1019 This specification registers three new SIP header fields, according 1020 to the process of RFC 3261 [1]. 1022 The following is the registration for the Accept-Contact header 1023 field: 1025 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of 1026 this specification.] 1028 Header Field Name: Accept-Contact 1030 Compact Form: a 1032 The following is the registration for the Reject-Contact header 1033 field: 1035 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of 1036 this specification.] 1038 Header Field Name: Reject-Contact 1040 Compact Form: j 1042 The following is the registration for the Request-Disposition header 1043 field: 1045 RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of 1046 this specification.] 1048 Header Field Name: Request-Disposition 1050 Compact Form: d 1052 13. Acknowledgments 1054 The initial set of media feature tags used by this specification were 1055 influenced by Scott Petrack's CMA design. Jonathan Lennox, Bob 1056 Penfield, Ben Campbell, Mary Barnes, Rohan Mahy and John Hearty 1057 provided helpful comments. Graham Klyne provided assistance on the 1058 usage of RFC 2533. 1060 Normative References 1062 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1063 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1064 Session Initiation Protocol", RFC 3261, June 2002. 1066 [2] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 1067 2533, March 1999. 1069 [3] Rosenberg, J., "Indicating User Agent Capabilities in the 1070 Session Initiation Protocol (SIP)", 1071 draft-ietf-sip-callee-caps-00 (work in progress), June 2003. 1073 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1074 Levels", BCP 14, RFC 2119, March 1997. 1076 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1077 Notification", RFC 3265, June 2002. 1079 [6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 1081 [7] jdrosen@dynamicsoft.com and schulzrinne@cs.columbia.edu, 1082 "Reliability of Provisional Responses in Session Initiation 1083 Protocol (SIP)", RFC 3262, June 2002. 1085 [8] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1086 Method", RFC 3311, October 2002. 1088 [9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 1089 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1090 Instant Messaging", RFC 3428, December 2002. 1092 [10] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1093 Method", RFC 3515, April 2003. 1095 Informative References 1097 [11] Lennox, J. and H. Schulzrinne, "Call Processing Language 1098 Framework and Requirements", RFC 2824, May 2000. 1100 [12] Rosenberg, J., "Guidelines for Authors of Extensions to the 1101 Session Initiation Protocol (SIP)", 1102 draft-ietf-sip-guidelines-06 (work in progress), November 2002. 1104 Authors' Addresses 1106 Jonathan Rosenberg 1107 dynamicsoft 1108 600 Lanidex Plaza 1109 Parsippany, NJ 07054 1110 US 1112 Phone: +1 973 952-5000 1113 EMail: jdrosen@dynamicsoft.com 1114 URI: http://www.jdrosen.net 1116 Henning Schulzrinne 1117 Columbia University 1118 M/S 0401 1119 1214 Amsterdam Ave. 1120 New York, NY 10027 1121 US 1123 EMail: schulzrinne@cs.columbia.edu 1124 URI: http://www.cs.columbia.edu/~hgs 1126 Paul Kyzivat 1127 Cisco Systems 1128 1414 Massachusetts Avenue 1129 BXB500 C2-2 1130 Boxboro, MA 01719 1131 US 1133 EMail: pkzivat@cisco.com 1135 Intellectual Property Statement 1137 The IETF takes no position regarding the validity or scope of any 1138 intellectual property or other rights that might be claimed to 1139 pertain to the implementation or use of the technology described in 1140 this document or the extent to which any license under such rights 1141 might or might not be available; neither does it represent that it 1142 has made any effort to identify any such rights. Information on the 1143 IETF's procedures with respect to rights in standards-track and 1144 standards-related documentation can be found in BCP-11. Copies of 1145 claims of rights made available for publication and any assurances of 1146 licenses to be made available, or the result of an attempt made to 1147 obtain a general license or permission for the use of such 1148 proprietary rights by implementors or users of this specification can 1149 be obtained from the IETF Secretariat. 1151 The IETF invites any interested party to bring to its attention any 1152 copyrights, patents or patent applications, or other proprietary 1153 rights which may cover technology that may be required to practice 1154 this standard. Please address the information to the IETF Executive 1155 Director. 1157 Full Copyright Statement 1159 Copyright (C) The Internet Society (2003). All Rights Reserved. 1161 This document and translations of it may be copied and furnished to 1162 others, and derivative works that comment on or otherwise explain it 1163 or assist in its implementation may be prepared, copied, published 1164 and distributed, in whole or in part, without restriction of any 1165 kind, provided that the above copyright notice and this paragraph are 1166 included on all such copies and derivative works. However, this 1167 document itself may not be modified in any way, such as by removing 1168 the copyright notice or references to the Internet Society or other 1169 Internet organizations, except as needed for the purpose of 1170 developing Internet standards in which case the procedures for 1171 copyrights defined in the Internet Standards process must be 1172 followed, or as required to translate it into languages other than 1173 English. 1175 The limited permissions granted above are perpetual and will not be 1176 revoked by the Internet Society or its successors or assignees. 1178 This document and the information contained herein is provided on an 1179 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1180 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1181 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1182 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1183 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1185 Acknowledgement 1187 Funding for the RFC Editor function is currently provided by the 1188 Internet Society.