idnits 2.17.1 draft-ietf-sipcore-proxy-feature-04.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 14, 2012) is 4307 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 16, 2012 H. Kaplan 6 Acme Packet 7 June 14, 2012 9 Mechanism to indicate support of features and capabilities in the 10 Session Initiation Protocol (SIP) 11 draft-ietf-sipcore-proxy-feature-04.txt 13 Abstract 15 This specification creates a new IANA registry, "Proxy-Feature 16 Feature Caps Trees", for registering "feature caps", which are used 17 by SIP entities not represented by the URI of the Contact header 18 field to indicate support of features and capabilities, where media 19 feature 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 16, 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. SIP 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. Proxy-Feature Feature Caps Trees . . . . . . . . . . . . . 15 96 7.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 15 97 7.2.2. Global Feature Cap Registration Tree . . . . . . . . . 15 98 7.2.3. SIP Feature Cap Registration Tree . . . . . . . . . . 15 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 101 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 104 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 107 1. Introduction 109 The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" 110 extension, defined in RFC 3840 [RFC3840], provides a mechanism that 111 allows a SIP message to convey information relating to the 112 originator's features and capabilities, using the Contact header 113 field. 115 This specification creates a new IANA registry, "Proxy-Feature 116 Feature Caps Trees", for registering "feature caps", which are used 117 by SIP entities not represented by the URI of the Contact header 118 field to indicate support of features and capabilities, where media 119 feature tags cannot be used to indicate the support. Such cases are: 121 o - The SIP entity acts as a SIP proxy. 122 o - The SIP entity acts as a SIP registrar. 123 o - The SIP entity acts as a B2BUA, where the Contact header field 124 URI represents another SIP entity. 126 This specification also defines a new SIP header field, Feature-Caps, 127 to convey feature caps in SIP messages. 129 NOTE: Unlike media feature tags, feature caps are intended to only be 130 used with the SIP protocol. 132 2. Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in BCP 14, RFC 2119 137 [RFC2119]. 139 3. Definitions 141 Downstream SIP entity: SIP entity in the direction towards which a 142 SIP request is sent. 144 Upstream SIP entity: SIP entity in the direction from which a SIP 145 request is received. 147 4. Feature Caps 148 4.1. Introduction 150 Feature caps are used by SIP entities not represented by the URI of 151 the Contact header field to indicate support of features and 152 capabilities, where media feature tags cannot be used to indicate the 153 support. 155 A value, or a list of values, that provides additional information 156 about the supported feature or capability, can be associated with a 157 feature cap. 159 Section 5 defines how feature caps are conveyed using the Feature- 160 Caps header field. 162 The feature cap ABNF is defined in Section 6.2.2. 164 4.2. Registration Trees 166 4.2.1. General 168 The following subsections define registration trees, distinguished by 169 the use of faceted names (e.g., names of the form "tree.feature- 170 name"). The registration trees are defined in the IANA "Proxy- 171 Feature Feature Caps Trees" registry. 173 The trees defined herein are similar to the global tree and sip tree 174 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840 175 [RFC3840]. Other registration trees are outside the scope of this 176 specification. 178 NOTE: In contrast to RFC 2506 and RFC 3840, this specification only 179 defines a global tree and a sip tree, as they are the only trees 180 defined in those RFCs that have been used for defining SIP-specific 181 media feature tags. 183 When a feature cap is registered in any registration tree, no leading 184 "+" is used in the registration. 186 4.2.2. Global Tree 188 The global feature cap tree is similar to the media feature tag 189 global tree defined in RFC 2506 [RFC2506]. 191 A feature cap for the global tree will be registered by the IANA 192 after review by a designated expert. That review will serve to 193 ensure that the feature cap meets the technical requirements of this 194 specification. 196 A feature cap in the global tree will be distinguished by the leading 197 facet "g.". An organization can propose either a designation 198 indicative of the feature, (e.g., "g.blinktags") or a faceted 199 designation including the organization name (e.g., 200 "g.organization.blinktags"). 202 When a feature cap is registered in the global tree, it needs to meet 203 the "Expert Review" policies defined in RFC 5226 [RFC5226]. A 204 designated area expert will review the proposed feature cap, and 205 consult with members of related mailing lists. 207 4.2.3. SIP Tree 209 The sip feature cap tree is similar to the media feature tag sip tree 210 defined in RFC 3840 [RFC3840]. 212 A feature cap in the sip tree will be distinguished by the leading 213 facet "sip.". 215 When a feature cap is registered in the sip tree, it needs to meet 216 the "IETF Consensus" policies defined in RFC 5226 [RFC5226]. An RFC, 217 which contains the registration of the feature cap, MUST be 218 published. 220 4.3. Registration Template 222 To: sip-feature-caps@apps.ietf.org (feature caps mailing list) 223 Subject: Registration of feature cap XXXX 225 | Instructions are preceded by '|'. Some fields are optional. 227 Feature cap name: 229 Summary of feature indicated by this feature cap: 231 | The summary should be no longer than 4 lines. More 232 | detailed information can be provided in the SIP feature 233 | cap specification. 235 Feature cap specification reference: 237 | The referenced specification MUST contain the information 238 | listed in section XX of XXXX (IANA: Replace XXXX with 239 | assigned RFC number of this specification. 241 Values appropriate for use with this feature cap: 243 | If no values are defined for the feature cap, 244 | indicate "N/A". Details about feature cap values 245 | MUST be defined in the feature cap specification. 247 The feature cap is intended primarily for 248 use in the following applications, protocols, 249 services, or negotiation mechanisms: [optional] 251 | For applications, also specify the number of the 252 | first version which will use the feature cap, 253 | if applicable. 255 Examples of typical use: [optional] 257 Considerations particular to use in individual 258 applications, protocols, services, or negotiation 259 mechanisms: [optional] 261 Interoperability considerations: [optional] 263 Security considerations: 265 Privacy concerns, related to exposure of personal 266 information: 268 Denial of service concerns related to consequences 269 of specifying incorrect values: 271 Other: 273 Additional information: [optional] 275 Keywords: [optional] 277 Related feature caps: [optional] 279 Name(s) & email address(es) of person(s) to 280 contact for further information: 282 Intended usage: 284 | one of COMMON, LIMITED USE or OBSOLETE 286 Author/Change controller: 288 Other information: [optional] 290 | Any other information that the author deems 291 | interesting may be added here. 293 Figure 1: Registration Template 295 4.4. Feature Cap Specification Requirements 297 4.4.1. General 299 A feature cap specification MUST address the issues defined in the 300 following subsections, or document why an issue is not applicable for 301 the specific feature cap. A reference to the specification MUST be 302 provided when the feature cap is registered with IANA (see 303 Section 4.3). 305 It is bad practice for feature cap specifications to repeat 306 procedures (e.g. general procedures on the usage of the Feature-Caps 307 header field and feature caps) defined in this specification, unless 308 needed for clarification or emphasis purpose. 310 A feature cap specification MUST NOT weaken any behavior designated 311 with "SHOULD" or "MUST" in this specification. However, a 312 specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" 313 requirements to "MUST" strength if features and capabilities 314 associated with the SIP feature cap require it. 316 4.4.2. Overall Description 318 The feature cap specification MUST contain an overall description of 319 the feature cap: how it is used to indicate support of a feature, a 320 description of the feature associated with the SIP feature cap, a 321 description of any additional information (conveyed using one or more 322 feature cap values) that can be conveyed together with the feature 323 cap, and a description of how the associated feature may be 324 exercised/invoked. 326 4.4.3. Feature Cap Values 328 A feature cap can have an associated value, or a list of values. 330 The feature cap specification MUST define the syntax and semantics of 331 any value defined for the feature cap, including possible 332 restrictions related to the usage of a specific value. The feature 333 cap specification MUST define the value(s) in accordance with the 334 syntax defined in section 6.2.2. 336 A feature cap value is only applicable for the feature cap for which 337 it has been defined. For other feature caps, the value has to be 338 defined explicitly, even if the semantics are identical. 340 It is STRONGLY RECOMMENDED to not re-use a value that already has 341 been defined for another feature cap, unless the semantics of the 342 values are the same. 344 4.4.4. Usage Restrictions 346 If there are restrictions on how SIP entities can insert a SIP 347 feature cap, the feature cap specification MUST document such 348 restrictions. 350 There might be restrictions related to whether entities are allowed 351 to insert a feature cap in registration related messages, standalone 352 transaction messages, or dialog related messages, whether entities 353 are allowed to insert a feature cap in requests or responses, whether 354 entities also need to support other features and capabilities in 355 order to insert a feature cap, and whether entities are allowed to 356 indicate support of a feature in conjunction with another feature. 358 4.4.5. Examples 360 It is RECOMMENDED that the feature cap specification provide 361 demonstrative message flow diagrams, paired with complete messages 362 and message descriptions. 364 Note that example message flows are by definition informative, and do 365 not replace normative text. 367 5. Feature-Caps Header Field 369 5.1. Introduction 371 The Feature-Caps header field is used by SIP entities to convey 372 support of features and capabilities, by setting feature caps. 373 Feature caps conveyed in a Feature-Caps header field indicate that 374 the SIP entity that inserted the header field supports the associated 375 features and capabilities. 377 NOTE: It is not possible to, as a Feature-Caps header field value, 378 convey the address of the SIP entity that inserted the Feature-Caps 379 header field. If additional data about a supported feature needs to 380 be conveyed, such as the address of the SIP entity that indicated 381 support of the feature, then the feature definition needs to define a 382 way to convey that information as a value of the associated feature 383 cap. 385 The feature cap specification MUST specify for which SIP methods and 386 message types, and the associated semantics, the feature cap is 387 applicable. See Section 4 for more information. No semantics is 388 defined for feature caps present in SIP methods and message types not 389 covered by the associated feature cap specification. 391 Within a given Feature-Caps header field, feature caps are listed in 392 a non-priority order, and for a given header field any order of 393 listed SIP feature caps have the same meaning. For example, 394 "foo;bar" and "bar;foo" have the same meaning (i.e. that the SIP 395 entity that inserted the feature caps supports the features and 396 capabilities associated with the "foo" and "bar" feature caps. 398 5.2. User Agent and Proxy Behavior 400 5.2.1. General 402 If the URI in a Contact header field of a request or response 403 represents a SIP entity, the entity MUST NOT indicate supported 404 features and capabilities using a Feature-Caps header field within 405 that request or response. 407 When a SIP entity receives a SIP request, or response, that contains 408 one or more Feature-Caps header fields, the feature caps in the 409 header field inform the entity about the features and capabilities 410 supported by the entities that inserted the header fields. 411 Procedures how features and capabilities are invoked are outside the 412 scope of this specification, and MUST be described by individual 413 feature cap specifications. 415 When a SIP entity adds a Feature-Caps header field to a SIP message, 416 it MUST place the header field before any existing Feature-Caps 417 header field in the message to be forwarded, so that the added header 418 field becomes the top-most one. Then, when another SIP entity 419 receives a SIP request or the response, the SIP feature caps in the 420 top-most Feature-Caps header field will represent the supported 421 features and capabilities "closest" to the entity. 423 5.2.2. B2BUA Behavior 425 The procedures in this Section applies to UAs that are part of B2BUAs 426 that are referenced in the message by a Record-Route header field 427 rather than by the URI of the Contact header field. 429 When a UA sends a SIP request, if the UA wants to indicate support of 430 features and capabilities towards its downstream SIP entities, it 431 inserts a Feature-Caps header field to the request, containing one or 432 more feature caps associated with the supported features and 433 capabilities, before it forwards the request. 435 If the SIP request is triggered by another SIP request that the B2BUA 436 has received, the UA MAY forward received Feature-Caps header fields 437 by copying them to the outgoing SIP request, similar to a SIP proxy, 438 before it inserts its own Feature-Caps header field to the SIP 439 request. 441 When a UA receives a SIP response, if the UA wants to indicate 442 support of features and capabilities towards its upstream SIP 443 entities, it inserts a Feature-Caps header field to the response, 444 containing one or more feature caps associated with the supported 445 features and capabilities, before it forwards the response. 447 If the SIP response is triggered by another SIP response that the 448 B2BUA has received, the UA MAY forward received Feature-Caps header 449 field by copying them to the outgoing SIP response, similar to a SIP 450 proxy, before it inserts its own Feature-Caps header field to the SIP 451 response. 453 5.2.3. Registrar Behavior 455 If a SIP registrar wants to indicate support of features and 456 capabilities towards its upstream SIP entities, it inserts a Feature- 457 Caps header field, containing one or more feature caps associated 458 with the supported features and capabilities, to a REGISTER response. 460 5.2.4. Proxy behavior 462 When a SIP proxy receives a SIP request, if the proxy wants to 463 indicate support of features and capabilities towards its downstream 464 SIP entities, it inserts a Feature-Caps header field to the request, 465 containing one or more SIP feature caps associated with the supported 466 features and capabilities, before it forwards the request. 468 When a proxy receives a SIP response, if the proxy wants to indicate 469 support of features and capabilities towards its upstream SIP 470 entities, it inserts a Feature-Caps header field to the response, 471 containing one or more SIP feature caps associated with the supported 472 features and capabilities, before it forwards the response. 474 5.3. SIP Message Type and Response Code Semantics 476 5.3.1. General 478 This Section describes the general usage and semantics of the 479 Feature-Caps header field for different SIP message types and 480 response codes. The usage and semantics of a specific feature cap 481 MUST be described in the associated feature cap specification. 483 NOTE: Future specifications can define usage and semantics of the 484 Feature-Caps header field for SIP methods, response codes and request 485 types not specified in this specification. 487 The Feature-Caps header field ABNF is defined in Section 6.3.1. 489 5.3.2. SIP Dialog 491 The Feature-Caps header field can be used within an initial SIP 492 request for a dialog, within a target refresh SIP request, and within 493 any 18x or 2xx response associated with such requests. 495 If a feature cap is inserted in a Feature-Caps header field of an 496 initial request for a dialog, or within a response of such request, 497 it indicates to the receivers of the request (or response) that the 498 feature associated with the feature cap is supported for the duration 499 of the dialog, until a target refresh request is sent for the dialog, 500 or the dialog is terminated. 502 Unless a feature cap is inserted in a Feature-Caps header field or a 503 target refresh request, or within a response of such request, it 504 indicates to the receivers of the request (or response) that the 505 feature is no long supported for the dialog. 507 For a given dialog a SIP entity MUST insert the same feature caps in 508 all 18x and 2xx responses associated with a given transaction. 510 5.3.3. SIP Registration (REGISTER) 512 The Feature-Caps header field can be used within a SIP REGISTER 513 request, and within the 200 (OK) response associated with such 514 request. 516 If a feature cap is conveyed in a Feature-Caps header field of a 517 REGISTER request, or within an associated response, it indicates to 518 the receivers of the message that the feature associated with the 519 feature cap is supported for the registration, until the registration 520 of the contact that was explicitly conveyed in the REGISTER request 521 expires, or until the registered contact is explicitly refreshed and 522 the refresh REGISTER request does not contain the feature cap 523 associated with the feature. 525 NOTE: While a REGISTER response can contain contacts that have been 526 registered as part of other registration transactions, support of any 527 indicated feature only applies to the contact(s) that were explicitly 528 conveyed in the associated REGISTER request. 530 This specification does not define any semantics for usage of the 531 Feature-Caps header field in pure registration binding fetching 532 messages (see Section 10.2.3 of RFC 3261), where the REGISTER request 533 does not contain a Contact header field. Unless such semantics is 534 defined in a future extension, fetching messages will not have any 535 impact on previously indicated support of features and capabilities, 536 and SIP entities MUST NOT insert a Feature-Caps header field to such 537 messages. 539 If SIP Outbound [RFC5626] is used, the rules above apply. However, 540 supported features and capabilities only apply for the registration 541 flow on which support has been explicitly indicated. 543 5.3.4. SIP Stand-Alone Transactions 545 The Feature-Caps header field can be used within a standalone SIP 546 request, and within any 18x or 2xx response associated with such 547 request. 549 If a feature cap is inserted in a Feature-Caps header field of a 550 standalone request, or within a response of such request, it 551 indicates to the receivers of the request (or response) that the 552 feature associated with the feature cap is supported for the duration 553 of the standalone transaction. 555 6. Syntax 557 6.1. General 559 This Section defines the ABNF for Feature-Caps, and for the Feature- 560 Cap header field. 562 6.2. Syntax: feature cap 564 6.2.1. General 566 In a feature cap name (ABNF: fcap-name), dots can be used to 567 implement a SIP feature cap tree hierarchy (e.g. 568 tree.feature.subfeature). The description of usage of such tree 569 hierarchy must be described when registered. 571 6.2.2. ABNF 573 The ABNF for the feature cap: 575 feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list 576 / fcap-string-value ) RDQUOT] 577 fcap-name = ftag-name 578 fcap-value-list = tag-value-list 579 fcap-string-value = string-value 580 ;; ftag-name, tag-value-list, string-value defined in RFC 3840 582 NOTE: In comparison with media feature tags, the "+" sign in front 583 of the feature cap name is mandatory. 585 Figure 2: ABNF 587 6.3. Syntax: Feature-Caps header field 589 6.3.1. ABNF 591 The ABNF for the Feature-Caps header fields is: 593 Feature-Caps = "Feature-Caps" HCOLON fc-value 594 *(COMMA fc-value) 595 fc-value = "*" *(SEMI feature-cap) 597 Figure 3: ABNF 599 NOTE: A "*" value means that no information regarding which SIP 600 entity, or domain, that indicate support of features and capabilities 601 is provided. 603 7. IANA Considerations 605 7.1. Registration of the Feature-Caps header field 607 This specification registers a new SIP header field, Feature-Caps, 608 according to the process of RFC 3261 [RFC3261]. 610 The following is the registration for the Feature-Caps header field: 612 RFC Number: RFC XXX 614 Header Field Name: Feature-Caps 616 7.2. Proxy-Feature Feature Caps Trees 618 7.2.1. Introduction 620 This specification creates a new sub registry to the IANA "Session 621 Initiation Protocol (SIP) Parameters" Protocol Registry, per the 622 guidelines in RFC 5226 [RFC5226]. The name of the sub registry is 623 "Proxy-Feature Feature Caps Trees". 625 7.2.2. Global Feature Cap Registration Tree 627 This specification creates a new feature cap tree in the IANA "Proxy- 628 Feature Feature Caps Trees" registry. The name of the tree is 629 "Global Feature Cap Registration Tree", and its leading facet is 630 "g.". It is used for the registration of feature caps. 632 The addition of entries into this tree occurs through the Expert 633 Review policies, as defined in RFC 5226. A designated area expert 634 will review the proposed feature cap, and consult with members of 635 related mailing lists. The information required in the registration 636 is defined in Section 4.3 of RFC XXX. 638 Note that all feature caps registered in the global tree will have 639 names with a leading facet "g.". No leading "+" is used in the 640 registrations in any of the feature cap registration trees. 642 7.2.3. SIP Feature Cap Registration Tree 644 This specification creates a new feature cap tree in the IANA "Proxy- 645 Feature Feature Caps Trees" registry. The name of the tree is "SIP 646 Feature Cap Registration Tree", and its leading facet is "sip.". It 647 is used for the registration of feature caps. 649 The addition of entries into this tree occurs through the IETF 650 Consensus, as defined in RFC 5226. This requires the publication of 651 an RFC that contains the registration. The information required in 652 the registration is defined in Section 4.3 of RFC XXX. 654 Note that all feature caps registered in the SIP tree will have names 655 with a leading facet "sip.". No leading "+" is used in the 656 registrations in any of the feature cap registration trees. 658 8. Security Considerations 660 The security issues for feature caps are similar to the ones defined 661 in RFC 3840 for media feature tags. However, as feature caps will 662 typically not be used to convey capability information of end-user 663 devices, those aspects of RFC 3840 do not apply to feature caps. 665 In addition, the RFC 3840 security issue regarding an attacker using 666 the SIP caller preferences extension [RFC3841] in order to affect 667 routing decisions does not apply, as the mechanism is not defined to 668 be used with feature caps. 670 Feature caps can provide capability and characteristics information 671 about the SIP entity, some of which might be sensitive. The Feature- 672 Caps header field does not convey address information about SIP 673 entities. However, individual feature caps might provide address 674 information as feature cap values. Therefore, mechanisms for 675 guaranteeing confidentiality and authenticity SHOULD be provided. 677 9. Acknowledgements 679 The authors wish to thank everyone in the SIP community that provided 680 input and feedback on the work of this specification. 682 10. Change Log 684 [RFC EDITOR NOTE: Please remove this Section when publishing] 686 Changes from draft-ietf-sipcore-proxy-feature-03 687 o Additional Security Considerations text added. 688 o IANA Considerations modified. 689 o Editorial corrections. 691 Changes from draft-ietf-sipcore-proxy-feature-02 692 o Changes based on WGLC comments from Shida Schubert. 693 o - Document title changed 694 o - Terminology alignment 695 o - Note text clarifications 696 o Changes based on WGLC comments from Lili Yang. 698 Changes from draft-ietf-sipcore-proxy-feature-01 699 o Changes based on comments from Paul Kyzivat. 700 o IANA Considerations text added. 702 Changes from draft-holmberg-sipcore-proxy-feature-04/ 703 draft-ietf-sipcore-proxy-feature-00 704 o Media feature tags replaced with feature caps, based on SIPCORE 705 consensus at IETF#83 (Paris). 706 o Editorial corrections and modifications. 708 Changes from draft-holmberg-sipcore-proxy-feature-03 709 o Hadriel Kaplan added as co-author. 710 o Terminology change: instead of talking of proxies, talk about 711 entities which are not represented by the URI in a Contact header 712 field (http://www.ietf.org/mail-archive/web/sipcore/current/ 713 msg04449.html). 714 o Clarification regarding the usage of the header field in 18x/2xx 715 responses (http://www.ietf.org/mail-archive/web/sipcore/current/ 716 msg04449.html). 717 o Specifying that feature support can also be indicated in target 718 refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ 719 current/msg04454.html). 720 o Feature Cap specification registration information added. 722 Changes from draft-holmberg-sipcore-proxy-feature-02 723 o Definition, and usage of, a new header field, instead of Path, 724 Record-Route, Route and Service-Route. 726 Changes from draft-holmberg-sipcore-proxy-feature-01 727 o Requirement section added 728 o Use-cases and examples updated based on work in 3GPP 730 Changes from draft-holmberg-sipcore-proxy-feature-00 731 o Additional use-cases added 732 o Direction section added 734 11. References 736 11.1. Normative References 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 742 A., Peterson, J., Sparks, R., Handley, M., and E. 743 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 744 June 2002. 746 11.2. Informative References 748 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 749 Registration Procedure", BCP 31, RFC 2506, March 1999. 751 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 752 "Indicating User Agent Capabilities in the Session 753 Initiation Protocol (SIP)", RFC 3840, August 2004. 755 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 756 Preferences for the Session Initiation Protocol (SIP)", 757 RFC 3841, August 2004. 759 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 760 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 761 May 2008. 763 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 764 Initiated Connections in the Session Initiation Protocol 765 (SIP)", RFC 5626, October 2009. 767 [3GPP.23.237] 768 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 769 Stage 2", 3GPP TS 23.237 10.9.0, March 2012. 771 [3GPP.24.837] 772 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 773 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 774 10.0.0, April 2011. 776 Authors' Addresses 778 Christer Holmberg 779 Ericsson 780 Hirsalantie 11 781 Jorvas 02420 782 Finland 784 Email: christer.holmberg@ericsson.com 786 Ivo Sedlacek 787 Ericsson 788 Scheelevaegen 19C 789 Lund 22363 790 Sweden 792 Email: ivo.sedlacek@ericsson.com 793 Hadriel Kaplan 794 Acme Packet 795 71 Third Ave. 796 Burlington, MA 01803 797 USA 799 Email: hkaplan@acmepacket.com