idnits 2.17.1 draft-ietf-sipcore-proxy-feature-03.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 (June 11, 2012) is 4337 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: December 13, 2012 H. Kaplan 6 Acme Packet 7 June 11, 2012 9 Mechanism to indicate support of features and capabilities in the 10 Session Initiation Protocol (SIP) 11 draft-ietf-sipcore-proxy-feature-03.txt 13 Abstract 15 This specification creates a new IANA registry, "Feature Cap 16 Registry", for registering "feature caps", which are used by SIP 17 entities not represented by the URI of the Contact header field to 18 indicate support of features and capabilities, where media feature 19 tags cannot be used to indicate the support. 21 This specification also defines a new SIP header field, Feature-Caps, 22 to convey feature caps in SIP messages. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 13, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Feature Caps . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 5 64 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 5 66 4.2.3. Feature Cap Registration Tree . . . . . . . . . . . . 6 67 4.3. Registration Template . . . . . . . . . . . . . . . . . . 6 68 4.4. Feature Cap Specification Requirements . . . . . . . . . . 8 69 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.4.2. Overall Description . . . . . . . . . . . . . . . . . 8 71 4.4.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 8 72 4.4.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 9 73 4.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 9 75 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 10 77 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 10 79 5.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 11 80 5.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 11 81 5.3. SIP Message Type and Response Code Semantics . . . . . . . 11 82 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 83 5.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 12 84 5.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 12 85 5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 13 86 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 6.2. Syntax: feature cap . . . . . . . . . . . . . . . . . . . 13 89 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 90 6.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 6.3. Syntax: Feature-Caps header field . . . . . . . . . . . . 14 92 6.3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 7.1. Registration of the Feature-Caps header field . . . . . . 14 95 7.2. Global Feature Cap Registration Tree . . . . . . . . . . . 15 96 7.3. Feature Cap Registration Tree . . . . . . . . . . . . . . 15 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 99 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 105 1. Introduction 107 The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" 108 extension, defined in RFC 3840 [RFC3840], provides a mechanism that 109 allows a SIP message to convey information relating to the 110 originator's features and capabilities, using the Contact header 111 field. 113 This specification creates a new IANA registry, "Feature Cap 114 Registry", for registering "feature caps", which are used by SIP 115 entities not represented by the URI of the Contact header field to 116 indicate support of features and capabilities, where media feature 117 tags cannot be used to indicate the support. Such cases are: 119 o - The SIP entity acts as a SIP proxy. 120 o - The SIP entity acts as a SIP registrar. 121 o - The SIP entity acts as a B2BUA, where the Contact header field 122 URI represents another SIP entity. 124 This specification also defines a new SIP header field, Feature-Caps, 125 to convey feature caps in SIP messages. 127 NOTE: Unlike media feature tags, feature caps are intended to only be 128 used with the SIP protocol. 130 2. Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in BCP 14, RFC 2119 135 [RFC2119]. 137 3. Definitions 139 Downstream SIP entity: SIP entity in the direction towards which a 140 SIP request is sent. 142 Upstream SIP entity: SIP entity in the direction from which a SIP 143 request is received. 145 4. Feature Caps 146 4.1. Introduction 148 Feature caps are used by SIP entities not represented by the URI of 149 the Contact header field to indicate support of features and 150 capabilities, where media feature tags cannot be used to indicate the 151 support. 153 A value, or a list of values, that provides additional information 154 about the supported feature or capability, can be associated with a 155 feature cap. 157 Section 5 defines how feature caps are conveyed using the Feature- 158 Caps header field. 160 The feature cap ABNF is defined in Section 6.2.2. 162 4.2. Registration Trees 164 4.2.1. General 166 The following subsections define registration "trees", distinguished 167 by the use of faceted names (e.g., names of the form "tree.feature- 168 name"). 170 The trees defined herein are similar to the global tree and sip tree 171 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840 172 [RFC3840]. Other registration trees are outside the scope of this 173 specification. 175 NOTE: In contrast to RFC 2506 and RFC 3840, this specification only 176 defines a global tree and a sip tree, as they are the only trees 177 defined in those RFCs that have been used for defining SIP-specific 178 media feature tags. 180 When a feature cap is registered in any registration tree, no leading 181 "+" is used in the registration. 183 4.2.2. Global Tree 185 The feature cap global tree is similar to the media feature tag 186 global tree defined in RFC 2506 [RFC2506]. 188 A feature cap for the global tree will be registered by the IANA 189 after review by a designated expert. That review will serve to 190 ensure that the feature cap meets the technical requirements of this 191 specification. 193 A feature cap in the global tree will be distinguished by the leading 194 facet "g.". An organization can propose either a designation 195 indicative of the feature, (e.g., "g.blinktags") or a faceted 196 designation including the organization name (e.g., 197 "g.organization.blinktags"). 199 When a feature cap is registered in the global tree, it needs to meet 200 the "Expert Review" policies defined in RFC 5226 [RFC5226]. A 201 designated area expert will review the proposed feature cap, and 202 consult with members of related mailing lists. 204 4.2.3. Feature Cap Registration Tree 206 The feature cap sip tree is similar to the media feature tag sip tree 207 defined in RFC 3840 [RFC3840]. 209 A feature cap in the sip tree will be distinguished by the leading 210 facet "sip.". 212 When a feature cap is registered in the sip tree, it needs to meet 213 the "IETF Consensus" policies defined in RFC 5226 [RFC5226]. An RFC, 214 which contains the registration of the feature cap, MUST be 215 published. 217 4.3. Registration Template 219 To: sip-feature-caps@apps.ietf.org (feature caps mailing list) 220 Subject: Registration of feature cap XXXX 222 | Instructions are preceded by '|'. Some fields are optional. 224 Feature cap name: 226 Summary of feature indicated by this feature cap: 228 | The summary should be no longer than 4 lines. More 229 | detailed information can be provided in the SIP feature 230 | cap specification. 232 Feature cap specification reference: 234 | The referenced specification MUST contain the information 235 | listed in section XX of XXXX (IANA: Replace XXXX with 236 | assigned RFC number of this specification. 238 Values appropriate for use with this feature cap: 240 | If no values are defined for the feature cap, 241 | indicate "N/A". Details about feature cap values 242 | MUST be defined in the feature cap specification. 244 The feature cap is intended primarily for 245 use in the following applications, protocols, 246 services, or negotiation mechanisms: [optional] 248 | For applications, also specify the number of the 249 | first version which will use the feature cap, 250 | if applicable. 252 Examples of typical use: [optional] 254 Considerations particular to use in individual 255 applications, protocols, services, or negotiation 256 mechanisms: [optional] 258 Interoperability considerations: [optional] 260 Security considerations: 262 Privacy concerns, related to exposure of personal 263 information: 265 Denial of service concerns related to consequences 266 of specifying incorrect values: 268 Other: 270 Additional information: [optional] 272 Keywords: [optional] 274 Related feature caps: [optional] 276 Name(s) & email address(es) of person(s) to 277 contact for further information: 279 Intended usage: 281 | one of COMMON, LIMITED USE or OBSOLETE 283 Author/Change controller: 285 Other information: [optional] 287 | Any other information that the author deems 288 | interesting may be added here. 290 Figure 1: Registration Template 292 4.4. Feature Cap Specification Requirements 294 4.4.1. General 296 A feature cap specification MUST address the issues defined in the 297 following subsections, or document why an issue is not applicable for 298 the specific feature cap. A reference to the specification MUST be 299 provided when the feature cap is registered with IANA (see 300 Section 4.3). 302 It is bad practice for feature cap specifications to repeat 303 procedures (e.g. general procedures on the usage of the Feature-Caps 304 header field and feature caps) defined in this specification, unless 305 needed for clarification or emphasis purpose. 307 A feature cap specification MUST NOT weaken any behavior designated 308 with "SHOULD" or "MUST" in this specification. However, a 309 specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" 310 requirements to "MUST" strength if features and capabilities 311 associated with the SIP feature cap require it. 313 4.4.2. Overall Description 315 The feature cap specification MUST contain an overall description of 316 the feature cap: how it is used to indicate support of a feature, a 317 description of the feature associated with the SIP feature cap, a 318 description of any additional information (conveyed using one or more 319 feature cap values) that can be conveyed together with the feature 320 cap, and a description of how the associated feature may be 321 exercised/invoked. 323 4.4.3. Feature Cap Values 325 A feature cap can have an associated value, or a list of values. 327 The feature cap specification MUST define the syntax and semantics of 328 any value defined for the feature cap, including possible 329 restrictions related to the usage of a specific value. The feature 330 cap specification MUST define the value(s) in accordance with the 331 syntax defined in section 6.2.2. 333 A feature cap value is only applicable for the feature cap for which 334 it has been defined. For other feature caps, the value has to be 335 defined explicitly, even if the semantics are identical. 337 It is STRONGLY RECOMMENDED to not re-use a value that already has 338 been defined for another feature cap, unless the semantics of the 339 values are the same. 341 4.4.4. Usage Restrictions 343 If there are restrictions on how SIP entities can insert a SIP 344 feature cap, the feature cap specification MUST document such 345 restrictions. 347 There might be restrictions related to whether entities are allowed 348 to insert a feature cap in registration related messages, standalone 349 transaction messages, or dialog related messages, whether entities 350 are allowed to insert a feature cap in requests or responses, whether 351 entities also need to support other features and capabilities in 352 order to insert a feature cap, and whether entities are allowed to 353 indicate support of a feature in conjunction with another feature. 355 4.4.5. Examples 357 It is RECOMMENDED that the feature cap specification provide 358 demonstrative message flow diagrams, paired with complete messages 359 and message descriptions. 361 Note that example message flows are by definition informative, and do 362 not replace normative text. 364 5. Feature-Caps Header Field 366 5.1. Introduction 368 The Feature-Caps header field is used by SIP entities to convey 369 support of features and capabilities, by setting feature caps. 370 Feature caps conveyed in a Feature-Caps header field indicate that 371 the SIP entity that inserted the header field supports the associated 372 features and capabilities. 374 NOTE: It is not possible to, as a Feature-Caps header field value, 375 convey the address of the SIP entity that inserted the Feature-Caps 376 header field. If additional data about a supported feature needs to 377 be conveyed, such as the address of the SIP entity that indicated 378 support of the feature, then the feature definition needs to define a 379 way to convey that information as a value of the associated feature 380 cap. 382 The feature cap specification MUST specify for which SIP methods and 383 message types, and the associated semantics, the feature cap is 384 applicable. See Section 4 for more information. No semantics is 385 defined for feature caps present in SIP methods and message types not 386 covered by the associated feature cap specification. 388 Within a given Feature-Caps header field, feature caps are listed in 389 a non-priority order, and for a given header field any order of 390 listed SIP feature caps have the same meaning. For example, 391 "foo;bar" and "bar;foo" have the same meaning (i.e. that the SIP 392 entity that inserted the feature caps supports the features and 393 capabilities associated with the "foo" and "bar" feature caps. 395 5.2. User Agent and Proxy Behavior 397 5.2.1. General 399 If the URI in a Contact header field of a request or response 400 represents a SIP entity, the entity MUST NOT indicate supported 401 features and capabilities using a Feature-Caps header field within 402 that request or response. 404 When a SIP entity receives a SIP request, or response, that contains 405 one or more Feature-Caps header fields, the feature caps in the 406 header field inform the entity about the features and capabilities 407 supported by the entities that inserted the header fields. 408 Procedures how features and capabilities are invoked are outside the 409 scope of this specification, and MUST be described by individual 410 feature cap specifications. 412 When a SIP entity adds a Feature-Caps header field to a SIP message, 413 it MUST place the header field before any existing Feature-Caps 414 header field in the message to be forwarded, so that the added header 415 field becomes the top-most one. Then, when another SIP entity 416 receives a SIP request or the response, the SIP feature caps in the 417 top-most Feature-Caps header field will represent the supported 418 features and capabilities "closest" to the entity. 420 5.2.2. B2BUA Behavior 422 The procedures in this Section applies to UAs that are part of B2BUAs 423 that are referenced in the message by a Record-Route header field 424 rather than by the URI of the Contact header field. 426 When a UA sends a SIP request, if the UA wants to indicate support of 427 features and capabilities towards its downstream SIP entities, it 428 inserts a Feature-Caps header field to the request, containing one or 429 more feature caps associated with the supported features and 430 capabilities, before it forwards the request. 432 If the SIP request is triggered by another SIP request that the B2BUA 433 has received, the UA MAY forward received Feature-Caps header fields 434 by copying them to the outgoing SIP request, similar to a SIP proxy, 435 before it inserts its own Feature-Caps header field to the SIP 436 request. 438 When a UA receives a SIP response, if the UA wants to indicate 439 support of features and capabilities towards its upstream SIP 440 entities, it inserts a Feature-Caps header field to the response, 441 containing one or more feature caps associated with the supported 442 features and capabilities, before it forwards the response. 444 If the SIP response is triggered by another SIP response that the 445 B2BUA has received, the UA MAY forward received Feature-Caps header 446 field by copying them to the outgoing SIP response, similar to a SIP 447 proxy, before it inserts its own Feature-Caps header field to the SIP 448 response. 450 5.2.3. Registrar Behavior 452 If a SIP registrar wants to indicate support of features and 453 capabilities towards its upstream SIP entities, it inserts a Feature- 454 Caps header field, containing one or more feature caps associated 455 with the supported features and capabilities, to a REGISTER response. 457 5.2.4. Proxy behavior 459 When a SIP proxy receives a SIP request, if the proxy wants to 460 indicate support of features and capabilities towards its downstream 461 SIP entities, it inserts a Feature-Caps header field to the request, 462 containing one or more SIP feature caps associated with the supported 463 features and capabilities, before it forwards the request. 465 When a proxy receives a SIP response, if the proxy wants to indicate 466 support of features and capabilities towards its upstream SIP 467 entities, it inserts a Feature-Caps header field to the response, 468 containing one or more SIP feature caps associated with the supported 469 features and capabilities, before it forwards the response. 471 5.3. SIP Message Type and Response Code Semantics 473 5.3.1. General 475 This Section describes the general usage and semantics of the 476 Feature-Caps header field for different SIP message types and 477 response codes. The usage and semantics of a specific feature cap 478 MUST be described in the associated feature cap specification. 480 NOTE: Future specifications can define usage and semantics of the 481 Feature-Caps header field for SIP methods, response codes and request 482 types not specified in this specification. 484 The Feature-Caps header field ABNF is defined in Section 6.3.1. 486 5.3.2. SIP Dialog 488 The Feature-Caps header field can be used within an initial SIP 489 request for a dialog, within a target refresh SIP request, and within 490 any 18x or 2xx response associated with such requests. 492 If a feature cap is inserted in a Feature-Caps header field of an 493 initial request for a dialog, or within a response of such request, 494 it indicates to the receivers of the request (or response) that the 495 feature associated with the feature cap is supported for the duration 496 of the dialog, until a target refresh request is sent for the dialog, 497 or the dialog is terminated. 499 Unless a feature cap is inserted in a Feature-Caps header field or a 500 target refresh request, or within a response of such request, it 501 indicates to the receivers of the request (or response) that the 502 feature is no long supported for the dialog. 504 For a given dialog a SIP entity MUST insert the same feature caps in 505 all 18x and 2xx responses associated with a given transaction. 507 5.3.3. SIP Registration (REGISTER) 509 The Feature-Caps header field can be used within a SIP REGISTER 510 request, and within the 200 (OK) response associated with such 511 request. 513 If a feature cap is conveyed in a Feature-Caps header field of a 514 REGISTER request, or within an associated response, it indicates to 515 the receivers of the message that the feature associated with the 516 feature cap is supported for the registration, until the registration 517 of the contact that was explicitly conveyed in the REGISTER request 518 expires, or until the registered contact is explicitly refreshed and 519 the refresh REGISTER request does not contain the feature cap 520 associated with the feature. 522 NOTE: While a REGISTER response can contain contacts that have been 523 registered as part of other registration transactions, support of any 524 indicated feature only applies to the contact(s) that were explicitly 525 conveyed in the associated REGISTER request. 527 This specification does not define any semantics for usage of the 528 Feature-Caps header field in pure registration binding fetching 529 messages (see Section 10.2.3 of RFC 3261), where the REGISTER request 530 does not contain a Contact header field. Unless such semantics is 531 defined in a future extension, fetching messages will not have any 532 impact on previously indicated support of features and capabilities, 533 and SIP entities MUST NOT insert a Feature-Caps header field to such 534 messages. 536 If SIP Outbound [RFC5626] is used, the rules above apply. However, 537 supported features and capabilities only apply for the registration 538 flow on which support has been explicitly indicated. 540 5.3.4. SIP Stand-Alone Transactions 542 The Feature-Caps header field can be used within a standalone SIP 543 request, and within any 18x or 2xx response associated with such 544 request. 546 If a feature cap is inserted in a Feature-Caps header field of a 547 standalone request, or within a response of such request, it 548 indicates to the receivers of the request (or response) that the 549 feature associated with the feature cap is supported for the duration 550 of the standalone transaction. 552 6. Syntax 554 6.1. General 556 This Section defines the ABNF for Feature-Caps, and for the Feature- 557 Cap header field. 559 6.2. Syntax: feature cap 561 6.2.1. General 563 In a feature cap name (ABNF: fcap-name), dots can be used to 564 implement a SIP feature cap tree hierarchy (e.g. 565 tree.feature.subfeature). The description of usage of such tree 566 hierarchy must be described when registered. 568 6.2.2. ABNF 570 The ABNF for the feature cap: 572 feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list 573 / fcap-string-value ) RDQUOT] 574 fcap-name = ftag-name 575 fcap-value-list = tag-value-list 576 fcap-string-value = string-value 577 ;; ftag-name, tag-value-list, string-value defined in RFC 3840 579 NOTE: In comparison with media feature tags, the "+" sign in front 580 of the feature cap name is mandatory. 582 Figure 2: ABNF 584 6.3. Syntax: Feature-Caps header field 586 6.3.1. ABNF 588 The ABNF for the Feature-Caps header fields is: 590 Feature-Caps = "Feature-Caps" HCOLON fc-value 591 *(COMMA fc-value) 592 fc-value = "*" *(SEMI feature-cap) 594 Figure 3: ABNF 596 NOTE: A "*" value means that no information regarding which SIP 597 entity, or domain, that indicate support of features and capabilities 598 is provided. 600 7. IANA Considerations 602 7.1. Registration of the Feature-Caps header field 604 This specification registers a new SIP header field, Feature-Caps, 605 according to the process of RFC 3261 [RFC3261]. 607 The following is the registration for the Feature-Caps header field: 609 RFC Number: RFC XXX 611 Header Field Name: Feature-Caps 613 7.2. Global Feature Cap Registration Tree 615 This specification creates a new feature cap tree. The name of the 616 tree is "Global Feature Cap Registration Tree", and its leading facet 617 is "g.". It is used for the registration of feature caps. 619 The addition of entries into this registry occurs through the Expert 620 Review policies, as defined in RFC 5226 [RFC5226]. A designated area 621 expert will review the proposed SIP feature cap, and consult with 622 members of related mailing lists. The information required in the 623 registration is defined in Section 4.3 of RFC XXX. 625 Note that all feature caps registered in the SIP tree will have names 626 with a leading facet "g.". No leading "+" is used in the 627 registrations in any of the media feature tag trees. 629 7.3. Feature Cap Registration Tree 631 This specification creates a new feature cap tree, per the guidelines 632 in RFC 5226 [RFC5226]. The name of the tree is "Feature Cap 633 Registration Tree", and its leading facet is "sip.". It is used for 634 the registration of feature caps. 636 The addition of entries into this registry occurs through the IETF 637 Consensus, as defined in RFC 5226. This requires the publication of 638 an RFC that contains the registration. The information required in 639 the registration is defined in Section 4.3 of RFC XXX. 641 Note that all feature caps registered in the SIP tree will have names 642 with a leading facet "sip.". No leading "+" is used in the 643 registrations in any of the media feature tag trees. 645 8. Security Considerations 647 Feature caps can provide sensitive information about a SIP entity. 648 RFC 3840 cautions against providing sensitive information to another 649 party. Once this information is given out, any use may be made of 650 it. 652 9. Acknowledgements 654 10. Change Log 656 [RFC EDITOR NOTE: Please remove this Section when publishing] 657 Changes from draft-ietf-sipcore-proxy-feature-02 658 o Changes based on WGLC comments from Shida Schubert. 659 o - Document title changed 660 o - Terminology alignment 661 o - Note text clarifications 662 o Changes based on WGLC comments from Lili Yang. 664 Changes from draft-ietf-sipcore-proxy-feature-01 665 o Changes based on comments from Paul Kyzivat. 666 o IANA Considerations text added. 668 Changes from draft-holmberg-sipcore-proxy-feature-04/ 669 draft-ietf-sipcore-proxy-feature-00 670 o Media feature tags replaced with feature caps, based on SIPCORE 671 consensus at IETF#83 (Paris). 672 o Editorial corrections and modifications. 674 Changes from draft-holmberg-sipcore-proxy-feature-03 675 o Hadriel Kaplan added as co-author. 676 o Terminology change: instead of talking of proxies, talk about 677 entities which are not represented by the URI in a Contact header 678 field (http://www.ietf.org/mail-archive/web/sipcore/current/ 679 msg04449.html). 680 o Clarification regarding the usage of the header field in 18x/2xx 681 responses (http://www.ietf.org/mail-archive/web/sipcore/current/ 682 msg04449.html). 683 o Specifying that feature support can also be indicated in target 684 refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ 685 current/msg04454.html). 686 o Feature Cap specification registration information added. 688 Changes from draft-holmberg-sipcore-proxy-feature-02 689 o Definition, and usage of, a new header field, instead of Path, 690 Record-Route, Route and Service-Route. 692 Changes from draft-holmberg-sipcore-proxy-feature-01 693 o Requirement section added 694 o Use-cases and examples updated based on work in 3GPP 696 Changes from draft-holmberg-sipcore-proxy-feature-00 697 o Additional use-cases added 698 o Direction section added 700 11. References 701 11.1. Normative References 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, March 1997. 706 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 707 A., Peterson, J., Sparks, R., Handley, M., and E. 708 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 709 June 2002. 711 11.2. Informative References 713 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 714 Registration Procedure", BCP 31, RFC 2506, March 1999. 716 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 717 "Indicating User Agent Capabilities in the Session 718 Initiation Protocol (SIP)", RFC 3840, August 2004. 720 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 721 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 722 May 2008. 724 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 725 Initiated Connections in the Session Initiation Protocol 726 (SIP)", RFC 5626, October 2009. 728 [3GPP.23.237] 729 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 730 Stage 2", 3GPP TS 23.237 10.9.0, March 2012. 732 [3GPP.24.837] 733 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 734 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 735 10.0.0, April 2011. 737 Authors' Addresses 739 Christer Holmberg 740 Ericsson 741 Hirsalantie 11 742 Jorvas 02420 743 Finland 745 Email: christer.holmberg@ericsson.com 746 Ivo Sedlacek 747 Ericsson 748 Scheelevaegen 19C 749 Lund 22363 750 Sweden 752 Email: ivo.sedlacek@ericsson.com 754 Hadriel Kaplan 755 Acme Packet 756 71 Third Ave. 757 Burlington, MA 01803 758 USA 760 Email: hkaplan@acmepacket.com