idnits 2.17.1 draft-ietf-sipcore-proxy-feature-09.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 4, 2012) is 4252 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 8, 2013 H. Kaplan 6 Acme Packet 7 September 4, 2012 9 Mechanism to indicate support of features and capabilities in the 10 Session Initiation Protocol (SIP) 11 draft-ietf-sipcore-proxy-feature-09.txt 13 Abstract 15 This specification defines a new SIP header field, Feature-Caps, to 16 convey feature capability indicators, which are used by SIP entities 17 not represented by the URI of the Contact header field to indicate 18 support of features and capabilities, where media feature tags cannot 19 be used to indicate the support. 21 This specification also defines feature capability indicators, and 22 creates a new IANA registry, "Proxy-Feature Feature Capability 23 Indicator Trees", for registering feature capability indicators. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 8, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 4 63 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 5 65 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 6 67 4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 6 68 4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 6 69 4.3. SIP Message Type and Response Code Semantics . . . . . . . 7 70 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 7 72 4.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 8 73 4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8 74 5. Feature Capability Indicators . . . . . . . . . . . . . . . . 9 75 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 9 77 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 9 79 5.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.3. Feature Capability Indicator Specification Requirements . 10 81 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.3.2. Overall Description . . . . . . . . . . . . . . . . . 11 83 5.3.3. Feature Capability Indicator Values . . . . . . . . . 11 84 5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11 85 5.3.5. Interoperability Considerations . . . . . . . . . . . 12 86 5.3.6. Security Considerations . . . . . . . . . . . . . . . 12 87 5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.3.8. Other Information . . . . . . . . . . . . . . . . . . 12 89 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12 92 6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 6.3. Syntax: feature capability indicator . . . . . . . . . . . 13 94 6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 95 6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 98 7.1. Registration of the Feature-Caps header field . . . . . . 13 99 7.2. Registration of the Feature-Caps header field parameter . 14 100 7.3. Proxy-Feature Feature Capability Indicator Trees . . . . . 14 101 7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 102 7.3.2. Global Feature Capability Indicator Registration 103 Tree . . . . . . . . . . . . . . . . . . . . . . . . . 14 104 7.3.3. SIP Feature Capability Indicator Registration Tree . . 15 105 8. Feature Capability Indicator Registration Template . . . . . . 17 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 107 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 108 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 110 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 111 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 114 1. Introduction 116 The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" 117 extension, defined in RFC 3840 [RFC3840], provides a mechanism that 118 allows a SIP message to convey information relating to the 119 originator's features and capabilities, using the Contact header 120 field. 122 This specification defines a new SIP header field, Feature-Caps, to 123 convey feature capability indicators, which are used by SIP entities 124 not represented by the URI of the Contact header field to indicate 125 support of features and capabilities, where media feature tags cannot 126 be used to indicate the support. Such cases are: 128 o - The SIP entity acts as a SIP proxy. 129 o - The SIP entity acts as a SIP registrar. 130 o - The SIP entity acts as a B2BUA, where the Contact header field 131 URI represents another SIP entity. 133 NOTE: Unlike media feature tags, feature capability indicators are 134 intended to only be used with the SIP protocol. 136 This specification also defines feature capability indicators, and 137 creates a new IANA registry, "Proxy-Feature Feature Capability 138 Indicator Trees", for registering feature capability indicators. 140 2. Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in BCP 14, RFC 2119 145 [RFC2119]. 147 3. Definitions 149 Downstream SIP entity: SIP entity in the direction towards which a 150 SIP request is sent. 152 Upstream SIP entity: SIP entity in the direction from which a SIP 153 request is received. 155 4. Feature-Caps Header Field 156 4.1. Introduction 158 The Feature-Caps header field is used by SIP entities to convey 159 support of features and capabilities, by setting feature capability 160 indicators. A feature capability indicator conveyed in a Feature- 161 Caps header field indicates that a SIP entity in the SIP message 162 signalling path supports the associated feature and capability. 164 4.2. User Agent and Proxy Behavior 166 4.2.1. General 168 If the URI in a Contact header field of a request or response 169 represents a SIP entity, the entity MUST NOT indicate supported 170 features and capabilities using a Feature-Caps header field within 171 that request or response. 173 When a SIP entity receives a SIP request, or response, that contains 174 one or more Feature-Caps header fields, the feature capability 175 indicators in the header field inform the entity about the features 176 and capabilities supported by entities in the SIP message signalling 177 path. Procedures how features and capabilities are invoked are 178 outside the scope of this specification, and MUST be described by 179 individual feature capability indicator specifications. 181 NOTE: It is not possible to, as a Feature-Caps header field value, 182 convey the address of the SIP entity that inserted the Feature-Caps 183 header field. If additional data about a supported feature needs to 184 be conveyed, such as the address of the SIP entity that indicated 185 support of the feature, then the feature definition needs to define a 186 way to convey that information as a value of the associated feature 187 capability indicator. 189 When a SIP entity adds a Feature-Caps header field to a SIP message, 190 it MUST place the header field before any existing Feature-Caps 191 header field in the message to be forwarded, so that the added header 192 field becomes the top-most one. Then, when another SIP entity 193 receives a SIP request or the response, the SIP feature capability 194 indicators in the top-most Feature-Caps header field will represent 195 the supported features and capabilities "closest" to the entity. 197 For a given fc-value, as defined in section 5.3.1, feature capability 198 indicators are listed in a non-priority order, and any order of the 199 listed SIP feature capability indicators have the same meaning. For 200 example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the 201 SIP entity that inserted the feature capability indicator supports 202 the features and capabilities associated with the "foo" and "bar" 203 feature capability indicators. 205 4.2.2. B2BUA Behavior 207 The procedures in this Section applies to UAs that are part of B2BUAs 208 that are referenced in the message by a Record-Route header field 209 rather than by the URI of the Contact header field. 211 When such a UA sends a SIP request, if the UA wants to indicate 212 support of features and capabilities towards its downstream SIP 213 entities, it inserts a Feature-Caps header field to the request, 214 containing one or more feature capability indicators associated with 215 the supported features and capabilities, before it forwards the 216 request. 218 If the SIP request is triggered by another SIP request that the B2BUA 219 has received, the UA MAY forward received Feature-Caps header fields 220 by copying them to the outgoing SIP request, similar to a SIP proxy, 221 before it inserts its own Feature-Caps header field to the SIP 222 request. 224 When such a UA receives a SIP response, if the UA wants to indicate 225 support of features and capabilities towards its upstream SIP 226 entities, it inserts a Feature-Caps header field to the response, 227 containing one or more feature capability indicators associated with 228 the supported features and capabilities, before it forwards the 229 response. 231 If the SIP response is triggered by another SIP response that the 232 B2BUA has received, the UA MAY forward received Feature-Caps header 233 field by copying them to the outgoing SIP response, similar to a SIP 234 proxy, before it inserts its own Feature-Caps header field to the SIP 235 response. 237 4.2.3. Registrar Behavior 239 If a SIP registrar wants to indicate support of features and 240 capabilities towards its upstream SIP entities, it inserts a Feature- 241 Caps header field, containing one or more feature capability 242 indicators associated with the supported features and capabilities, 243 to a REGISTER response. 245 4.2.4. Proxy behavior 247 When a SIP proxy receives a SIP request, if the proxy wants to 248 indicate support of features and capabilities towards its downstream 249 SIP entities, it inserts a Feature-Caps header field to the request, 250 containing one or more SIP feature capability indicators associated 251 with the supported features and capabilities, before it forwards the 252 request. 254 When a proxy receives a SIP response, if the proxy wants to indicate 255 support of features and capabilities towards its upstream SIP 256 entities, it inserts a Feature-Caps header field to the response, 257 containing one or more SIP feature capability indicators associated 258 with the supported features and capabilities, before it forwards the 259 response. 261 4.3. SIP Message Type and Response Code Semantics 263 4.3.1. General 265 This Section describes the general usage and semantics of the 266 Feature-Caps header field for different SIP message types and 267 response codes. 269 Section 6.2.1 defines the Feature-Caps header field ABNF. 271 4.3.2. SIP Dialog 273 The Feature-Caps header field can be used within an initial SIP 274 request for a dialog, within a target refresh SIP request, and within 275 any 18x or 2xx response associated with such requests. 277 If a feature capability indicator is inserted in a Feature-Caps 278 header field of an initial request for a dialog, or within a response 279 of such request, it indicates to the receivers of the request (or 280 response) that the feature associated with the feature capability 281 indicator is supported for the duration of the dialog, until a target 282 refresh request is sent for the dialog, or the dialog is terminated. 284 Unless a feature capability indicator is inserted in a Feature-Caps 285 header field of a target refresh request, or within a response of 286 such request, it indicates to the receivers of the request (or 287 response) that the feature is no longer supported for the dialog. 289 For a given dialog a SIP entity MUST insert the same feature 290 capability indicators in all 18x and 2xx responses associated with a 291 given transaction. 293 NOTE: As it cannot be guaranteed that 2xx responses associated with 294 SIP SUBSCRIBE requests will reach the UAC, due to forking of the 295 request, entities need to indicate supported features and 296 capabilities in the SIP NOTIFY request that will be sent for each of 297 the created subscription dialogs. 299 4.3.3. SIP Registration (REGISTER) 301 The Feature-Caps header field can be used within a SIP REGISTER 302 request, and within the 200 (OK) response associated with such 303 request. 305 If a feature capability indicator is conveyed in a Feature-Caps 306 header field of a REGISTER request, or within an associated response, 307 it indicates to the receivers of the message that the feature 308 associated with the feature capability indicator is supported for the 309 registration, until the registration of the contact that was 310 explicitly conveyed in the REGISTER request expires, or until the 311 registered contact is explicitly refreshed and the refresh REGISTER 312 request does not contain the feature capability indicator associated 313 with the feature. 315 NOTE: While a REGISTER response can contain contacts that have been 316 registered as part of other registration transactions, support of any 317 indicated feature only applies to requests sent to the contact(s) 318 that were explicitly conveyed in the associated REGISTER request. 320 This specification does not define any semantics for usage of the 321 Feature-Caps header field in pure registration binding fetching 322 messages (see Section 10.2.3 of RFC 3261), where the REGISTER request 323 does not contain a Contact header field. Unless such semantics is 324 defined in a future extension, fetching messages will not have any 325 impact on previously indicated support of features and capabilities, 326 and SIP entities MUST NOT insert a Feature-Caps header field to such 327 messages. 329 If SIP Outbound [RFC5626] is used, the rules above apply. However, 330 supported features and capabilities only apply for the registration 331 flow on which support has been explicitly indicated. 333 4.3.4. SIP Stand-Alone Transactions 335 The Feature-Caps header field can be used within a standalone SIP 336 request, and within any 2xx response associated with such request. 338 If a feature capability indicator is inserted in a Feature-Caps 339 header field of a standalone request, or within a response of such 340 request, it indicates to the receivers of the request (or response) 341 that the feature associated with the feature capability indicator is 342 supported for the duration of the standalone transaction. 344 5. Feature Capability Indicators 346 5.1. Introduction 348 Feature capability indicators are used by SIP entities not 349 represented by the URI of the Contact header field to indicate 350 support of features and capabilities, where media feature tags cannot 351 be used to indicate the support. 353 A value, or a list of values, that provides additional information 354 about the supported feature or capability, can be associated with a 355 feature capability indicator. 357 5.2. Registration Trees 359 5.2.1. General 361 The following subsections define registration trees, distinguished by 362 the use of faceted names (e.g., names of the form "tree.feature- 363 name"). The registration trees are defined in the IANA "Proxy- 364 Feature Feature Capability Indicator Trees" registry. 366 The trees defined herein are similar to the global tree and sip tree 367 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840. 368 Other registration trees are outside the scope of this specification. 370 NOTE: In contrast to RFC 2506 and RFC 3840, this specification only 371 defines a global tree and a sip tree, as they are the only trees 372 defined in those RFCs that have been used for defining SIP-specific 373 media feature tags. 375 When a feature capability indicator is registered in any registration 376 tree, no leading "+" is used in the registration. 378 5.2.2. Global Tree 380 The global feature capability indicator tree is similar to the media 381 feature tag global tree defined in RFC 2506 [RFC2506]. 383 A feature capability indicator for the global tree will be registered 384 by the IANA after review by a designated expert. That review will 385 serve to ensure that the definition of the feature capability 386 indicator meets the technical requirements of this specification. 388 A feature capability indicator in the global tree will be 389 distinguished by the leading facet "g.". An organization can propose 390 either a designation indicative of the feature, (e.g., "g.blinktags") 391 or a faceted designation including the organization name (e.g., 392 "g.organization.blinktags"). 394 When a feature capability indicator is registered in the global tree, 395 it needs to meet the "Specification Required" policies defined in RFC 396 5226 [RFC5226]. A designated area expert will review the proposed 397 feature capability indicator, and consult with members of related 398 mailing lists. 400 5.2.3. SIP Tree 402 The sip feature capability indicator tree is similar to the media 403 feature tag sip tree defined in RFC 3840. 405 A feature capability indicator in the sip tree will be distinguished 406 by the leading facet "sip.". 408 When a feature capability indicator is registered in the sip tree, it 409 needs to meet the "IETF Consensus" policies defined in RFC 5226. An 410 RFC, which contains the registration of the feature capability 411 indicator, MUST be published. 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 SIP feature capability indicator 436 require 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 If there are specific interoperability considerations that apply to 491 the feature capability indicator, the feature capability indicator 492 specification MUST document such considerations. 494 5.3.6. Security Considerations 496 If there are specific security considerations that apply to the 497 feature capability indicator, the feature capability indicator 498 specification MUST document such considerations. 500 5.3.7. Examples 502 It is RECOMMENDED that the feature capability indicator specification 503 provide demonstrative message flow diagrams, paired with complete 504 messages and message descriptions. 506 Note that example message flows are by definition informative, and do 507 not replace normative text. 509 5.3.8. Other Information 511 If there is additional information about the feature capability 512 indicator, it is RECOMMENDED to describe such information. It can 513 include e.g. names of related feature capability indicators. 515 6. Syntax 517 6.1. General 519 This Section defines the ABNF for the Feature-Caps header field, and 520 for the feature capability indicators. 522 6.2. Syntax: Feature-Caps header field 524 6.2.1. ABNF 526 The ABNF for the Feature-Caps header fields is: 528 Feature-Caps = "Feature-Caps" HCOLON fc-value 529 *(COMMA fc-value) 530 fc-value = "*" *(SEMI feature-cap) 531 Figure 1: ABNF 533 NOTE: The "*" value is present in order to follow the guidelines for 534 syntax in RFC 4485 [RFC4485] and to maintain a consistent format with 535 RFC 3840 and RFC 3841 [RFC3841]. 537 6.3. Syntax: feature capability indicator 539 6.3.1. General 541 In a feature capability indicator name (ABNF: fcap-name), dots can be 542 used to implement a feature capability indicator tree hierarchy (e.g. 543 tree.feature.subfeature). The description of usage of such tree 544 hierarchy must be described when registered. 546 6.3.2. ABNF 548 The ABNF for the feature capability indicator: 550 feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list 551 / fcap-string-value ) RDQUOT] 552 fcap-name = ftag-name 553 fcap-value-list = tag-value-list 554 fcap-string-value = string-value 555 ;; ftag-name, tag-value-list, string-value defined in RFC 3840 557 NOTE: In comparison with media feature tags, the "+" sign in front 558 of the feature capability indicator name is mandatory. 560 Figure 2: ABNF 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 Figure 3: SIP Parameter Header Field 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 7.3.2. Global Feature Capability Indicator Registration Tree 609 This specification creates a new feature capability indicator tree in 610 the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. 611 The name of the tree is "Global Feature Capability Indicator 612 Registration Tree", and its leading facet is "g.". It is used for 613 the registration of feature capability indicators. 615 When a feature capability indicator is registered in the global tree, 616 it needs to meet the "Specification Required" policies defined in RFC 617 5226. A designated area expert will review the proposed feature 618 capability indicator, and consult with members of related mailing 619 lists. The information required in the registration is defined in 620 Section 5.3 of RFC XXXX. 622 Note that all feature capability indicators registered in the global 623 tree will have names with a leading facet "g.". No leading "+" is 624 used in the registrations in any of the feature capability indicator 625 registration trees. 627 The format of the global tree is as described below: 629 Name Description Reference 630 ------------------------------ 632 Name contains the Feature Capability Indicator Name, provided 633 in the registration feature capability indication registration 634 template. 636 Description, provided in the registration feature capability 637 indication registration template. 639 Reference contains the Feature Capability Indicator Specification 640 Reference, provided in the registration feature capability 641 indication registration template. 643 Figure 4 645 7.3.3. SIP Feature Capability Indicator Registration Tree 647 This specification creates a new feature capability indicator tree in 648 the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. 649 The name of the tree is "SIP Feature Capability Indicator 650 Registration Tree", and its leading facet is "sip.". It is used for 651 the registration of feature capability indicators. 653 When a feature capability indicator is registered in the sip tree, it 654 needs to meet the "IETF Consensus" policies defined in RFC 5226. An 655 RFC, which contains the registration of the feature capability 656 indicator, MUST be published. The information required in the 657 registration is defined in Section 5.3 of RFC XXXX. 659 Note that all feature capability indicators registered in the SIP 660 tree will have names with a leading facet "sip.". No leading "+" is 661 used in the registrations in any of the feature capability indicator 662 registration trees. 664 The format of the SIP tree is as described below: 666 Name Description Reference 667 ------------------------------ 669 Name contains the Feature Capability Indicator Name, provided 670 in the registration feature capability indication registration 671 template. 673 Description, provided in the registration feature capability 674 indication registration template. 676 Reference contains the Feature Capability Indicator Specification 677 Reference, provided in the registration feature capability 678 indication registration template. 680 Figure 5 682 8. Feature Capability Indicator Registration Template 684 Registration requests for the global tree are submitted 685 by e-mail to iana@iana.org. 687 Registration requests for the sip tree requires submitting 688 an Internet-Draft to the IESG. 690 | Instructions are preceded by '|'. All fields are mandatory. 692 Feature capability indicator name: 694 Description: 696 | The description should be no longer than 4 lines. More 697 | detailed information can be provided in the feature 698 | capability indicator specification. 700 Feature capability indicator name: 702 | The referenced specification MUST contain the information 703 | listed in Section 5.3 of RFC XXXX. 705 Feature capability indicator specification reference: 707 | The referenced specification MUST contain the information 708 | listed in Section 5.3 of RFC XXXX. 710 Contact: 712 | Name(s) & email address(es) of person(s) to 713 | contact for further information." 715 (IANA: Please replace XXXX with the assigned RFC number) 717 Figure 6: Registration Template 719 9. Security Considerations 721 The security issues for feature capability indicators are similar to 722 the ones defined in RFC 3840 for media feature tags. Media feature 723 tags can reveal information about end-users and end-user equipment, 724 which can be used for industrial espionage. The knowledge about end- 725 user equipment capabilities can also be used to influence application 726 behavior. As feature capability indicators are not intended to 727 convey capability information of end-user devices, such end-user 728 security aspects of RFC 3840 do not apply to feature capability 729 indicators. 731 In addition, the RFC 3840 security issue regarding an attacker using 732 the SIP caller preferences extension [RFC3841] in order to affect 733 routing decisions does not apply, as the mechanism is not defined to 734 be used with feature capability indicators. 736 Feature capability indicators can, however, provide capability and 737 characteristics information about the SIP entity, some of which might 738 be sensitive. Malicious elements viewing the indicators may be able 739 to discern application deployment details or identify elements with 740 exploitable feature implementation weaknesses. The Feature-Caps 741 header field does not convey address information about SIP entities. 742 However, individual feature capability indicators might provide 743 address information as feature capability indicator values. 744 Therefore, mechanisms for guaranteeing confidentiality and 745 authenticity SHOULD be provided. 747 10. Acknowledgements 749 The authors wish to thank everyone in the SIP community that provided 750 input and feedback on the work of this specification. 752 11. Change Log 754 [RFC EDITOR NOTE: Please remove this Section when publishing] 756 Changes from draft-holmberg-sipcore-proxy-feature-08 757 o Comments from Atle Mondrad. 759 Changes from draft-holmberg-sipcore-proxy-feature-06 760 o Editorial changes. 762 Changes from draft-holmberg-sipcore-proxy-feature-05 763 o AD comments from Robert Sparks 764 o Additional text added to the Security Considerations section. 765 o IANA registration template modified. 766 o IANA registration procedures clarified. 767 o Feature Capability Indicator specification requirements modified. 768 o Note regarding SUBSCRIBE 200 responses added. 769 o Editorial modifications. 771 Changes from draft-holmberg-sipcore-proxy-feature-04 772 o WGLC comments from Keith Drage 773 o 'feature cap' name changed to 'feature capability indicator'. 774 o Feature-Caps header field added to IANA Header Field Parameters 775 and Parameter Values registry. 776 o Editorial modifications. 778 Changes from draft-ietf-sipcore-proxy-feature-03 779 o Additional Security Considerations text added. 780 o IANA Considerations modified. 781 o Editorial corrections. 783 Changes from draft-ietf-sipcore-proxy-feature-02 784 o Changes based on WGLC comments from Shida Schubert. 785 o - Document title changed 786 o - Terminology alignment 787 o - Note text clarifications 788 o Changes based on WGLC comments from Lili Yang. 790 Changes from draft-ietf-sipcore-proxy-feature-01 791 o Changes based on comments from Paul Kyzivat. 792 o IANA Considerations text added. 794 Changes from draft-holmberg-sipcore-proxy-feature-04/ 795 draft-ietf-sipcore-proxy-feature-00 796 o Media feature tags replaced with feature caps, based on SIPCORE 797 consensus at IETF#83 (Paris). 798 o Editorial corrections and modifications. 800 Changes from draft-holmberg-sipcore-proxy-feature-03 801 o Hadriel Kaplan added as co-author. 802 o Terminology change: instead of talking of proxies, talk about 803 entities which are not represented by the URI in a Contact header 804 field (http://www.ietf.org/mail-archive/web/sipcore/current/ 805 msg04449.html). 806 o Clarification regarding the usage of the header field in 18x/2xx 807 responses (http://www.ietf.org/mail-archive/web/sipcore/current/ 808 msg04449.html). 809 o Specifying that feature support can also be indicated in target 810 refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ 811 current/msg04454.html). 812 o Feature Cap specification registration information added. 814 Changes from draft-holmberg-sipcore-proxy-feature-02 815 o Definition, and usage of, a new header field, instead of Path, 816 Record-Route, Route and Service-Route. 818 Changes from draft-holmberg-sipcore-proxy-feature-01 819 o Requirement section added 820 o Use-cases and examples updated based on work in 3GPP 822 Changes from draft-holmberg-sipcore-proxy-feature-00 823 o Additional use-cases added 824 o Direction section added 826 12. References 828 12.1. Normative References 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, March 1997. 833 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 834 A., Peterson, J., Sparks, R., Handley, M., and E. 835 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 836 June 2002. 838 12.2. Informative References 840 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 841 Registration Procedure", BCP 31, RFC 2506, March 1999. 843 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 844 "Indicating User Agent Capabilities in the Session 845 Initiation Protocol (SIP)", RFC 3840, August 2004. 847 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 848 Preferences for the Session Initiation Protocol (SIP)", 849 RFC 3841, August 2004. 851 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 852 (IANA) Header Field Parameter Registry for the Session 853 Initiation Protocol (SIP)", BCP 98, RFC 3968, 854 December 2004. 856 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 857 of Extensions to the Session Initiation Protocol (SIP)", 858 RFC 4485, May 2006. 860 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 861 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 862 May 2008. 864 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 865 Initiated Connections in the Session Initiation Protocol 866 (SIP)", RFC 5626, October 2009. 868 [3GPP.23.237] 869 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 870 Stage 2", 3GPP TS 23.237 10.9.0, March 2012. 872 [3GPP.24.837] 873 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 874 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 875 10.0.0, April 2011. 877 Authors' Addresses 879 Christer Holmberg 880 Ericsson 881 Hirsalantie 11 882 Jorvas 02420 883 Finland 885 Email: christer.holmberg@ericsson.com 887 Ivo Sedlacek 888 Ericsson 889 Scheelevaegen 19C 890 Lund 22363 891 Sweden 893 Email: ivo.sedlacek@ericsson.com 895 Hadriel Kaplan 896 Acme Packet 897 71 Third Ave. 898 Burlington, MA 01803 899 USA 901 Email: hkaplan@acmepacket.com