idnits 2.17.1 draft-ietf-sipcore-proxy-feature-05.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 (August 8, 2012) is 4272 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 2 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: February 9, 2013 H. Kaplan 6 Acme Packet 7 August 8, 2012 9 Mechanism to indicate support of features and capabilities in the 10 Session Initiation Protocol (SIP) 11 draft-ietf-sipcore-proxy-feature-05.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 February 9, 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) . . . . . . . . . . . . . 7 73 4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8 74 5. Feature Capability Indicators . . . . . . . . . . . . . . . . 8 75 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8 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. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 86 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12 89 6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 6.3. Syntax: feature capability indicator . . . . . . . . . . . 12 91 6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 12 92 6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 94 7.1. Registration of the Feature-Caps header field . . . . . . 13 95 7.2. Registration of the Feature-Caps header field parameter . 13 96 7.3. Proxy-Feature Feature Capability Indicator Trees . . . . . 14 97 7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 98 7.3.2. Global Feature Capability Indicator Registration 99 Tree . . . . . . . . . . . . . . . . . . . . . . . . . 14 100 7.3.3. SIP Feature Capability Indicator Registration Tree . . 14 101 8. Feature Capability Indicator Registration Template . . . . . . 15 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 104 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 107 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 110 1. Introduction 112 The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" 113 extension, defined in RFC 3840 [RFC3840], provides a mechanism that 114 allows a SIP message to convey information relating to the 115 originator's features and capabilities, using the Contact header 116 field. 118 This specification defines a new SIP header field, Feature-Caps, to 119 convey feature capability indicators, which are used by SIP entities 120 not represented by the URI of the Contact header field to indicate 121 support of features and capabilities, where media feature tags cannot 122 be used to indicate the support. Such cases are: 124 o - The SIP entity acts as a SIP proxy. 125 o - The SIP entity acts as a SIP registrar. 126 o - The SIP entity acts as a B2BUA, where the Contact header field 127 URI represents another SIP entity. 129 NOTE: Unlike media feature tags, feature capability indicators are 130 intended to only be used with the SIP protocol. 132 This specification also defines feature capability indicators, and 133 creates a new IANA registry, "Proxy-Feature Feature Capability 134 Indicator Trees", for registering feature capability indicators. 136 2. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in BCP 14, RFC 2119 141 [RFC2119]. 143 3. Definitions 145 Downstream SIP entity: SIP entity in the direction towards which a 146 SIP request is sent. 148 Upstream SIP entity: SIP entity in the direction from which a SIP 149 request is received. 151 4. Feature-Caps Header Field 152 4.1. Introduction 154 The Feature-Caps header field is used by SIP entities to convey 155 support of features and capabilities, by setting feature capability 156 indicators. A feature capability indicator conveyed in a Feature- 157 Caps header field indicates that a SIP entity in the SIP message 158 signalling path supports the associated feature and capability. 160 For a given fc-value, as defined in section 5.3.1, feature capability 161 indicators are listed in a non-priority order, and any order of the 162 listed SIP feature capability indicators have the same meaning. For 163 example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the 164 SIP entity that inserted the feature capability indicator supports 165 the features and capabilities associated with the "foo" and "bar" 166 feature capability indicators. 168 4.2. User Agent and Proxy Behavior 170 4.2.1. General 172 If the URI in a Contact header field of a request or response 173 represents a SIP entity, the entity MUST NOT indicate supported 174 features and capabilities using a Feature-Caps header field within 175 that request or response. 177 When a SIP entity receives a SIP request, or response, that contains 178 one or more Feature-Caps header fields, the feature capability 179 indicators in the header field inform the entity about the features 180 and capabilities supported by entities in the SIP message signalling 181 path. Procedures how features and capabilities are invoked are 182 outside the scope of this specification, and MUST be described by 183 individual feature capability indicator specifications. 185 NOTE: It is not possible to, as a Feature-Caps header field value, 186 convey the address of the SIP entity that inserted the Feature-Caps 187 header field. If additional data about a supported feature needs to 188 be conveyed, such as the address of the SIP entity that indicated 189 support of the feature, then the feature definition needs to define a 190 way to convey that information as a value of the associated feature 191 capability indicator. 193 When a SIP entity adds a Feature-Caps header field to a SIP message, 194 it MUST place the header field before any existing Feature-Caps 195 header field in the message to be forwarded, so that the added header 196 field becomes the top-most one. Then, when another SIP entity 197 receives a SIP request or the response, the SIP feature capability 198 indicators in the top-most Feature-Caps header field will represent 199 the supported features and capabilities "closest" to the entity. 201 4.2.2. B2BUA Behavior 203 The procedures in this Section applies to UAs that are part of B2BUAs 204 that are referenced in the message by a Record-Route header field 205 rather than by the URI of the Contact header field. 207 When a UA sends a SIP request, if the UA wants to indicate support of 208 features and capabilities towards its downstream SIP entities, it 209 inserts a Feature-Caps header field to the request, containing one or 210 more feature capability indicators associated with the supported 211 features and capabilities, before it forwards the request. 213 If the SIP request is triggered by another SIP request that the B2BUA 214 has received, the UA MAY forward received Feature-Caps header fields 215 by copying them to the outgoing SIP request, similar to a SIP proxy, 216 before it inserts its own Feature-Caps header field to the SIP 217 request. 219 When a UA receives a SIP response, if the UA wants to indicate 220 support of features and capabilities towards its upstream SIP 221 entities, it inserts a Feature-Caps header field to the response, 222 containing one or more feature capability indicators associated with 223 the supported features and capabilities, before it forwards the 224 response. 226 If the SIP response is triggered by another SIP response that the 227 B2BUA has received, the UA MAY forward received Feature-Caps header 228 field by copying them to the outgoing SIP response, similar to a SIP 229 proxy, before it inserts its own Feature-Caps header field to the SIP 230 response. 232 4.2.3. Registrar Behavior 234 If a SIP registrar wants to indicate support of features and 235 capabilities towards its upstream SIP entities, it inserts a Feature- 236 Caps header field, containing one or more feature capability 237 indicators associated with the supported features and capabilities, 238 to a REGISTER response. 240 4.2.4. Proxy behavior 242 When a SIP proxy receives a SIP request, if the proxy wants to 243 indicate support of features and capabilities towards its downstream 244 SIP entities, it inserts a Feature-Caps header field to the request, 245 containing one or more SIP feature capability indicators associated 246 with the supported features and capabilities, before it forwards the 247 request. 249 When a proxy receives a SIP response, if the proxy wants to indicate 250 support of features and capabilities towards its upstream SIP 251 entities, it inserts a Feature-Caps header field to the response, 252 containing one or more SIP feature capability indicators associated 253 with the supported features and capabilities, before it forwards the 254 response. 256 4.3. SIP Message Type and Response Code Semantics 258 4.3.1. General 260 This Section describes the general usage and semantics of the 261 Feature-Caps header field for different SIP message types and 262 response codes. 264 NOTE: Future specifications can define usage and semantics of the 265 Feature-Caps header field for SIP methods, response codes and request 266 types not specified in this specification. 268 Section 6.2.1 defines the Feature-Caps header field ABNF. 270 4.3.2. SIP Dialog 272 The Feature-Caps header field can be used within an initial SIP 273 request for a dialog, within a target refresh SIP request, and within 274 any 18x or 2xx response associated with such requests. 276 If a feature capability indicator is inserted in a Feature-Caps 277 header field of an initial request for a dialog, or within a response 278 of such request, it indicates to the receivers of the request (or 279 response) that the feature associated with the feature capability 280 indicator is supported for the duration of the dialog, until a target 281 refresh request is sent for the dialog, or the dialog is terminated. 283 Unless a feature capability indicator is inserted in a Feature-Caps 284 header field or a target refresh request, or within a response of 285 such request, it indicates to the receivers of the request (or 286 response) that the feature is no long supported for the dialog. 288 For a given dialog a SIP entity MUST insert the same feature 289 capability indicators in all 18x and 2xx responses associated with a 290 given transaction. 292 4.3.3. SIP Registration (REGISTER) 294 The Feature-Caps header field can be used within a SIP REGISTER 295 request, and within the 200 (OK) response associated with such 296 request. 298 If a feature capability indicator is conveyed in a Feature-Caps 299 header field of a REGISTER request, or within an associated response, 300 it indicates to the receivers of the message that the feature 301 associated with the feature capability indicator is supported for the 302 registration, until the registration of the contact that was 303 explicitly conveyed in the REGISTER request expires, or until the 304 registered contact is explicitly refreshed and the refresh REGISTER 305 request does not contain the feature capability indicator associated 306 with the feature. 308 NOTE: While a REGISTER response can contain contacts that have been 309 registered as part of other registration transactions, support of any 310 indicated feature only applies to the contact(s) that were explicitly 311 conveyed in the associated REGISTER request. 313 This specification does not define any semantics for usage of the 314 Feature-Caps header field in pure registration binding fetching 315 messages (see Section 10.2.3 of RFC 3261), where the REGISTER request 316 does not contain a Contact header field. Unless such semantics is 317 defined in a future extension, fetching messages will not have any 318 impact on previously indicated support of features and capabilities, 319 and SIP entities MUST NOT insert a Feature-Caps header field to such 320 messages. 322 If SIP Outbound [RFC5626] is used, the rules above apply. However, 323 supported features and capabilities only apply for the registration 324 flow on which support has been explicitly indicated. 326 4.3.4. SIP Stand-Alone Transactions 328 The Feature-Caps header field can be used within a standalone SIP 329 request, and within any 18x or 2xx response associated with such 330 request. 332 If a feature capability indicator is inserted in a Feature-Caps 333 header field of a standalone request, or within a response of such 334 request, it indicates to the receivers of the request (or response) 335 that the feature associated with the feature capability indicator is 336 supported for the duration of the standalone transaction. 338 5. Feature Capability Indicators 340 5.1. Introduction 342 Feature capability indicators are used by SIP entities not 343 represented by the URI of the Contact header field to indicate 344 support of features and capabilities, where media feature tags cannot 345 be used to indicate the support. 347 A value, or a list of values, that provides additional information 348 about the supported feature or capability, can be associated with a 349 feature capability indicator. 351 Section 4 defines how feature capability indicators are conveyed 352 using the Feature-Caps header field. 354 Section 6.3.2 defines the feature capability indicator ABNF. 356 Section 8 provides a template for registering feature capability 357 indicators. 359 5.2. Registration Trees 361 5.2.1. General 363 The following subsections define registration trees, distinguished by 364 the use of faceted names (e.g., names of the form "tree.feature- 365 name"). The registration trees are defined in the IANA "Proxy- 366 Feature Feature Capability Indicator Trees" registry. 368 The trees defined herein are similar to the global tree and sip tree 369 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840 370 [RFC3840]. Other registration trees are outside the scope of this 371 specification. 373 NOTE: In contrast to RFC 2506 and RFC 3840, this specification only 374 defines a global tree and a sip tree, as they are the only trees 375 defined in those RFCs that have been used for defining SIP-specific 376 media feature tags. 378 When a feature capability indicator is registered in any registration 379 tree, no leading "+" is used in the registration. 381 5.2.2. Global Tree 383 The global feature capability indicator tree is similar to the media 384 feature tag global tree defined in RFC 2506 [RFC2506]. 386 A feature capability indicator for the global tree will be registered 387 by the IANA after review by a designated expert. That review will 388 serve to ensure that the feature capability indicator meets the 389 technical requirements of this specification. 391 A feature capability indicator in the global tree will be 392 distinguished by the leading facet "g.". An organization can propose 393 either a designation indicative of the feature, (e.g., "g.blinktags") 394 or a faceted designation including the organization name (e.g., 395 "g.organization.blinktags"). 397 When a feature capability indicator is registered in the global tree, 398 it needs to meet the "Expert Review" policies defined in RFC 5226 399 [RFC5226]. A designated area expert will review the proposed feature 400 capability indicator, and consult with members of related mailing 401 lists. This policy overrides the policy defined for registering new 402 header field parameters. 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 [RFC3840]. 409 A feature capability indicator in the sip tree will be distinguished 410 by the leading facet "sip.". 412 When a feature capability indicator is registered in the sip tree, it 413 needs to meet the "IETF Consensus" policies defined in RFC 5226 414 [RFC5226]. An RFC, which contains the registration of the feature 415 capability indicator, MUST be published. This policy overrides the 416 policy defined for registering new header field parameters. 418 5.3. Feature Capability Indicator Specification Requirements 420 5.3.1. General 422 A feature capability indicator specification MUST address the issues 423 defined in the following subsections, or document why an issue is not 424 applicable for the specific feature capability indicator. A 425 reference to the specification MUST be provided when the feature 426 capability indicator is registered with IANA (see Section 8). 428 It is bad practice for feature capability indicator specifications to 429 repeat procedures (e.g. general procedures on the usage of the 430 Feature-Caps header field and feature capability indicators) defined 431 in this specification, unless needed for clarification or emphasis 432 purpose. A feature capability indicator specification MUST NOT 433 modify the Feature-Caps header field rules and semantics defined in 434 Section 4. 436 A feature capability indicator specification MUST NOT weaken any 437 behavior designated with "SHOULD" or "MUST" in this specification. 438 However, a specification MAY strengthen "SHOULD", "MAY", or 439 "RECOMMENDED" requirements to "MUST" strength if features and 440 capabilities associated with the SIP feature capability indicator 441 require it. 443 5.3.2. Overall Description 445 The feature capability indicator specification MUST contain an 446 overall description of the feature capability indicator: how it is 447 used to indicate support of a feature, a description of the feature 448 associated with the SIP feature cap, a description of any additional 449 information (conveyed using one or more feature capability indicator 450 values) that can be conveyed together with the feature capability 451 indicator, and a description of how the associated feature may be 452 exercised/invoked. 454 5.3.3. Feature Capability Indicator Values 456 A feature capability indicator can have an associated value, or a 457 list of values. 459 The feature capability indicator specification MUST define the syntax 460 and semantics of any value defined for the feature capability 461 indicator, including possible restrictions related to the usage of a 462 specific value. The feature cap specification MUST define the 463 value(s) in accordance with the ABNF defined in Section 6.3.2. 465 A feature capability indicator value is only applicable for the 466 feature capability indicator for which it has been defined. For 467 other feature capability indicators, the value has to be defined 468 explicitly, even if the semantics are identical. 470 It is STRONGLY RECOMMENDED to not re-use a value that already has 471 been defined for another feature capability indicator, unless the 472 semantics of the values are the same. 474 5.3.4. Usage Restrictions 476 If there are restrictions on how SIP entities can insert a SIP 477 feature cap, the feature capability indicator specification MUST 478 document such restrictions. 480 There might be restrictions related to whether entities are allowed 481 to insert a feature capability indicator in registration related 482 messages, standalone transaction messages, or dialog related 483 messages, whether entities are allowed to insert a feature capability 484 indicator in requests or responses, whether entities also need to 485 support other features and capabilities in order to insert a feature 486 capability indicator, and whether entities are allowed to indicate 487 support of a feature in conjunction with another feature. 489 5.3.5. Examples 491 It is RECOMMENDED that the feature capability indicator specification 492 provide demonstrative message flow diagrams, paired with complete 493 messages and message descriptions. 495 Note that example message flows are by definition informative, and do 496 not replace normative text. 498 6. Syntax 500 6.1. General 502 This Section defines the ABNF for the Feature-Caps header field, and 503 for the feature capability indicators. 505 6.2. Syntax: Feature-Caps header field 507 6.2.1. ABNF 509 The ABNF for the Feature-Caps header fields is: 511 Feature-Caps = "Feature-Caps" HCOLON fc-value 512 *(COMMA fc-value) 513 fc-value = "*" *(SEMI feature-cap) 515 Figure 1: ABNF 517 NOTE: A "*" value means that no information regarding which SIP 518 entity, or domain, that indicate support of features and capabilities 519 is provided. 521 6.3. Syntax: feature capability indicator 523 6.3.1. General 525 In a feature capability indicator name (ABNF: fcap-name), dots can be 526 used to implement a SIP feature cap tree hierarchy (e.g. 527 tree.feature.subfeature). The description of usage of such tree 528 hierarchy must be described when registered. 530 6.3.2. ABNF 532 The ABNF for the feature capability indicator: 534 feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list 535 / fcap-string-value ) RDQUOT] 536 fcap-name = ftag-name 537 fcap-value-list = tag-value-list 538 fcap-string-value = string-value 539 ;; ftag-name, tag-value-list, string-value defined in RFC 3840 541 NOTE: In comparison with media feature tags, the "+" sign in front 542 of the feature capability indicator name is mandatory. 544 Figure 2: ABNF 546 7. IANA Considerations 548 7.1. Registration of the Feature-Caps header field 550 This specification registers a new SIP header field, Feature-Caps, 551 according to the process of RFC 3261 [RFC3261]. 553 The following is the registration for the Feature-Caps header field: 555 RFC Number: RFC XXX 557 Header Field Name: Feature-Caps 559 7.2. Registration of the Feature-Caps header field parameter 561 This specification adds the Feature-Caps header field to the IANA 562 "Header Field Parameters and Parameter Values" registry, according to 563 the process of RFC 3968 [RFC3968] 565 Header Field Parameter Name Predefined Values Reference 566 ---------------------------------------------------------------- 568 Feature-Caps * No [xxx] 570 * denotes parameter names conforming to the 571 syntax defined in [xxx]. Valid feature capability 572 indicators are registered in [reference to the new 573 Proxy-Feature Feature Capability Indicator Trees registry]. 575 Figure 3: SIP Parameter Header Field 577 (IANA: please sort the "Feature-Caps" line into the table and place 578 the remainder of the above as a footnote to the table.) 580 7.3. Proxy-Feature Feature Capability Indicator Trees 582 7.3.1. Introduction 584 This specification creates a new sub registry to the IANA "Session 585 Initiation Protocol (SIP) Parameters" Protocol Registry, according to 586 the process of RFC 5226 [RFC5226]. The name of the sub registry is 587 "Proxy-Feature Feature Capability Indicator Trees". 589 7.3.2. Global Feature Capability Indicator Registration Tree 591 This specification creates a new feature capability indicator tree in 592 the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. 593 The name of the tree is "Global Feature Capability Indicator 594 Registration Tree", and its leading facet is "g.". It is used for 595 the registration of feature capability indicators. 597 The addition of entries into this tree occurs through the Expert 598 Review policies, as defined in RFC 5226. A designated area expert 599 will review the proposed feature capability indicator, and consult 600 with members of related mailing lists. The information required in 601 the registration is defined in Section 5.3 of RFC XXX. 603 Note that all feature capability indicators registered in the global 604 tree will have names with a leading facet "g.". No leading "+" is 605 used in the registrations in any of the feature capability indicator 606 registration trees. 608 7.3.3. SIP Feature Capability Indicator Registration Tree 610 This specification creates a new feature capability indicator tree in 611 the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. 612 The name of the tree is "SIP Feature Capability Indicator 613 Registration Tree", and its leading facet is "sip.". It is used for 614 the registration of feature capability indicators. 616 The addition of entries into this tree occurs through the IETF 617 Consensus, as defined in RFC 5226. This requires the publication of 618 an RFC that contains the registration. The information required in 619 the registration is defined in Section 5.3 of RFC XXX. 621 Note that all feature capability indicators registered in the SIP 622 tree will have names with a leading facet "sip.". No leading "+" is 623 used in the registrations in any of the feature capability indicator 624 registration trees. 626 8. Feature Capability Indicator Registration Template 628 To: sip-feature-capability-indicators@apps.ietf.org 629 (feature capability indicators mailing list) 630 Subject: Registration of feature capability indicator XXXX 632 | Instructions are preceded by '|'. Some fields are optional. 634 Feature cap name: 636 Summary of feature indicated by this feature capability indicator: 638 | The summary should be no longer than 4 lines. More 639 | detailed information can be provided in the SIP feature 640 | cap specification. 642 Feature cap specification reference: 644 | The referenced specification MUST contain the information 645 | listed in Section 5.3 of XXXX (IANA: Replace XXXX with 646 | assigned RFC number of this specification. 648 Values appropriate for use with this feature capability indicator: 650 | If no values are defined for the feature capability indicator, 651 | indicate "N/A". Details about feature capability indicator values 652 | MUST be defined in the feature capability indicator specification. 654 The feature capability indicator is intended primarily for 655 use in the following applications, protocols, 656 services, or negotiation mechanisms: [optional] 658 | For applications, also specify the number of the 659 | first version which will use the feature capability indicator, 660 | if applicable. 662 Examples of typical use: [optional] 664 Considerations particular to use in individual 665 applications, protocols, services, or negotiation 666 mechanisms: [optional] 668 Interoperability considerations: [optional] 670 Security considerations: 672 Privacy concerns, related to exposure of personal 673 information: 675 Denial of service concerns related to consequences 676 of specifying incorrect values: 678 Other: 680 Additional information: [optional] 682 Keywords: [optional] 684 Related feature capability indicators: [optional] 686 Name(s) & email address(es) of person(s) to 687 contact for further information: 689 Intended usage: 691 | one of COMMON, LIMITED USE or OBSOLETE 693 Author/Change controller: 695 Other information: [optional] 697 | Any other information that the author deems 698 | interesting may be added here. 700 Figure 4: Registration Template 702 9. Security Considerations 704 The security issues for feature capability indicators are similar to 705 the ones defined in RFC 3840 for media feature tags. However, as 706 feature capability indicators will typically not be used to convey 707 capability information of end-user devices, those aspects of RFC 3840 708 do not apply to feature capability indicators. 710 In addition, the RFC 3840 security issue regarding an attacker using 711 the SIP caller preferences extension [RFC3841] in order to affect 712 routing decisions does not apply, as the mechanism is not defined to 713 be used with feature capability indicators. 715 Feature caps can provide capability and characteristics information 716 about the SIP entity, some of which might be sensitive. The Feature- 717 Caps header field does not convey address information about SIP 718 entities. However, individual feature capability indicators might 719 provide address information as feature capability indicator values. 720 Therefore, mechanisms for guaranteeing confidentiality and 721 authenticity SHOULD be provided. 723 10. Acknowledgements 725 The authors wish to thank everyone in the SIP community that provided 726 input and feedback on the work of this specification. 728 11. Change Log 730 [RFC EDITOR NOTE: Please remove this Section when publishing] 732 Changes from draft-holmberg-sipcore-proxy-feature-04 733 o WGLC comments from Keith Drage 734 o 'feature cap' name changed to 'feature capability indicator'. 735 o Feature-Caps header field added to IANA Header Field Parameters 736 and Parameter Values registry. 737 o Editorial modifications. 739 Changes from draft-ietf-sipcore-proxy-feature-03 740 o Additional Security Considerations text added. 741 o IANA Considerations modified. 742 o Editorial corrections. 744 Changes from draft-ietf-sipcore-proxy-feature-02 745 o Changes based on WGLC comments from Shida Schubert. 746 o - Document title changed 747 o - Terminology alignment 748 o - Note text clarifications 749 o Changes based on WGLC comments from Lili Yang. 751 Changes from draft-ietf-sipcore-proxy-feature-01 752 o Changes based on comments from Paul Kyzivat. 753 o IANA Considerations text added. 755 Changes from draft-holmberg-sipcore-proxy-feature-04/ 756 draft-ietf-sipcore-proxy-feature-00 757 o Media feature tags replaced with feature caps, based on SIPCORE 758 consensus at IETF#83 (Paris). 759 o Editorial corrections and modifications. 761 Changes from draft-holmberg-sipcore-proxy-feature-03 762 o Hadriel Kaplan added as co-author. 764 o Terminology change: instead of talking of proxies, talk about 765 entities which are not represented by the URI in a Contact header 766 field (http://www.ietf.org/mail-archive/web/sipcore/current/ 767 msg04449.html). 768 o Clarification regarding the usage of the header field in 18x/2xx 769 responses (http://www.ietf.org/mail-archive/web/sipcore/current/ 770 msg04449.html). 771 o Specifying that feature support can also be indicated in target 772 refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ 773 current/msg04454.html). 774 o Feature Cap specification registration information added. 776 Changes from draft-holmberg-sipcore-proxy-feature-02 777 o Definition, and usage of, a new header field, instead of Path, 778 Record-Route, Route and Service-Route. 780 Changes from draft-holmberg-sipcore-proxy-feature-01 781 o Requirement section added 782 o Use-cases and examples updated based on work in 3GPP 784 Changes from draft-holmberg-sipcore-proxy-feature-00 785 o Additional use-cases added 786 o Direction section added 788 12. References 790 12.1. Normative References 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, March 1997. 795 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 796 A., Peterson, J., Sparks, R., Handley, M., and E. 797 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 798 June 2002. 800 12.2. Informative References 802 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 803 Registration Procedure", BCP 31, RFC 2506, March 1999. 805 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 806 "Indicating User Agent Capabilities in the Session 807 Initiation Protocol (SIP)", RFC 3840, August 2004. 809 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 810 Preferences for the Session Initiation Protocol (SIP)", 811 RFC 3841, August 2004. 813 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 814 (IANA) Header Field Parameter Registry for the Session 815 Initiation Protocol (SIP)", BCP 98, RFC 3968, 816 December 2004. 818 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 819 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 820 May 2008. 822 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 823 Initiated Connections in the Session Initiation Protocol 824 (SIP)", RFC 5626, October 2009. 826 [3GPP.23.237] 827 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 828 Stage 2", 3GPP TS 23.237 10.9.0, March 2012. 830 [3GPP.24.837] 831 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 832 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 833 10.0.0, April 2011. 835 Authors' Addresses 837 Christer Holmberg 838 Ericsson 839 Hirsalantie 11 840 Jorvas 02420 841 Finland 843 Email: christer.holmberg@ericsson.com 845 Ivo Sedlacek 846 Ericsson 847 Scheelevaegen 19C 848 Lund 22363 849 Sweden 851 Email: ivo.sedlacek@ericsson.com 852 Hadriel Kaplan 853 Acme Packet 854 71 Third Ave. 855 Burlington, MA 01803 856 USA 858 Email: hkaplan@acmepacket.com