idnits 2.17.1 draft-ietf-sipcore-proxy-feature-02.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 (May 9, 2012) is 4369 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: November 10, 2012 H. Kaplan 6 Acme Packet 7 May 9, 2012 9 Indication of features supported by proxy 10 draft-ietf-sipcore-proxy-feature-02.txt 12 Abstract 14 This specification creates a new IANA registry, "SIP Feature Cap 15 Registry", which is used to register indicators, "SIP feature caps", 16 used by SIP entities to indicate support of features and 17 capabilities, in cases where the Contact header field contains a URI 18 that does not represent the SIP entity that wants to indicate support 19 of its features and capabilities. 21 This specification also defines a new SIP header field, Feature-Caps, 22 that can be used by SIP entities to convey information about 23 supported features and capabilities, using SIP feature caps. 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 November 10, 2012. 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. SIP Feature Caps . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 5 65 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 5 67 4.2.3. SIP Feature Cap Registration Tree . . . . . . . . . . 6 68 4.3. Registration Template . . . . . . . . . . . . . . . . . . 6 69 4.4. SIP Feature Cap Specification Requirements . . . . . . . . 8 70 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.4.2. Overall Description . . . . . . . . . . . . . . . . . 8 72 4.4.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 8 73 4.4.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 9 74 4.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 9 75 5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 9 76 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 10 78 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 10 80 5.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 11 81 5.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 11 82 5.3. SIP Message Type and Response Code Semantics . . . . . . . 11 83 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 12 85 5.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 12 86 5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 13 87 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 6.2. Syntax: SIP feature cap . . . . . . . . . . . . . . . . . 13 90 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 91 6.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 6.3. Syntax: Feature-Caps header field . . . . . . . . . . . . 14 93 6.3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 7.1. Registration of the Feature-Caps header field . . . . . . 14 96 7.2. Global Feature Cap Registration Tree . . . . . . . . . . . 14 97 7.3. SIP Feature Cap Registration Tree . . . . . . . . . . . . 15 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 99 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 100 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 106 1. Introduction 108 The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" 109 extension, defined in RFC 3840 [RFC3840], provides a mechanism that 110 allows a SIP message to convey information relating to the 111 originator's features and capabilities, using the Contact header 112 field. 114 This specification creates a new IANA registry, "SIP Feature Cap 115 Registry", which is used to register indicators, "SIP feature caps", 116 that can be used by SIP entities to indicate support of features and 117 capabilities, in cases where the Contact header field contains a URI 118 that does not represent the SIP entity that wants to indicate support 119 of its features and capabilities, and media feature tags cannot be 120 used to indicate the support. Such cases are: 122 o - The SIP entity acts as a SIP proxy. 123 o - The SIP entity acts as a SIP registrar. 124 o - The SIP entity acts as a B2BUA, where the Contact header field 125 URI represents another SIP entity. 127 This specification also defines a new SIP header field, Feature-Caps, 128 that can be used by SIP entities to convey information about 129 supported features and capabilities, using SIP feature caps. 131 Unlike media feature tags, SIP feature caps are intended to only be 132 used with the SIP protocol. 134 2. Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in BCP 14, RFC 2119 139 [RFC2119]. 141 3. Definitions 143 Downstream SIP entity: SIP entity in the direction towards which a 144 SIP request is sent. 146 Upstream SIP entity: SIP entity in the direction from which a SIP 147 request is received. 149 4. SIP Feature Caps 151 4.1. Introduction 153 A SIP feature cap can be used by SIP entities to indicate support of 154 features and capabilities, in cases where media feature tags cannot 155 be used, ie if the Contact header field contains a URI that does not 156 represent the SIP entity that wants to indicate support of its 157 features and capabilities. 159 A value, or a list of values, can be associated with a SIP feature 160 cap. 162 Section 5 defines how SIP feature caps are conveyed using the SIP 163 Feature-Caps header field. 165 The SIP feature cap ABNF is defined in Section 6.2.2. 167 4.2. Registration Trees 169 4.2.1. General 171 The following subsections define registration "trees", distinguished 172 by the use of faceted names (e.g., names of the form "tree.feature- 173 name"). 175 The trees defined herein are similar to the global tree and sip tree 176 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841 177 [RFC3841]. Other registration trees are outside the scope of this 178 specification. 180 NOTE: Compared to RFC 2506, this specification only defines a global 181 tree and a sip tree, as they are the only tree defined in RFC 2506 182 that have been used for defining media feature tags for SIP. 184 When a SIP feature cap is registered in any registration tree, no 185 leading "+" is used in the registration. 187 4.2.2. Global Tree 189 The SIP feature cap global tree is similar to the media feature tag 190 global tree defined in RFC 2506 [RFC2506]. 192 A SIP feature cap for the global tree will be registered by the IANA 193 after review by a designated expert. That review will serve to 194 ensure that the SIP feature cap meets the technical requirements of 195 this specification. 197 A SIP feature cap in the global tree will be distinguished by the 198 leading facet "g.". An organization can propose either a designation 199 indicative of the feature, (e.g., "g.blinktags") or a faceted 200 designation including the organization name (e.g., 201 "g.organization.blinktags"). 203 When a SIP feature cap is registered in the global tree, it needs to 204 meet the "Expert Review" policies defined in RFC 5226 [RFC5226]. A 205 designated area expert will review the proposed SIP feature cap, and 206 consult with members of related mailing lists. 208 4.2.3. SIP Feature Cap Registration Tree 210 The SIP feature cap sip tree is similar to the media feature tag sip 211 tree defined in RFC 3840 [RFC3840]. 213 A SIP feature cap in the sip tree will be distinguished by the 214 leading facet "sip.". 216 When a SIP feature cap is registered in the sip tree, it needs to 217 meet the "IETF Consensus" policies defined in RFC 5226 [RFC5226]. An 218 RFC, which contains the registration of the SIP feature cap, must be 219 published. 221 4.3. Registration Template 223 To: sip-feature-caps@apps.ietf.org (SIP feature caps mailing list) 224 Subject: Registration of SIP feature cap XXXX 226 | Instructions are preceded by `|'. Some fields are optional. 228 SIP feature cap name: 230 Summary of feature indicated by this SIP feature cap: 232 | The summary should be no longer than 4 lines. More 233 | detailed information can be provided in the SIP feature 234 | cap specification. 236 SIP feature cap specification reference: 238 | The referenced specification MUST contain the information 239 | listed in section XX of XXXX (IANA: Replace XXXX with 240 | assigned RFC number of this specification. 242 Values appropriate for use with this SIP feature cap: 244 | If no values are defined for the SIP feature cap, 245 | indicate "N/A". Details about SIP feature cap values 246 | MUST be defined in the SIP feature cap specification. 248 The SIP feature cap is intended primarily for 249 use in the following applications, protocols, 250 services, or negotiation mechanisms: [optional] 252 | For applications, also specify the number of the 253 | first version which will use the SIP feature cap, 254 | if applicable. 256 Examples of typical use: [optional] 258 Considerations particular to use in individual 259 applications, protocols, services, or negotiation 260 mechanisms: [optional] 262 Interoperability considerations: [optional] 264 Security considerations: 266 Privacy concerns, related to exposure of personal 267 information: 269 Denial of service concerns related to consequences 270 of specifying incorrect values: 272 Other: 274 Additional information: [optional] 276 Keywords: [optional] 278 Related SIP feature caps: [optional] 280 Name(s) & email address(es) of person(s) to 281 contact for further information: 283 Intended usage: 285 | one of COMMON, LIMITED USE or OBSOLETE 287 Author/Change controller: 289 Other information: [optional] 291 | Any other information that the author deems 292 | interesting may be added here. 294 Figure 1: Registration Template 296 4.4. SIP Feature Cap Specification Requirements 298 4.4.1. General 300 A SIP feature cap specification MUST address the issues defined in 301 the following subsections, or document why an issue is not applicable 302 for the specific SIP feature cap. A reference to the specification 303 MUST be provided when the SIP feature cap is registered with IANA 304 (see Section 4.3). 306 It is bad practice for SIP feature cap specifications to repeat 307 procedures defined in this specification, unless needed for 308 clarification or emphasis purpose. 310 A SIP feature cap specification MUST NOT weaken any behavior 311 designated with "SHOULD" or "MUST" in this specification. However, a 312 specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" 313 requirements to "MUST" strength if features associated with the SIP 314 feature cap require it. 316 4.4.2. Overall Description 318 The SIP feature cap specification MUST contain an overall description 319 of the SIP feature cap: how it is used to indicate support of a 320 feature, a description of the feature associated with the SIP feature 321 cap, a description of any additional information (conveyed using one 322 or more SIP feature cap values) that can be conveyed together with 323 the SIP feature cap, and a description of how the associated feature 324 may be exercised/invoked. 326 4.4.3. Feature Cap Values 328 A SIP feature cap can have an associated value, or a list of values. 329 A SIP feature cap value MUST conform to the ABNF defined in Section 330 6.2.2. 332 The SIP feature cap specification MUST define the syntax and 333 semantics of any value defined for the SIP feature cap, including 334 possible restrictions related to the usage of a specific value. 336 A SIP feature cap value is only applicable for the SIP feature cap 337 for which it has been defined. For other SIP feature caps, the value 338 has to be defined explicitly, even if the name or the semantics are 339 identical. 341 It is STRONLY RECOMMENDED to not re-use a value name that already has 342 been defined for another SIP feature cap, unless the semantics of the 343 values are the same. 345 4.4.4. Usage Restrictions 347 If there are restrictions on how SIP entities can insert a SIP 348 feature cap, the SIP feature cap specification MUST document such 349 restrictions. 351 There might be restrictions related to whether entities are allowed 352 to insert a SIP feature cap in registration related messages, 353 standalone transaction messages, or dialog related messages, whether 354 entities are allowed to insert a SIP feature cap in requests or 355 responses, whether entities also need to support other features in 356 order to insert a SIP feature cap, and whether entities are allowed 357 to indicate support of a feature in conjunction with another feature. 359 4.4.5. Examples 361 It is RECOMMENDED that the SIP feature cap specification provide 362 demonstrative message flow diagrams, paired with complete messages 363 and message descriptions. 365 Note that example flows are by definition informative, and do not 366 replace normative text. 368 5. Feature-Caps Header Field 370 5.1. Introduction 372 The Feature-Caps header field is used by SIP entities to convey 373 support of features and capabilities, using SIP feature caps. SIP 374 feature caps conveyed in a Feature-Caps header field indicate that 375 the SIP entity that inserted the header field supports the associated 376 features. 378 NOTE: It is not possible to convey the address of the SIP entity as a 379 Feature-Caps header field parameter. Each feature that requires 380 address information to be conveyed need to define a way to convey 381 that information as part of the associated SIP feature cap value. 383 The SIP feature cap specification MUST specify for which SIP methods 384 and message types, and the associated semantics, the SIP feature cap 385 is applicable. See Section 4 for more information. No semantics is 386 defined for SIP feature caps present in SIP methods and message types 387 not covered by the associated SIP feature cap specification. 389 Within a given Feature-Caps header field, SIP feature caps are listed 390 in a non-priority order, and for a given header field any order of 391 listed SIP feature caps have the same meaning. For example, 392 "foo;bar" and "bar;foo" have the same meaning(i.e. that the SIP 393 entity that inserted the feature caps supports the features 394 associated with the "foo" and "bar" SIP feature caps. 396 5.2. User Agent and Proxy Behavior 398 5.2.1. General 400 If the URI in a Contact header field of a request or response 401 represents a SIP entity, the entity MUST NOT indicate supported 402 features and capabilities using a Feature-Caps header field within 403 that request or response. 405 When a SIP entity receives a SIP request, or response, that contains 406 one or more Feature-Caps header fields, the SIP feature caps in the 407 header field inform the entity about the features supported by the 408 entities that inserted the header fields. Procedures how features 409 are invoked are outside the scope of this specification, and MUST be 410 described by individual SIP 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 "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 towards its downstream SIP entities, it inserts a Feature- 428 Caps header field to the request, containing one or more SIP feature 429 caps associated with the supported features, before it forwards the 430 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 towards its upstream SIP entities, it inserts a 440 Feature-Caps header field to the response, containing one or more SIP 441 feature caps associated with the supported features, before it 442 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 towards its 453 upstream SIP entities, it inserts a Feature-Caps header field, 454 containing one or more SIP feature caps associated with the supported 455 features, 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 towards its downstream SIP entities, it 461 inserts a Feature-Caps header field to the request, containing one or 462 more SIP feature caps associated with the supported features, before 463 it forwards the request. 465 When a proxy receives a SIP response, if the proxy wants to indicate 466 support of features towards its upstream SIP entities, it inserts a 467 Feature-Caps header field to the response, containing one or more SIP 468 feature caps associated with the supported features, before it 469 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 SIP feature 478 cap MUST be described in the associated SIP feature cap 479 specification. 481 NOTE: Future specifications can define usage and semantics of the 482 Feature-Caps header field for SIP methods, response codes and request 483 types not specified in this specification. 485 The Feature-Caps header field ABNF is defined in Section 6.3.1. 487 5.3.2. SIP Dialog 489 The Feature-Caps header field can be used within an initial SIP 490 request for a dialog, within a target refresh SIP request, and within 491 any 18x or 2xx response associated with such requests. 493 If a SIP feature cap is inserted in a Feature-Caps header field of an 494 initial request for a dialog, or within a response of such request, 495 it indicates to the receivers of the request (or response) that the 496 feature associated with the SIP feature cap is supported for the 497 duration of the dialog, until a target refresh request is sent for 498 the dialog, or the dialog is terminated. 500 Unless a SIP feature cap is inserted in a Feature-Caps header field 501 or a target refresh request, or within a response of such request, it 502 indicates to the receivers of the request (or response) that the 503 feature is no long supported for the dialog. 505 For a given dialog a SIP entity MUST insert the same SIP feature caps 506 in all 18x and 2xx responses associated with a given transaction. 508 5.3.3. SIP Registration (REGISTER) 510 The Feature-Caps header field can be used within a SIP REGISTER 511 request, and within the 200 (OK) response associated with such 512 request. 514 If a SIP feature cap is conveyed in a Feature-Caps header field of a 515 REGISTER request, or within an associated response, it indicates to 516 the receivers of the message that the feature associated with the SIP 517 feature cap is supported for the registration, until the registration 518 of the contact that was explicitly conveyed in the REGISTER request 519 expires, or until the registered contact is explicitly refreshed and 520 the refresh REGISTER request does not contain the SIP feature cap 521 associated with the feature. 523 NOTE: While a REGISTER response can contain contacts that have been 524 registered as part of other registration transactions, support of any 525 indicated feature only applies to the contact(s) that were explicitly 526 conveyed in the associated REGISTER request. 528 This specification does not define any semantics for usage of the 529 Feature-Caps header field in pure registration binding fetching 530 messages (see Section 10.2.3 of RFC 3261), where the REGISTER request 531 does not contain a Contact header field. Unless such semantics is 532 defined in a future extension, fetching messages will not have any 533 impact on previously indicated support of features, and SIP entities 534 MUST NOT insert a Feature-Caps header field to such messages. 536 If SIP Outbound [RFC5626] is used, the rules above apply. However, 537 supported features only apply for the registration flow on which 538 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 SIP 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 SIP feature cap is supported for the 550 duration 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: SIP feature cap 561 6.2.1. General 563 In a SIP 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 SIP 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 RFC3840 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 is provided. 599 7. IANA Considerations 601 7.1. Registration of the Feature-Caps header field 603 This specification registers a new SIP header field, Feature-Caps, 604 according to the process of RFC 3261 [RFC3261]. 606 The following is the registration for the Feature-Caps header field: 608 RFC Number: RFC XXX 610 Header Field Name: Feature-Caps 612 7.2. Global Feature Cap Registration Tree 614 This specification creates a new SIP feature cap tree. The name of 615 the tree is "Global Feature Cap Registration Tree", and its leading 616 facet is "g.". It is used for the registration of SIP feature caps. 618 The addition of entries into this registry occurs through the Expert 619 Review policies, as defined in RFC 5226 [RFC5226]. A designated area 620 expert will review the proposed SIP feature cap, and consult with 621 members of related mailing lists. The information required in the 622 registration is defined in Section 4.3 of RFC XXX. 624 Note that all SIP feature caps registered in the SIP tree will have 625 names with a leading facet "g.". No leading "+" is used in the 626 registrations in any of the media feature tag trees. 628 7.3. SIP Feature Cap Registration Tree 630 This specification creates a new SIP feature cap tree, per the 631 guidelines... The name of the tree is "SIP Feature Cap Registration 632 Tree", and its leading facet is "sip.". It is used for the 633 registration of SIP feature caps. 635 The addition of entries into this registry occurs through the IETF 636 Consensus, as defined in RFC 5226 [RFC5226]. This requires the 637 publication of an RFC that contains the registration. The 638 information required in the registration is defined in Section 4.3 of 639 RFC XXX. 641 Note that all SIP feature caps registered in the SIP tree will have 642 names 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 SIP feature caps can provide sensitive information about a SIP 648 entity. RFC 3840 cautions against providing sensitive information to 649 another party. Once this information is given out, any use may be 650 made of it. 652 9. Acknowledgements 654 10. Change Log 656 [RFC EDITOR NOTE: Please remove this Section when publishing] 658 Changes from draft-ietf-sipcore-proxy-feature-01 659 o Changes based on comments from Paul Kyzivat. 660 o IANA Considerations text added. 662 Changes from draft-holmberg-sipcore-proxy-feature-04/ 663 draft-ietf-sipcore-proxy-feature-00 664 o Media feature tags replaced with SIP feature caps, based on 665 SIPCORE consensus at IETF#83 (Paris). 666 o Editorial corrections and modifications. 668 Changes from draft-holmberg-sipcore-proxy-feature-03 669 o Hadriel Kaplan added as co-author. 670 o Terminology change: instead of talking of proxies, talk about 671 entities which are not represented by the URI in a Contact header 672 field (http://www.ietf.org/mail-archive/web/sipcore/current/ 673 msg04449.html). 674 o Clarification regarding the usage of the header field in 18x/2xx 675 responses (http://www.ietf.org/mail-archive/web/sipcore/current/ 676 msg04449.html). 677 o Specifying that feature support can also be indicated in target 678 refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ 679 current/msg04454.html). 680 o Feature Cap specification registration information added. 682 Changes from draft-holmberg-sipcore-proxy-feature-02 683 o Definition, and usage of, a new header field, instead of Path, 684 Record-Route, Route and Service-Route. 686 Changes from draft-holmberg-sipcore-proxy-feature-01 687 o Requirement section added 688 o Use-cases and examples updated based on work in 3GPP 690 Changes from draft-holmberg-sipcore-proxy-feature-00 691 o Additional use-cases added 692 o Direction section added 694 11. References 696 11.1. Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 702 A., Peterson, J., Sparks, R., Handley, M., and E. 703 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 704 June 2002. 706 11.2. Informative References 708 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 709 Registration Procedure", BCP 31, RFC 2506, March 1999. 711 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 712 "Indicating User Agent Capabilities in the Session 713 Initiation Protocol (SIP)", RFC 3840, August 2004. 715 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 716 Preferences for the Session Initiation Protocol (SIP)", 717 RFC 3841, August 2004. 719 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 720 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 721 May 2008. 723 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 724 Initiated Connections in the Session Initiation Protocol 725 (SIP)", RFC 5626, October 2009. 727 [3GPP.23.237] 728 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 729 Stage 2", 3GPP TS 23.237 10.9.0, March 2012. 731 [3GPP.24.837] 732 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 733 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 734 10.0.0, April 2011. 736 Authors' Addresses 738 Christer Holmberg 739 Ericsson 740 Hirsalantie 11 741 Jorvas 02420 742 Finland 744 Email: christer.holmberg@ericsson.com 745 Ivo Sedlacek 746 Ericsson 747 Scheelevaegen 19C 748 Lund 22363 749 Sweden 751 Email: ivo.sedlacek@ericsson.com 753 Hadriel Kaplan 754 Acme Packet 755 71 Third Ave. 756 Burlington, MA 01803 757 USA 759 Email: hkaplan@acmepacket.com