idnits 2.17.1 draft-ietf-sipcore-proxy-feature-10.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 (September 21, 2012) is 4234 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 585, but not defined -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: March 25, 2013 H. Kaplan 6 Acme Packet 7 September 21, 2012 9 Mechanism to indicate support of features and capabilities in the 10 Session Initiation Protocol (SIP) 11 draft-ietf-sipcore-proxy-feature-10.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 header field to 23 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 March 25, 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 . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 107 7.3.3. SIP Feature Capability Indicator Registration Tree . . 15 108 8. Feature Capability Indicator Registration Template . . . . . . 16 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 110 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 111 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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 header field to 139 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" to the entity. 206 For a given fc-value, as defined in section 6.2.1, the order in which 207 feature capability indicators are listed has no significance. For 208 example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the 209 SIP entity that inserted the feature capability indicator supports 210 the features and capabilities associated with the "foo" and "bar" 211 feature capability indicators. 213 4.2.2. B2BUA Behavior 215 The procedures in this Section apply to User Agents (UAs) [RFC3261] 216 that are part of B2BUAs that are referenced in the message by a 217 Record-Route header field rather than by the URI of the Contact 218 header field. 220 When such a UA sends a SIP request, if the UA wants to indicate 221 support of features and capabilities towards its downstream SIP 222 entities, it inserts a Feature-Caps header field to the request, 223 containing one or more feature capability indicators associated with 224 the supported features and capabilities, before it forwards the 225 request. 227 If the SIP request is triggered by another SIP request that the B2BUA 228 has received, the UA MAY forward received Feature-Caps header fields 229 by copying them to the outgoing SIP request, similar to a SIP proxy, 230 before it inserts its own Feature-Caps header field to the SIP 231 request. 233 When such a UA receives a SIP response, if the UA wants to indicate 234 support of features and capabilities towards its upstream SIP 235 entities, it inserts a Feature-Caps header field to the response, 236 containing one or more feature capability indicators associated with 237 the supported features and capabilities, before it forwards the 238 response. 240 If the SIP response is triggered by another SIP response that the 241 B2BUA has received, the UA MAY forward received Feature-Caps header 242 field by copying them to the outgoing SIP response, similar to a SIP 243 proxy, before it inserts its own Feature-Caps header field to the SIP 244 response. 246 4.2.3. Registrar Behavior 248 If a SIP registrar wants to indicate support of features and 249 capabilities towards its upstream SIP entities, it inserts a Feature- 250 Caps header field, containing one or more feature capability 251 indicators associated with the supported features and capabilities, 252 to a REGISTER response. 254 4.2.4. Proxy behavior 256 When a SIP proxy receives a SIP request, if the proxy wants to 257 indicate support of features and capabilities towards its downstream 258 SIP entities, it inserts a Feature-Caps header field to the request, 259 containing one or more SIP feature capability indicators associated 260 with the supported features and capabilities, before it forwards the 261 request. 263 When a proxy receives a SIP response, if the proxy wants to indicate 264 support of features and capabilities towards its upstream SIP 265 entities, it inserts a Feature-Caps header field to the response, 266 containing one or more SIP feature capability indicators associated 267 with the supported features and capabilities, before it forwards the 268 response. 270 4.3. SIP Message Type and Response Code Semantics 272 4.3.1. General 274 This Section describes the general usage and semantics of the 275 Feature-Caps header field for different SIP message types and 276 response codes. 278 Section 6.2.1 defines the Feature-Caps header field ABNF. 280 4.3.2. SIP Dialog 282 The Feature-Caps header field can be used within an initial SIP 283 request for a dialog, within a target refresh SIP request, and within 284 any 18x or 2xx response associated with such requests. 286 If a feature capability indicator is inserted in a Feature-Caps 287 header field of an initial request for a dialog, or within a response 288 of such request, it indicates to the receivers of the request (or 289 response) that the feature associated with the feature capability 290 indicator is supported for the duration of the dialog, until a target 291 refresh request is sent for the dialog, or the dialog is terminated. 293 Unless a feature capability indicator is inserted in a Feature-Caps 294 header field of a target refresh request, or within a response of 295 such request, it indicates to the receivers of the request (or 296 response) that the feature is no longer supported for the dialog. 298 For a given dialog a SIP entity MUST insert the same feature 299 capability indicators in all 18x and 2xx responses associated with a 300 given transaction. 302 As it cannot be guaranteed that 2xx responses associated with SIP 303 SUBSCRIBE requests will reach the User Agent Client (UAC) [RFC3261], 304 due to forking of the request, entities need to indicate supported 305 features and capabilities in the SIP NOTIFY request that will be sent 306 for each of the created subscription dialogs. 308 4.3.3. SIP Registration (REGISTER) 310 The Feature-Caps header field can be used within a SIP REGISTER 311 request, and within the 200 (OK) response associated with such 312 request. 314 If a feature capability indicator is conveyed in a Feature-Caps 315 header field of a REGISTER request, or within an associated response, 316 it indicates to the receivers of the message that the feature 317 associated with the feature capability indicator is supported for the 318 registration, until the registration of the contact that was 319 explicitly conveyed in the REGISTER request expires, or until the 320 registered contact is explicitly refreshed and the refresh REGISTER 321 request does not contain the feature capability indicator associated 322 with the feature. 324 While a REGISTER response can contain contacts that have been 325 registered as part of other registration transactions, support of any 326 indicated feature only applies to requests sent to the contact(s) 327 that were explicitly conveyed in the associated REGISTER request. 329 This specification does not define any semantics for usage of the 330 Feature-Caps header field in pure registration binding fetching 331 messages (see Section 10.2.3 of RFC 3261), where the REGISTER request 332 does not contain a Contact header field. Unless such semantics is 333 defined in a future extension, fetching messages will not have any 334 impact on previously indicated support of features and capabilities, 335 and SIP entities MUST NOT insert a Feature-Caps header field to such 336 messages. 338 If SIP Outbound [RFC5626] is used, the rules above apply. However, 339 supported features and capabilities only apply for the registration 340 flow on which support has been explicitly indicated. 342 4.3.4. SIP Stand-Alone Transactions 344 The Feature-Caps header field can be used within a standalone SIP 345 request, and within any 2xx response associated with such request. 347 If a feature capability indicator is inserted in a Feature-Caps 348 header field of a standalone request, or within a response of such 349 request, it indicates to the receivers of the request (or response) 350 that the feature associated with the feature capability indicator is 351 supported for the duration of the standalone transaction. 353 5. Feature Capability Indicators 355 5.1. Introduction 357 Feature capability indicators are used by SIP entities not 358 represented by the URI of the Contact header field to indicate 359 support of features and capabilities, where media feature tags cannot 360 be used to indicate the support. 362 A value, or a list of values, that provides additional information 363 about the supported feature or capability, can be associated with a 364 feature capability indicator. 366 5.2. Registration Trees 368 5.2.1. General 370 The following subsections define registration trees, distinguished by 371 the use of faceted names (e.g., names of the form "tree.feature- 372 name"). The registration trees are defined in the IANA "Proxy- 373 Feature Feature Capability Indicator Trees" registry. 375 The trees defined herein are similar to the global tree and sip tree 376 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840. 377 Other registration trees are outside the scope of this specification. 379 In contrast to RFC 2506 and RFC 3840, this specification only defines 380 a global tree and a sip tree, as they are the only trees defined in 381 those RFCs that have been used for defining SIP-specific media 382 feature tags. 384 When a feature capability indicator is registered in any registration 385 tree, no leading "+" is used in the registration. 387 5.2.2. Global Tree 389 The global feature capability indicator tree is similar to the media 390 feature tag global tree defined in RFC 2506 [RFC2506]. 392 A feature capability indicator in the global tree will be 393 distinguished by the leading facet "g.". An organization can propose 394 either a designation indicative of the feature, (e.g., "g.blinktags") 395 or a faceted designation including the organization name (e.g., 396 "g.organization.blinktags"). 398 When a feature capability indicator is registered in the global tree, 399 it needs to meet the "Specification Required" policies defined in RFC 400 5226 [RFC5226]. A designated area expert will review the proposed 401 feature capability indicator, and consult with members of related 402 mailing lists. 404 5.2.3. SIP Tree 406 The sip feature capability indicator tree is similar to the media 407 feature tag sip tree defined in RFC 3840. 409 A feature capability indicator in the sip tree will be distinguished 410 by the leading facet "sip.". 412 5.3. Feature Capability Indicator Specification Requirements 414 5.3.1. General 416 A feature capability indicator specification MUST address the issues 417 defined in the following subsections, or document why an issue is not 418 applicable for the specific feature capability indicator. A 419 reference to the specification MUST be provided when the feature 420 capability indicator is registered with IANA (see Section 8). 422 It is bad practice for feature capability indicator specifications to 423 repeat procedures (e.g. general procedures on the usage of the 424 Feature-Caps header field and feature capability indicators) defined 425 in this specification, unless needed for clarification or emphasis 426 purpose. A feature capability indicator specification MUST NOT 427 modify the Feature-Caps header field rules and semantics defined in 428 Section 4. 430 A feature capability indicator specification MUST NOT weaken any 431 behavior designated with "SHOULD" or "MUST" in this specification. 432 However, a specification MAY strengthen "SHOULD", "MAY", or 433 "RECOMMENDED" requirements to "MUST" strength if features and 434 capabilities associated with the SIP feature capability indicator 435 require it. 437 5.3.2. Overall Description 439 The feature capability indicator specification MUST contain an 440 overall description of the feature capability indicator: how it is 441 used to indicate support of a feature, a description of the feature 442 associated with the feature capability indicator, a description of 443 any additional information (conveyed using one or more feature 444 capability indicator values) that can be conveyed together with the 445 feature capability indicator, and a description of how the associated 446 feature may be exercised/invoked. 448 5.3.3. Feature Capability Indicator Values 450 A feature capability indicator can have an associated value, or a 451 list of values. The feature capability indicator specification MUST 452 define the syntax and semantics of any value defined for the feature 453 capability indicator, including possible restrictions related to the 454 usage of a specific value. The feature capability indicator 455 specification MUST define the value(s) in accordance with the ABNF 456 defined in Section 6.3.2. The feature capability indicator 457 specification MUST define whether the feature capability indicator 458 has a default value. 460 If no values are defined for the feature capability indicator, it 461 MUST be indicated in the feature capability indicator specification. 463 A feature capability indicator value is only applicable for the 464 feature capability indicator for which it has been defined. For 465 other feature capability indicators, the value has to be defined 466 explicitly, even if the semantics are identical. 468 It is strongly RECOMMENDED to not re-use a value that already has 469 been defined for another feature capability indicator, unless the 470 semantics of the values are the same. 472 5.3.4. Usage Restrictions 474 If there are restrictions on how SIP entities can insert a feature 475 capability indicator, the feature capability indicator specification 476 MUST document such restrictions. 478 There might be restrictions related to whether entities are allowed 479 to insert a feature capability indicator in registration related 480 messages, standalone transaction messages, dialog related messages, 481 whether entities are allowed to insert a feature capability indicator 482 in requests or responses, whether entities also need to support other 483 features and capabilities in order to insert a feature capability 484 indicator, and whether entities are allowed to indicate support of a 485 feature in conjunction with another feature. 487 5.3.5. Interoperability Considerations 489 If there are specific interoperability considerations that apply to 490 the feature capability indicator, the feature capability indicator 491 specification MUST document such considerations. 493 Interoperability considerations can e.g. include procedures related 494 to cases where an expected feature capability indicator is not 495 present, or where it contains an unexpected value. 497 5.3.6. Security Considerations 499 If there are specific security considerations that apply to the 500 feature capability indicator, the feature capability indicator 501 specification MUST document such considerations. 503 5.3.7. Examples 505 It is RECOMMENDED that the feature capability indicator specification 506 provide demonstrative message flow diagrams, paired with complete 507 messages and message descriptions. 509 Note that example message flows are by definition informative, and do 510 not replace normative text. 512 5.3.8. Other Information 514 If there is additional information about the feature capability 515 indicator, it is RECOMMENDED to describe such information. It can 516 include e.g. names of related feature capability indicators. 518 6. Syntax 520 6.1. General 522 This Section defines the ABNF for the Feature-Caps header field, and 523 for the feature capability indicators. 525 6.2. Syntax: Feature-Caps header field 527 6.2.1. ABNF 529 The ABNF for the Feature-Caps header fields is: 531 Feature-Caps = "Feature-Caps" HCOLON fc-value 532 *(COMMA fc-value) 533 fc-value = "*" *(SEMI feature-cap) 535 NOTE: The "*" value is present in order to follow the guidelines for 536 syntax in RFC 4485 [RFC4485] and to maintain a consistent format with 537 RFC 3840 and RFC 3841 [RFC3841]. 539 6.3. Syntax: feature capability indicator 541 6.3.1. General 543 In a feature capability indicator name (ABNF: fcap-name), dots can be 544 used to implement a feature capability indicator tree hierarchy (e.g. 545 tree.feature.subfeature). The description of usage of such tree 546 hierarchy must be described when registered. 548 6.3.2. ABNF 550 The ABNF for the feature capability indicator: 552 feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list 553 / fcap-string-value ) RDQUOT] 554 fcap-name = ftag-name 555 fcap-value-list = tag-value-list 556 fcap-string-value = string-value 557 ;; ftag-name, tag-value-list, string-value defined in RFC 3840 559 NOTE: In comparison with media feature tags, the "+" sign in front 560 of the feature capability indicator name is mandatory. 562 7. IANA Considerations 564 7.1. Registration of the Feature-Caps header field 566 This specification registers a new SIP header field, Feature-Caps, 567 according to the process of RFC 3261 [RFC3261]. 569 The following is the registration for the Feature-Caps header field: 571 RFC Number: RFC XXXX 573 Header Field Name: Feature-Caps 575 7.2. Registration of the Feature-Caps header field parameter 577 This specification adds the Feature-Caps header field to the IANA 578 "Header Field Parameters and Parameter Values" registry, according to 579 the process of RFC 3968 [RFC3968]. 581 Predefined 582 Header Field Parameter Name Values Reference 583 ------------------------------------------------------------------ 585 Feature-Caps + * No [RFC XXXX] 587 * denotes parameter names conforming to the 588 syntax defined in RFC XXXX. Valid 589 feature capability indicators are registered in [IANA: 590 insert reference to the new Proxy-Feature Feature 591 Capability Indicator Trees registry]. 593 (IANA: please sort the "Feature-Caps" line into the table and place 594 the remainder of the above as a footnote to the table.) 596 7.3. Proxy-Feature Feature Capability Indicator Trees 598 7.3.1. Introduction 600 This specification creates a new sub registry to the IANA "Session 601 Initiation Protocol (SIP) Parameters" Protocol Registry, according to 602 the process of RFC 5226. The name of the sub registry is "Proxy- 603 Feature Feature Capability Indicator Trees". 605 7.3.2. Global Feature Capability Indicator Registration Tree 607 This specification creates a new feature capability indicator tree in 608 the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. 609 The name of the tree is "Global Feature Capability Indicator 610 Registration Tree", and its leading facet is "g.". It is used for 611 the registration of feature capability indicators. 613 When a feature capability indicator is registered in the global tree, 614 it needs to meet the "Specification Required" policies defined in RFC 615 5226. A designated area expert will review the proposed feature 616 capability indicator, and consult with members of related mailing 617 lists. The information required in the registration is defined in 618 Section 5.3 of RFC XXXX. 620 Note that all feature capability indicators registered in the global 621 tree will have names with a leading facet "g.". No leading "+" is 622 used in the registrations in any of the feature capability indicator 623 registration trees. 625 The format of the global tree is as described below: 627 Name Description Reference 628 ------------------------------ 630 Name contains the Feature Capability Indicator Name, provided 631 in the registration feature capability indication registration 632 template. 634 Description, provided in the registration feature capability 635 indication registration template. 637 Reference contains the Feature Capability Indicator Specification 638 Reference, provided in the registration feature capability 639 indication registration template. 641 7.3.3. SIP Feature Capability Indicator Registration Tree 643 This specification creates a new feature capability indicator tree in 644 the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. 645 The name of the tree is "SIP Feature Capability Indicator 646 Registration Tree", and its leading facet is "sip.". It is used for 647 the registration of feature capability indicators. 649 When a feature capability indicator is registered in the sip tree, it 650 needs to meet the "IETF Consensus" policies defined in RFC 5226. The 651 information required in the registration is defined in Section 5.3 of 652 RFC XXXX. 654 Note that all feature capability indicators registered in the SIP 655 tree will have names with a leading facet "sip.". No leading "+" is 656 used in the registrations in any of the feature capability indicator 657 registration trees. 659 The format of the SIP tree is as described below: 661 Name Description Reference 662 ------------------------------ 664 Name contains the Feature Capability Indicator Name, provided 665 in the registration feature capability indication registration 666 template. 668 Description, provided in the registration feature capability 669 indication registration template. 671 Reference contains the Feature Capability Indicator Specification 672 Reference, provided in the registration feature capability 673 indication registration template. 675 8. Feature Capability Indicator Registration Template 677 Registration requests for the global tree are submitted 678 by e-mail to iana@iana.org. 680 Registration requests for the sip tree requires submitting 681 an Internet-Draft to the IESG. 683 | Instructions are preceded by '|'. All fields are mandatory. 685 Feature capability indicator name: 687 Description: 689 | The description should be no longer than 4 lines. More 690 | detailed information can be provided in the feature 691 | capability indicator specification. 693 Feature capability indicator name: 695 | The referenced specification MUST contain the information 696 | listed in Section 5.3 of RFC XXXX. 698 Feature capability indicator specification reference: 700 | The referenced specification MUST contain the information 701 | listed in Section 5.3 of RFC XXXX. 703 Contact: 705 | Name(s) & email address(es) of person(s) to 706 | contact for further information." 708 (IANA: Please replace XXXX with the assigned RFC number) 710 9. Security Considerations 712 The security issues for feature capability indicators are similar to 713 the ones defined in RFC 3840 for media feature tags. Media feature 714 tags can reveal information about end-users and end-user equipment, 715 which can be used for industrial espionage. The knowledge about end- 716 user equipment capabilities can also be used to influence application 717 behavior. As feature capability indicators are not intended to 718 convey capability information of end-user devices, such end-user 719 security aspects of RFC 3840 do not apply to feature capability 720 indicators. 722 In addition, the RFC 3840 security issue regarding an attacker using 723 the SIP caller preferences extension [RFC3841] in order to affect 724 routing decisions does not apply, as the mechanism is not defined to 725 be used with feature capability indicators. 727 Feature capability indicators can, however, provide capability and 728 characteristics information about the SIP entity, some of which might 729 be sensitive. Malicious elements viewing the indicators may be able 730 to discern application deployment details or identify elements with 731 exploitable feature implementation weaknesses. The Feature-Caps 732 header field does not convey address information about SIP entities. 733 However, individual feature capability indicators might provide 734 address information as feature capability indicator values. 735 Therefore, if the feature capability indicators provide sensitive 736 information, mechanisms for guaranteeing confidentiality and 737 authenticity MUST be provided. 739 10. Acknowledgements 741 The authors wish to thank everyone in the SIP community that provided 742 input and feedback on the work of this specification. 744 11. Change Log 746 [RFC EDITOR NOTE: Please remove this Section when publishing] 748 Changes from draft-holmberg-sipcore-proxy-feature-09 749 o Editorial changes based on SECDIR comments from Radia Perlman. 750 o Editorial changes based on Gen-Art comments from Brian E 751 Carpenter. 752 o Editorial changes based on OPSDIR comments from Jouni Korhonen. 753 o Change in security considerations indicating that, if sensitive 754 information is conveyed, mechanisms for guaranteeing 755 confidentiality and authenticity must be provided. 757 Changes from draft-holmberg-sipcore-proxy-feature-08 758 o Comments from Atle Mondrad. 760 Changes from draft-holmberg-sipcore-proxy-feature-06 761 o Editorial changes. 763 Changes from draft-holmberg-sipcore-proxy-feature-05 764 o AD comments from Robert Sparks 765 o Additional text added to the Security Considerations section. 766 o IANA registration template modified. 767 o IANA registration procedures clarified. 768 o Feature Capability Indicator specification requirements modified. 769 o Note regarding SUBSCRIBE 200 responses added. 770 o Editorial modifications. 772 Changes from draft-holmberg-sipcore-proxy-feature-04 773 o WGLC comments from Keith Drage 774 o 'feature cap' name changed to 'feature capability indicator'. 775 o Feature-Caps header field added to IANA Header Field Parameters 776 and Parameter Values registry. 777 o Editorial modifications. 779 Changes from draft-ietf-sipcore-proxy-feature-03 780 o Additional Security Considerations text added. 781 o IANA Considerations modified. 782 o Editorial corrections. 784 Changes from draft-ietf-sipcore-proxy-feature-02 785 o Changes based on WGLC comments from Shida Schubert. 786 o - Document title changed 787 o - Terminology alignment 788 o - Note text clarifications 789 o Changes based on WGLC comments from Lili Yang. 791 Changes from draft-ietf-sipcore-proxy-feature-01 792 o Changes based on comments from Paul Kyzivat. 793 o IANA Considerations text added. 795 Changes from draft-holmberg-sipcore-proxy-feature-04/ 796 draft-ietf-sipcore-proxy-feature-00 797 o Media feature tags replaced with feature caps, based on SIPCORE 798 consensus at IETF#83 (Paris). 799 o Editorial corrections and modifications. 801 Changes from draft-holmberg-sipcore-proxy-feature-03 802 o Hadriel Kaplan added as co-author. 803 o Terminology change: instead of talking of proxies, talk about 804 entities which are not represented by the URI in a Contact header 805 field (http://www.ietf.org/mail-archive/web/sipcore/current/ 806 msg04449.html). 808 o Clarification regarding the usage of the header field in 18x/2xx 809 responses (http://www.ietf.org/mail-archive/web/sipcore/current/ 810 msg04449.html). 811 o Specifying that feature support can also be indicated in target 812 refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ 813 current/msg04454.html). 814 o Feature Cap specification registration information added. 816 Changes from draft-holmberg-sipcore-proxy-feature-02 817 o Definition, and usage of, a new header field, instead of Path, 818 Record-Route, Route and Service-Route. 820 Changes from draft-holmberg-sipcore-proxy-feature-01 821 o Requirement section added 822 o Use-cases and examples updated based on work in 3GPP 824 Changes from draft-holmberg-sipcore-proxy-feature-00 825 o Additional use-cases added 826 o Direction section added 828 12. References 830 12.1. Normative References 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, March 1997. 835 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 836 A., Peterson, J., Sparks, R., Handley, M., and E. 837 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 838 June 2002. 840 12.2. Informative References 842 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 843 Registration Procedure", BCP 31, RFC 2506, March 1999. 845 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 846 "Indicating User Agent Capabilities in the Session 847 Initiation Protocol (SIP)", RFC 3840, August 2004. 849 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 850 Preferences for the Session Initiation Protocol (SIP)", 851 RFC 3841, August 2004. 853 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 854 (IANA) Header Field Parameter Registry for the Session 855 Initiation Protocol (SIP)", BCP 98, RFC 3968, 856 December 2004. 858 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 859 of Extensions to the Session Initiation Protocol (SIP)", 860 RFC 4485, May 2006. 862 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 863 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 864 May 2008. 866 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 867 Initiated Connections in the Session Initiation Protocol 868 (SIP)", RFC 5626, October 2009. 870 [3GPP.23.237] 871 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 872 Stage 2", 3GPP TS 23.237 10.9.0, March 2012. 874 [3GPP.24.837] 875 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 876 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 877 10.0.0, April 2011. 879 Authors' Addresses 881 Christer Holmberg 882 Ericsson 883 Hirsalantie 11 884 Jorvas 02420 885 Finland 887 Email: christer.holmberg@ericsson.com 889 Ivo Sedlacek 890 Ericsson 891 Scheelevaegen 19C 892 Lund 22363 893 Sweden 895 Email: ivo.sedlacek@ericsson.com 896 Hadriel Kaplan 897 Acme Packet 898 71 Third Ave. 899 Burlington, MA 01803 900 USA 902 Email: hkaplan@acmepacket.com