idnits 2.17.1 draft-ietf-sipcore-proxy-feature-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2012) is 4207 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) == Missing Reference: 'RFC XXXX' is mentioned on line 587, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group C. Holmberg 3 Internet-Draft I. Sedlacek 4 Intended status: Standards Track Ericsson 5 Expires: April 22, 2013 H. Kaplan 6 Acme Packet 7 October 19, 2012 9 Mechanism to indicate support of features and capabilities in the 10 Session Initiation Protocol (SIP) 11 draft-ietf-sipcore-proxy-feature-12.txt 13 Abstract 15 This specification defines a new SIP header field, Feature-Caps. The 16 Feature-Caps header field conveys feature capability indicators that 17 are used to indicate support of features and capabilities for SIP 18 entities that are not represented by the Uniform Resource Identifier 19 (URI) of the Contact header field. 21 SIP entities that are represented by the URI of the SIP Contact 22 header field can convey media feature tags in the Contact header 23 field to indicate support of features and capabilities. 25 This specification also defines feature capability indicators, and 26 creates a new IANA registry, "Proxy-Feature Feature Capability 27 Indicator Trees", for registering feature capability indicators. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 22, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 5 67 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 5 69 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 6 71 4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 6 72 4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 7 73 4.3. SIP Message Type and Response Code Semantics . . . . . . . 7 74 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 7 76 4.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 8 77 4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8 78 5. Feature Capability Indicators . . . . . . . . . . . . . . . . 9 79 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 80 5.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 9 81 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 9 83 5.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.3. Feature Capability Indicator Specification Requirements . 10 85 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 86 5.3.2. Overall Description . . . . . . . . . . . . . . . . . 10 87 5.3.3. Feature Capability Indicator Values . . . . . . . . . 11 88 5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11 89 5.3.5. Interoperability Considerations . . . . . . . . . . . 11 90 5.3.6. Security Considerations . . . . . . . . . . . . . . . 12 91 5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 92 5.3.8. Other Information . . . . . . . . . . . . . . . . . . 12 93 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12 96 6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 97 6.3. Syntax: feature capability indicator . . . . . . . . . . . 13 98 6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 99 6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 101 7.1. Registration of the Feature-Caps header field . . . . . . 13 102 7.2. Registration of the Feature-Caps header field parameter . 13 103 7.3. Proxy-Feature Feature Capability Indicator Trees . . . . . 14 104 7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 105 7.3.2. Global Feature Capability Indicator Registration 106 Tree . . . . . . . . . . . . . . . . . . . . . . . . . 15 107 7.3.3. SIP Feature Capability Indicator Registration Tree . . 15 108 8. Feature Capability Indicator Registration Template . . . . . . 16 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 110 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 111 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 117 1. Introduction 119 The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" 120 extension, defined in RFC 3840 [RFC3840], provides a mechanism that 121 allows a SIP message to convey information relating to the 122 originator's features and capabilities, using the Contact header 123 field. 125 This specification defines a new SIP header field, Feature-Caps. The 126 Feature-Caps header field conveys feature capability indicators that 127 are used to indicate support of features and capabilities for SIP 128 entities that are not represented by the Uniform Resource Identifier 129 (URI) of the Contact header field. Such cases are: 131 o - The SIP entity acts as a SIP proxy. 132 o - The SIP entity acts as a SIP registrar. 133 o - The SIP entity acts as a Back-to-Back User Agent (B2BUA) 134 [RFC3261], where the Contact header field URI represents another 135 SIP entity. 137 SIP entities that are represented by the URI of the SIP Contact 138 header field can convey media feature tags in the Contact header 139 field to indicate support of features and capabilities. 141 Unlike media feature tags, feature capability indicators are intended 142 to only be used with the SIP protocol. 144 This specification also defines feature capability indicators, and 145 creates a new IANA registry, "Proxy-Feature Feature Capability 146 Indicator Trees", for registering feature capability indicators. 148 2. Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in BCP 14, RFC 2119 153 [RFC2119]. 155 3. Definitions 157 Downstream SIP entity: SIP entity in the direction towards which a 158 SIP request is sent. 160 Upstream SIP entity: SIP entity in the direction from which a SIP 161 request is received. 163 4. Feature-Caps Header Field 165 4.1. Introduction 167 The Feature-Caps header field is used by SIP entities to convey 168 support of features and capabilities, by setting feature capability 169 indicators. A feature capability indicator conveyed in a Feature- 170 Caps header field indicates that a SIP entity in the SIP message 171 signalling path supports the associated feature and capability. 173 4.2. User Agent and Proxy Behavior 175 4.2.1. General 177 If the URI in a Contact header field of a request or response 178 represents a SIP entity, the entity MUST NOT indicate supported 179 features and capabilities using a Feature-Caps header field within 180 that request or response. 182 When a SIP entity receives a SIP request, or response, that contains 183 one or more Feature-Caps header fields, the feature capability 184 indicators in the header field inform the entity about the features 185 and capabilities supported by entities in the SIP message signalling 186 path. The procedure by which features and capabilities are invoked 187 are outside the scope of this specification, and MUST be described by 188 individual feature capability indicator specifications. 190 A Feature-Caps header field value cannot convey the address of the 191 SIP entity that inserted the Feature-Caps header field. If 192 additional data about a supported feature needs to be conveyed, such 193 as the address of the SIP entity that indicated support of the 194 feature, then the feature definition needs to define a way to convey 195 that information as a value of the associated feature capability 196 indicator. 198 When a SIP entity adds a Feature-Caps header field to a SIP message, 199 it MUST place the header field before any existing Feature-Caps 200 header field in the message to be forwarded, so that the added header 201 field becomes the top-most one. Then, when another SIP entity 202 receives a SIP request or the response, the SIP feature capability 203 indicators in the top-most Feature-Caps header field will represent 204 the supported features and capabilities "closest", from a SIP 205 signaling point of view, to the entity. 207 Based on features and policies, a SIP entity MAY remove a Feature- 208 Caps header field from a SIP message. Also, a SIP entity MAY remove 209 a feature capability indicator from a Feature-Caps header field 210 within a SIP message. A SIP entity SHOULD NOT re-order the Feature- 211 Caps header fields within a SIP message. 213 For a given fc-value, as defined in section 6.2.1, the order in which 214 feature capability indicators are listed has no significance. For 215 example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the 216 SIP entity that inserted the feature capability indicator supports 217 the features and capabilities associated with the "foo" and "bar" 218 feature capability indicators. 220 4.2.2. B2BUA Behavior 222 The procedures in this Section apply to User Agents (UAs) [RFC3261] 223 that are part of B2BUAs that are referenced in the message by a 224 Record-Route header field rather than by the URI of the Contact 225 header field. 227 When such a UA sends a SIP request, if the UA wants to indicate 228 support of features and capabilities towards its downstream SIP 229 entities, it inserts a Feature-Caps header field to the request, 230 containing one or more feature capability indicators associated with 231 the supported features and capabilities, before it forwards the 232 request. 234 If the SIP request is triggered by another SIP request that the B2BUA 235 has received, the UA MAY forward received Feature-Caps header fields 236 by copying them to the outgoing SIP request, similar to a SIP proxy, 237 before it inserts its own Feature-Caps header field to the SIP 238 request. 240 When such a UA receives a SIP response, if the UA wants to indicate 241 support of features and capabilities towards its upstream SIP 242 entities, it inserts a Feature-Caps header field to the response, 243 containing one or more feature capability indicators associated with 244 the supported features and capabilities, before it forwards the 245 response. 247 If the SIP response is triggered by another SIP response that the 248 B2BUA has received, the UA MAY forward received Feature-Caps header 249 field by copying them to the outgoing SIP response, similar to a SIP 250 proxy, before it inserts its own Feature-Caps header field to the SIP 251 response. 253 4.2.3. Registrar Behavior 255 If a SIP registrar wants to indicate support of features and 256 capabilities towards its upstream SIP entities, it inserts a Feature- 257 Caps header field, containing one or more feature capability 258 indicators associated with the supported features and capabilities, 259 to a REGISTER response. 261 4.2.4. Proxy behavior 263 When a SIP proxy receives a SIP request, if the proxy wants to 264 indicate support of features and capabilities towards its downstream 265 SIP entities, it inserts a Feature-Caps header field to the request, 266 containing one or more SIP feature capability indicators associated 267 with the supported features and capabilities, before it forwards the 268 request. 270 When a proxy receives a SIP response, if the proxy wants to indicate 271 support of features and capabilities towards its upstream SIP 272 entities, it inserts a Feature-Caps header field to the response, 273 containing one or more SIP feature capability indicators associated 274 with the supported features and capabilities, before it forwards the 275 response. 277 4.3. SIP Message Type and Response Code Semantics 279 4.3.1. General 281 This Section describes the general usage and semantics of the 282 Feature-Caps header field for different SIP message types and 283 response codes. 285 Section 6.2.1 defines the Feature-Caps header field ABNF. 287 4.3.2. SIP Dialog 289 The Feature-Caps header field can be used within an initial SIP 290 request for a dialog, within a target refresh SIP request, and within 291 any 18x or 2xx response associated with such requests. 293 If a feature capability indicator is inserted in a Feature-Caps 294 header field of an initial request for a dialog, or within a response 295 of such request, it indicates to the receivers of the request (or 296 response) that the feature associated with the feature capability 297 indicator is supported for the duration of the dialog, until a target 298 refresh request is sent for the dialog, or the dialog is terminated. 300 Unless a feature capability indicator is inserted in a Feature-Caps 301 header field of a target refresh request, or within a response of 302 such request, it indicates to the receivers of the request (or 303 response) that the feature is no longer supported for the dialog. 305 For a given dialog a SIP entity MUST insert the same feature 306 capability indicators in all 18x and 2xx responses associated with a 307 given transaction. 309 As it cannot be guaranteed that 2xx responses associated with SIP 310 SUBSCRIBE requests will reach the User Agent Client (UAC) [RFC3261], 311 due to forking of the request, entities need to indicate supported 312 features and capabilities in the SIP NOTIFY request that will be sent 313 for each of the created subscription dialogs. 315 4.3.3. SIP Registration (REGISTER) 317 The Feature-Caps header field can be used within a SIP REGISTER 318 request, and within the 200 (OK) response associated with such 319 request. 321 If a feature capability indicator is conveyed in a Feature-Caps 322 header field of a REGISTER request, or within an associated response, 323 it indicates to the receivers of the message that the feature 324 associated with the feature capability indicator is supported for the 325 registration, until the registration of the contact that was 326 explicitly conveyed in the REGISTER request expires, or until the 327 registered contact is explicitly refreshed and the refresh REGISTER 328 request does not contain the feature capability indicator associated 329 with the feature. 331 While a REGISTER response can contain contacts that have been 332 registered as part of other registration transactions, support of any 333 indicated feature only applies to requests sent to the contact(s) 334 that were explicitly conveyed in the associated REGISTER request. 336 This specification does not define any semantics for usage of the 337 Feature-Caps header field in pure registration binding fetching 338 messages (see Section 10.2.3 of RFC 3261), where the REGISTER request 339 does not contain a Contact header field. Unless such semantics is 340 defined in a future extension, fetching messages will not have any 341 impact on previously indicated support of features and capabilities, 342 and SIP entities MUST NOT insert a Feature-Caps header field to such 343 messages. 345 If SIP Outbound [RFC5626] is used, the rules above apply. However, 346 supported features and capabilities only apply for the registration 347 flow on which support has been explicitly indicated. 349 4.3.4. SIP Stand-Alone Transactions 351 The Feature-Caps header field can be used within a standalone SIP 352 request, and within any 2xx response associated with such request. 354 If a feature capability indicator is inserted in a Feature-Caps 355 header field of a standalone request, or within a response of such 356 request, it indicates to the receivers of the request (or response) 357 that the feature associated with the feature capability indicator is 358 supported for the duration of the standalone transaction. 360 5. Feature Capability Indicators 362 5.1. Introduction 364 Feature capability indicators are used by SIP entities not 365 represented by the URI of the Contact header field to indicate 366 support of features and capabilities, where media feature tags cannot 367 be used to indicate the support. 369 A value, or a list of values, that provides additional information 370 about the supported feature or capability, can be associated with a 371 feature capability indicator. 373 5.2. Registration Trees 375 5.2.1. General 377 The following subsections define registration trees, distinguished by 378 the use of faceted names (e.g., names of the form "tree.feature- 379 name"). The registration trees are defined in the IANA "Proxy- 380 Feature Feature Capability Indicator Trees" registry. 382 The trees defined herein are similar to the global tree and sip tree 383 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840. 384 Other registration trees are outside the scope of this specification. 386 In contrast to RFC 2506 and RFC 3840, this specification only defines 387 a global tree and a sip tree, as they are the only trees defined in 388 those RFCs that have been used for defining SIP-specific media 389 feature tags. 391 When a feature capability indicator is registered in any registration 392 tree, no leading "+" is used in the registration. 394 5.2.2. Global Tree 396 The global feature capability indicator tree is similar to the media 397 feature tag global tree defined in RFC 2506 [RFC2506]. 399 A feature capability indicator in the global tree will be 400 distinguished by the leading facet "g.". An organization can propose 401 either a designation indicative of the feature, (e.g., "g.blinktags") 402 or a faceted designation including the organization name (e.g., 403 "g.organization.blinktags"). 405 5.2.3. SIP Tree 407 The sip feature capability indicator tree is similar to the media 408 feature tag sip tree defined in RFC 3840. 410 A feature capability indicator in the sip tree will be distinguished 411 by the leading facet "sip.". 413 5.3. Feature Capability Indicator Specification Requirements 415 5.3.1. General 417 A feature capability indicator specification MUST address the issues 418 defined in the following subsections, or document why an issue is not 419 applicable for the specific feature capability indicator. A 420 reference to the specification MUST be provided when the feature 421 capability indicator is registered with IANA (see Section 8). 423 It is bad practice for feature capability indicator specifications to 424 repeat procedures (e.g. general procedures on the usage of the 425 Feature-Caps header field and feature capability indicators) defined 426 in this specification, unless needed for clarification or emphasis 427 purpose. A feature capability indicator specification MUST NOT 428 modify the Feature-Caps header field rules and semantics defined in 429 Section 4. 431 A feature capability indicator specification MUST NOT weaken any 432 behavior designated with "SHOULD" or "MUST" in this specification. 433 However, a specification MAY strengthen "SHOULD", "MAY", or 434 "RECOMMENDED" requirements to "MUST" strength if features and 435 capabilities associated with the feature capability indicator require 436 it. 438 5.3.2. Overall Description 440 The feature capability indicator specification MUST contain an 441 overall description of the feature capability indicator: how it is 442 used to indicate support of a feature, a description of the feature 443 associated with the feature capability indicator, a description of 444 any additional information (conveyed using one or more feature 445 capability indicator values) that can be conveyed together with the 446 feature capability indicator, and a description of how the associated 447 feature MAY be exercised/invoked. 449 5.3.3. Feature Capability Indicator Values 451 A feature capability indicator can have an associated value, or a 452 list of values. The feature capability indicator specification MUST 453 define the syntax and semantics of any value defined for the feature 454 capability indicator, including possible restrictions related to the 455 usage of a specific value. The feature capability indicator 456 specification MUST define the value(s) in accordance with the ABNF 457 defined in Section 6.3.2. The feature capability indicator 458 specification MUST define whether the feature capability indicator 459 has a default value. 461 If no values are defined for the feature capability indicator, it 462 MUST be indicated in the feature capability indicator specification. 464 A feature capability indicator value is only applicable for the 465 feature capability indicator for which it has been defined. For 466 other feature capability indicators, the value has to be defined 467 explicitly, even if the semantics are identical. 469 It is strongly RECOMMENDED to not re-use a value that already has 470 been defined for another feature capability indicator, unless the 471 semantics of the values are the same. 473 5.3.4. Usage Restrictions 475 If there are restrictions on how SIP entities can insert a feature 476 capability indicator, the feature capability indicator specification 477 MUST document such restrictions. 479 There might be restrictions related to whether entities are allowed 480 to insert a feature capability indicator in registration related 481 messages, standalone transaction messages, dialog related messages, 482 whether entities are allowed to insert a feature capability indicator 483 in requests or responses, whether entities also need to support other 484 features and capabilities in order to insert a feature capability 485 indicator, and whether entities are allowed to indicate support of a 486 feature in conjunction with another feature. 488 5.3.5. Interoperability Considerations 490 The feature capability indicator specification MUST document any 491 specific interoperability considerations that apply to the feature 492 capability indicator. 494 Interoperability considerations can e.g. include procedures related 495 to cases where an expected feature capability indicator is not 496 present, or where it contains an unexpected value. 498 5.3.6. Security Considerations 500 The feature capability indicator specification MUST document any 501 specific security considerations that apply to the feature capability 502 indicator. 504 5.3.7. Examples 506 It is recommended that the feature capability indicator specification 507 provide demonstrative message flow diagrams, paired with complete 508 messages and message descriptions. 510 Note that example message flows are by definition informative, and do 511 not replace normative text. 513 5.3.8. Other Information 515 If there is additional information about the feature capability 516 indicator, it is recommended to describe such information. It can 517 include e.g. names of related feature capability indicators. 519 6. Syntax 521 6.1. General 523 This Section defines the ABNF for the Feature-Caps header field, and 524 for the feature capability indicators. The ABNF defined in this 525 specification is conformant to RFC 5234 [RFC5234]." 527 6.2. Syntax: Feature-Caps header field 529 6.2.1. ABNF 531 The ABNF for the Feature-Caps header fields is: 533 Feature-Caps = "Feature-Caps" HCOLON fc-value 534 *(COMMA fc-value) 535 fc-value = "*" *(SEMI feature-cap) 537 NOTE: The "*" value is present in order to follow the guidelines for 538 syntax in RFC 4485 [RFC4485] and to maintain a consistent format with 539 RFC 3840 and RFC 3841 [RFC3841]. 541 6.3. Syntax: feature capability indicator 543 6.3.1. General 545 In a feature capability indicator name (ABNF: fcap-name), dots can be 546 used to implement a feature capability indicator tree hierarchy (e.g. 547 tree.feature.subfeature). The description of usage of such tree 548 hierarchy must be described when registered. 550 6.3.2. ABNF 552 The ABNF for the feature capability indicator: 554 feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list 555 / fcap-string-value ) RDQUOT] 556 fcap-name = ftag-name 557 fcap-value-list = tag-value-list 558 fcap-string-value = string-value 559 ;; ftag-name, tag-value-list, string-value defined in RFC 3840 561 NOTE: In comparison with media feature tags, the "+" sign in front 562 of the feature capability indicator name is mandatory. 564 7. IANA Considerations 566 7.1. Registration of the Feature-Caps header field 568 This specification registers a new SIP header field, Feature-Caps, 569 according to the process of RFC 3261 [RFC3261]. 571 The following is the registration for the Feature-Caps header field: 573 RFC Number: RFC XXXX 575 Header Field Name: Feature-Caps 577 7.2. Registration of the Feature-Caps header field parameter 579 This specification adds the Feature-Caps header field to the IANA 580 "Header Field Parameters and Parameter Values" registry, according to 581 the process of RFC 3968 [RFC3968]. 583 Predefined 584 Header Field Parameter Name Values Reference 585 ------------------------------------------------------------------ 587 Feature-Caps + * No [RFC XXXX] 589 * denotes parameter names conforming to the 590 syntax defined in RFC XXXX. Valid 591 feature capability indicators are registered in [IANA: 592 insert reference to the new Proxy-Feature Feature 593 Capability Indicator Trees registry]. 595 (IANA: please sort the "Feature-Caps" line into the table and place 596 the remainder of the above as a footnote to the table.) 598 7.3. Proxy-Feature Feature Capability Indicator Trees 600 7.3.1. Introduction 602 This specification creates a new sub registry to the IANA "Session 603 Initiation Protocol (SIP) Parameters" Protocol Registry, according to 604 the process of RFC 5226. The name of the sub registry is "Proxy- 605 Feature Feature Capability Indicator Trees". 607 Feature capability indicators are categorized by the "leading facet" 608 of their name. The leading facet is a prefix of the name consisting 609 of all characters up to and including the first ".". Feature 610 capability indicator names that contain no "." characters are 611 considered to have an empty ("") leading facet. 613 The "Proxy-Feature Feature Capability Indicator Trees" registry 614 contains sub registries for subsets (called 'trees') of feature 615 capability indicators sharing the same leading facet. Each feature 616 capability indicator is registered within the tree that matches its 617 leading facet. If no tree matches its leading facet then the feature 618 capability indicator can not be registered. 620 New feature capability indicator sub registries (trees) can be 621 registered. The registration must meet the "Standards Action" 622 policies defined in RFC 5226 [RFC5226]. A new name, unique leading 623 facet, and registration policies (as defined in RFC 5226) for feature 624 capability indicators within this tree need to be provided. 626 This document defines the first two feature capability indicator 627 trees ("g." and "sip."). It does not define a tree for the empty 628 leading facet. 630 7.3.2. Global Feature Capability Indicator Registration Tree 632 This specification creates a new feature capability indicator tree in 633 the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. 634 The name of the tree is "Global Feature Capability Indicator 635 Registration Tree", and its leading facet is "g.". It is used for 636 the registration of feature capability indicators. 638 When a feature capability indicator is registered in the global tree, 639 it needs to meet the "Specification Required" policies defined in RFC 640 5226. A designated area expert will review the proposed feature 641 capability indicator, and consult with members of related mailing 642 lists. The information required in the registration is defined in 643 Section 5.3 of RFC XXXX. 645 Note that all feature capability indicators registered in the global 646 tree will have names with a leading facet "g.". No leading "+" is 647 used in the registrations in any of the feature capability indicator 648 registration trees. 650 The format of the global tree is as described below: 652 Name Description Reference 653 ------------------------------ 655 Name contains the Feature Capability Indicator Name, provided 656 in the registration feature capability indication registration 657 template. 659 Description, provided in the registration feature capability 660 indication registration template. 662 Reference contains the Feature Capability Indicator Specification 663 Reference, provided in the registration feature capability 664 indication registration template. 666 No initial values are registered in the global tree. 668 7.3.3. SIP Feature Capability Indicator Registration Tree 670 This specification creates a new feature capability indicator tree in 671 the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. 672 The name of the tree is "SIP Feature Capability Indicator 673 Registration Tree", and its leading facet is "sip.". It is used for 674 the registration of feature capability indicators. 676 When a feature capability indicator is registered in the sip tree, it 677 needs to meet the "IETF Review" policies defined in RFC 5226. The 678 information required in the registration is defined in Section 5.3 of 679 RFC XXXX. 681 Note that all feature capability indicators registered in the SIP 682 tree will have names with a leading facet "sip.". No leading "+" is 683 used in the registrations in any of the feature capability indicator 684 registration trees. 686 The format of the SIP tree is as described below: 688 Name Description Reference 689 ------------------------------ 691 Name contains the Feature Capability Indicator Name, provided 692 in the registration feature capability indication registration 693 template. 695 Description, provided in the registration feature capability 696 indication registration template. 698 Reference contains the Feature Capability Indicator Specification 699 Reference, provided in the registration feature capability 700 indication registration template. 702 No initial values are registered in the SIP tree. 704 8. Feature Capability Indicator Registration Template 705 Registration requests for the global tree are submitted 706 by e-mail to iana@iana.org. 708 Registration requests for the sip tree requires submitting 709 an Internet-Draft to the IESG. 711 | Instructions are preceded by '|'. All fields are mandatory. 713 Feature capability indicator name: 715 Description: 717 | The description should be no longer than 4 lines. More 718 | detailed information can be provided in the feature 719 | capability indicator specification. 721 Feature capability indicator name: 723 | The referenced specification must contain the information 724 | listed in Section 5.3 of RFC XXXX. 726 Feature capability indicator specification reference: 728 | The referenced specification must contain the information 729 | listed in Section 5.3 of RFC XXXX. 731 Contact: 733 | Name(s) & email address(es) of person(s) to 734 | contact for further information." 736 (IANA: Please replace XXXX with the assigned RFC number) 738 9. Security Considerations 740 The security issues for feature capability indicators are similar to 741 the ones defined in RFC 3840 for media feature tags. Media feature 742 tags can reveal information about end-users and end-user equipment, 743 which can be used for industrial espionage. The knowledge about end- 744 user equipment capabilities can also be used to influence application 745 behavior. As feature capability indicators are not intended to 746 convey capability information of end-user devices, such end-user 747 security aspects of RFC 3840 do not apply to feature capability 748 indicators. 750 In addition, the RFC 3840 security issue regarding an attacker using 751 the SIP caller preferences extension [RFC3841] in order to affect 752 routing decisions does not apply, as the mechanism is not defined to 753 be used with feature capability indicators. 755 Feature capability indicators can, however, provide capability and 756 characteristics information about the SIP entity, some of which might 757 be sensitive. Malicious elements viewing the indicators may be able 758 to discern application deployment details or identify elements with 759 exploitable feature implementation weaknesses. The Feature-Caps 760 header field does not convey address information about SIP entities. 761 However, individual feature capability indicators might provide 762 address information as feature capability indicator values. 763 Therefore, if the feature capability indicators provide information 764 that requires data integrity or origin authentication, mechanisms for 765 providing those MUST be provided. If confidentiality is required 766 then the specification MUST call for use of Transport Layer Security 767 (TLS) [RFC5246] at all hops. Since there are no satisfactory middle- 768 to-end or middle-to-middle SIP confidentiality mechanisms, TLS is as 769 good as it gets and specifications SHOULD NOT define feature 770 capability indicators that need confidentiality that is better than 771 the hop-by-hop confidentiality provided by TLS. 773 10. Acknowledgements 775 The authors wish to thank everyone in the SIP community that provided 776 input and feedback on the work of this specification. 778 11. Change Log 780 [RFC EDITOR NOTE: Please remove this Section when publishing] 782 Changes from draft-holmberg-sipcore-proxy-feature-11 783 o IANA: Indicating that no initial values are registered in the 784 trees. 785 o IESG: Editorial changes based on comments from Barry Leiba. 786 o IESG: Reference to RFC 5234 added based on comments from Adrian 787 Farrel. 788 o IESG: Editorial changes and Security Consideration modification 789 based on comments from Stephen Farrell. 790 o IESG: Editorial changes based on comments from Pete Resnick. 792 Changes from draft-holmberg-sipcore-proxy-feature-10 793 o Editorial changes. 795 o 'IETF Consensus' changed to 'IETF Review' (section 7.3.3) 797 Changes from draft-holmberg-sipcore-proxy-feature-09 798 o Editorial changes based on SECDIR comments from Radia Perlman. 799 o Editorial changes based on Gen-Art comments from Brian E 800 Carpenter. 801 o Editorial changes based on OPSDIR comments from Jouni Korhonen. 802 o Change in security considerations indicating that, if sensitive 803 information is conveyed, mechanisms for guaranteeing 804 confidentiality and authenticity must be provided. 806 Changes from draft-holmberg-sipcore-proxy-feature-08 807 o Comments from Atle Mondrad. 809 Changes from draft-holmberg-sipcore-proxy-feature-06 810 o Editorial changes. 812 Changes from draft-holmberg-sipcore-proxy-feature-05 813 o AD comments from Robert Sparks 814 o Additional text added to the Security Considerations section. 815 o IANA registration template modified. 816 o IANA registration procedures clarified. 817 o Feature Capability Indicator specification requirements modified. 818 o Note regarding SUBSCRIBE 200 responses added. 819 o Editorial modifications. 821 Changes from draft-holmberg-sipcore-proxy-feature-04 822 o WGLC comments from Keith Drage 823 o 'feature cap' name changed to 'feature capability indicator'. 824 o Feature-Caps header field added to IANA Header Field Parameters 825 and Parameter Values registry. 826 o Editorial modifications. 828 Changes from draft-ietf-sipcore-proxy-feature-03 829 o Additional Security Considerations text added. 830 o IANA Considerations modified. 831 o Editorial corrections. 833 Changes from draft-ietf-sipcore-proxy-feature-02 834 o Changes based on WGLC comments from Shida Schubert. 835 o - Document title changed 836 o - Terminology alignment 837 o - Note text clarifications 838 o Changes based on WGLC comments from Lili Yang. 840 Changes from draft-ietf-sipcore-proxy-feature-01 841 o Changes based on comments from Paul Kyzivat. 842 o IANA Considerations text added. 844 Changes from draft-holmberg-sipcore-proxy-feature-04/ 845 draft-ietf-sipcore-proxy-feature-00 846 o Media feature tags replaced with feature caps, based on SIPCORE 847 consensus at IETF#83 (Paris). 848 o Editorial corrections and modifications. 850 Changes from draft-holmberg-sipcore-proxy-feature-03 851 o Hadriel Kaplan added as co-author. 852 o Terminology change: instead of talking of proxies, talk about 853 entities which are not represented by the URI in a Contact header 854 field (http://www.ietf.org/mail-archive/web/sipcore/current/ 855 msg04449.html). 856 o Clarification regarding the usage of the header field in 18x/2xx 857 responses (http://www.ietf.org/mail-archive/web/sipcore/current/ 858 msg04449.html). 859 o Specifying that feature support can also be indicated in target 860 refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ 861 current/msg04454.html). 862 o Feature Cap specification registration information added. 864 Changes from draft-holmberg-sipcore-proxy-feature-02 865 o Definition, and usage of, a new header field, instead of Path, 866 Record-Route, Route and Service-Route. 868 Changes from draft-holmberg-sipcore-proxy-feature-01 869 o Requirement section added 870 o Use-cases and examples updated based on work in 3GPP 872 Changes from draft-holmberg-sipcore-proxy-feature-00 873 o Additional use-cases added 874 o Direction section added 876 12. References 878 12.1. Normative References 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, March 1997. 883 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 884 A., Peterson, J., Sparks, R., Handley, M., and E. 885 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 886 June 2002. 888 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 889 Specifications: ABNF", STD 68, RFC 5234, January 2008. 891 12.2. Informative References 893 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 894 Registration Procedure", BCP 31, RFC 2506, March 1999. 896 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 897 "Indicating User Agent Capabilities in the Session 898 Initiation Protocol (SIP)", RFC 3840, August 2004. 900 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 901 Preferences for the Session Initiation Protocol (SIP)", 902 RFC 3841, August 2004. 904 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 905 (IANA) Header Field Parameter Registry for the Session 906 Initiation Protocol (SIP)", BCP 98, RFC 3968, 907 December 2004. 909 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 910 of Extensions to the Session Initiation Protocol (SIP)", 911 RFC 4485, May 2006. 913 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 914 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 915 May 2008. 917 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 918 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 920 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 921 Initiated Connections in the Session Initiation Protocol 922 (SIP)", RFC 5626, October 2009. 924 [3GPP.23.237] 925 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 926 Stage 2", 3GPP TS 23.237 10.9.0, March 2012. 928 [3GPP.24.837] 929 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 930 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 931 10.0.0, April 2011. 933 Authors' Addresses 935 Christer Holmberg 936 Ericsson 937 Hirsalantie 11 938 Jorvas 02420 939 Finland 941 Email: christer.holmberg@ericsson.com 943 Ivo Sedlacek 944 Ericsson 945 Scheelevaegen 19C 946 Lund 22363 947 Sweden 949 Email: ivo.sedlacek@ericsson.com 951 Hadriel Kaplan 952 Acme Packet 953 71 Third Ave. 954 Burlington, MA 01803 955 USA 957 Email: hkaplan@acmepacket.com