idnits 2.17.1 draft-ietf-sipcore-proxy-feature-01.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 (April 17, 2012) is 4384 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: October 19, 2012 H. Kaplan 6 Acme Packet 7 April 17, 2012 9 Indication of features supported by proxy 10 draft-ietf-sipcore-proxy-feature-01.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 October 19, 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. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. Registration Trees . . . . . . . . . . . . . . . . . . . . 6 68 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.3.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 6 70 4.3.3. SIP Feature Cap Registration Tree . . . . . . . . . . 7 71 4.4. Registration Template . . . . . . . . . . . . . . . . . . 7 72 4.5. SIP Feature Cap Specification Requirements . . . . . . . . 9 73 4.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.5.2. Overall Description . . . . . . . . . . . . . . . . . 9 75 4.5.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 9 76 4.5.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 10 77 4.5.5. Implementation Details . . . . . . . . . . . . . . . . 10 78 4.5.6. Examples . . . . . . . . . . . . . . . . . . . . . . . 10 79 5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 10 80 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 81 5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 11 82 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 83 5.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 12 84 5.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 12 85 5.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 12 86 5.3. SIP Message Type and Response Code Semantics . . . . . . . 13 87 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 88 5.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 13 89 5.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 14 90 5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 14 91 5.4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 5.4.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 94 6.1. Registration of the Feature-Caps header field . . . . . . 15 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 97 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" 106 extension, defined in RFC 3840 [RFC3840], provides a mechanism that 107 allows a SIP message to convey information relating to the 108 originator's features and capabilities, using the Contact header 109 field. 111 This specification creates a new IANA registry, "SIP Feature Cap 112 Registry", which is used to register indicators, "SIP feature caps", 113 that can be used by SIP entities to indicate support of features and 114 capabilities, in cases where the Contact header field contains a URI 115 that does not represent the SIP entity that wants to indicate support 116 of its features and capabilities, and media feature tags cannot be 117 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 that can be used by SIP entities to convey information about 126 supported features and capabilities, using SIP feature caps. 128 Unlike media feature tags, SIP feature caps are intended to only be 129 used with the SIP protocol. 131 2. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in BCP 14, RFC 2119 136 [RFC2119]. 138 3. Definitions 140 Downstream SIP entity: SIP entity in the direction towards which a 141 SIP request is sent. 143 Upstream SIP entity: SIP entity in the direction from which a SIP 144 request is received. 146 4. SIP Feature Caps 148 4.1. Introduction 150 A SIP feature cap can be used by SIP entities to indicate support of 151 features and capabilities, in cases where media feature tags cannot 152 be used, ie if the Contact header field contains a URI that does not 153 represent the SIP entity that wants to indicate support of its 154 features and capabilities. 156 A value, or a list of values, can be associated with a SIP feature 157 cap. 159 [ref-to-section] defines how SIP feature caps are conveyed using the 160 SIP Feature-Caps header field. 162 4.2. Syntax 164 4.2.1. General 166 In a SIP feature cap name (ABNF: fcap-name), dots can be used to 167 implement a SIP feature cap tree hierarchy (e.g. 168 tree.feature.subfeature). The description of usage of such tree 169 hierarchy must be described when registered. 171 4.2.2. ABNF 173 The ABNF for the Feature-Caps header field is: 175 feature-cap = ["+"] fcap-name [EQUAL LDQUOT (fcap-value-list 176 / string-value ) RDQUOT] 177 fcap-name = ALPHA *( ALPHA / DIGIT / "!" / "'" 178 / "." / "-" / "%" ) 179 fcap-value-list = fcap-value *("," fcap-value) 180 fcap-value = ["!"] (token-nobang / boolean / numeric) 181 token-nobang = 1*(alphanum / "-" / "." / "%" / "*" 182 / "_" / "+" / "`" / "'" / "~" ) 183 boolean = "TRUE" / "FALSE" 184 numeric = "#" numeric-relation number 185 numeric-relation = ">=" / "<=" / "=" / (number ":") 186 number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] 187 string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">" 188 qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D 189 / %x3F-5B / %x5D-7E / UTF8-NONASCII 190 ;;gdtext as defined in RFC 3261 191 Figure 1: ABNF 193 4.3. Registration Trees 195 4.3.1. General 197 The following subsections define registration "trees", distinguished 198 by the use of faceted names (e.g., names of the form "tree.feature- 199 name"). 201 The tree definitions are based on the global tree and sip tree 202 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841 203 [RFC3841]. 205 Additional feature caps trees can be created by IANA, following the 206 same rules and procedures as defined for media feature tags in 207 section 3.1.4 of RFC 2506 [RFC2506]. 209 The acceptance of the proposed designation is at the discretion of 210 IANA. If IANA believes that additional information, or 211 clarification, is needed, it can request an updated proposal from the 212 proposing organization. 214 When a SIP feature cap is registered in any registration tree, no 215 leading "+" is used in the registration. 217 4.3.2. Global Tree 219 The SIP feature cap global tree is based on the media feature tag 220 global tree defined in RFC 2506 [RFC2506]. 222 A SIP feature cap for the global tree will be registered by the IANA 223 after review by a designated expert. That review will serve to 224 ensure that the SIP feature cap meets the technical requirements of 225 this specification. 227 A SIP feature cap in the global tree will be distinguished by the 228 leading facet "g.". An organization can propose either a designation 229 indicative of the feature, (e.g., "g.blinktags") or a faceted 230 designation including the organization name (e.g., 231 "g.organization.blinktags"). 233 When a SIP feature cap is registered in the global tree, it needs to 234 meet the "Expert Review" policies defined in RFC 5226 [RFC5226]. A 235 designated area expert will review the proposed SIP feature cap, and 236 consult with members of related mailing lists. 238 4.3.3. SIP Feature Cap Registration Tree 240 The SIP feature cap sip tree is based on the media feature tag sip 241 tree defined in RFC 3840 [RFC3840]. 243 A SIP feature cap in the sip tree will be distinguished by the 244 leading facet "sip.". 246 When a SIP feature cap is registered in the sip tree, it needs to 247 meet the "IETF Consensus" policies defined in RFC 5226 [RFC5226]. An 248 RFC, which contains the registration of the SIP feature cap, must be 249 published. 251 4.4. Registration Template 253 To: sip-feature-caps@apps.ietf.org (SIP feature caps mailing list) 254 Subject: Registration of SIP feature cap XXXX 256 | Instructions are preceded by `|'. Some fields are optional. 258 SIP feature cap name: 260 Summary of feature indicated by this SIP feature cap: 262 | The summary should be no longer than 4 lines. More 263 | detailed information can be provided in the SIP feature 264 | cap specification 266 SIP feature cap specification reference: 268 | The reference MUST contain the information listed in 269 | section XX of XXXX (IANA: Replace XXXX with assigned 270 | RFC number of this specification 272 Values appropriate for use with this SIP feature cap: 274 | If no values are defined for the SIP feature cap, 275 | indicate "N/A". Details about SIP feature cap values 276 | MUST be defined in the SIP feature cap specification. 278 The SIP feature cap is intended primarily for 279 use in the following applications, protocols, 280 services, or negotiation mechanisms: [optional] 282 | For applications, also specify the number of the 283 | first version which will use the SIP feature cap, 284 | if applicable. 286 Examples of typical use: [optional] 288 Related standards or documents: [optional] 290 Considerations particular to use in individual 291 applications, protocols, services, or negotiation 292 mechanisms: [optional] 294 Interoperability considerations: [optional] 296 Security considerations: 298 Privacy concerns, related to exposure of personal 299 information: 301 Denial of service concerns related to consequences 302 of specifying incorrect values: 304 Other: 306 Additional information: [optional] 308 Keywords: [optional] 310 Related SIP feature caps: [optional] 312 Name(s) & email address(es) of person(s) to 313 contact for further information: 315 Intended usage: 317 | one of COMMON, LIMITED USE or OBSOLETE 319 Author/Change controller: 321 Requested IANA publication delay: [optional] 323 | A delay may only be requested for final placement 324 | in the global or IETF trees, with a maximum of two 325 | months. Organizations requesting a registration 326 | with a publication delay should note that this 327 | delays only the official publication of the SIP 328 | feature cap and does not prevent information on 329 | it from being disseminated by the members of the 330 | relevant mailing list. 332 Other information: [optional] 334 | Any other information that the author deems 335 | interesting may be added here. 337 Figure 2: Registration Template 339 4.5. SIP Feature Cap Specification Requirements 341 4.5.1. General 343 A SIP feature cap specification MUST address the issues defined in 344 the following subsections, or document why an issue is not applicable 345 for the specific SIP feature cap. A reference to the specification 346 MUST be provided when the SIP feature cap is registered with IANA 347 (see [ref-to-temp]). 349 It is bad practice for SIP feature cap specifications to repeat 350 procedures defined in this specification, unless needed for 351 clarification or emphasis purpose. 353 A SIP feature cap specification MUST NOT weaken any behavior 354 designated with "SHOULD" or "MUST" in this specification. However, a 355 specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" 356 requirements to "MUST" strength if features associated with the SIP 357 feature cap require it. 359 4.5.2. Overall Description 361 The SIP feature cap specification MUST contain an overall description 362 of the SIP feature cap: how it is used to indicate support of a 363 feature, a description of the feature associated with the SIP feature 364 cap, and a description of any additional information (conveyed using 365 one or more SIP feature cap values) that can be conveyed together 366 with the SIP feature cap. 368 4.5.3. Feature Cap Values 370 A SIP feature cap can have an associated value, or a list of values. 371 A SIP feature cap value MUST conform to the ABNF defined in 372 Section 4.2.2. 374 The SIP feature cap specification MUST define the syntax and 375 semantics of any value defined for the SIP feature cap, including 376 possible restrictions related to the usage of a specific value. 378 A SIP feature cap value can share the name with a value defined for 379 another SIP feature cap. However, a value defined for a SIP feature 380 cap is feature cap specific, and can only be used with a SIP feature 381 cap for which the value has explicitly been defined. 383 It is STRONLY RECOMMENDED to not re-use a value name that already has 384 been defined for another SIP feature cap, unless the semantics of the 385 values are the same. 387 4.5.4. Usage Restrictions 389 If there are restrictions on how SIP entities can insert a SIP 390 feature cap, the SIP feature cap specification MUST document such 391 restrictions. 393 There might be restrictions related to whether entities are allowed 394 to insert a SIP feature cap in registration related messages, 395 standalone transaction messages, or dialog related messages, whether 396 entities are allowed to insert a SIP feature cap in requests or 397 responses, whether entities also need to support other features in 398 order to insert a SIP feature cap, and whether entities are allowed 399 to indicate support of a feature in conjunction with another feature. 401 4.5.5. Implementation Details 403 The SIP feature cap specification SHOULD define the procedure 404 regarding how implementers shall implement and use the Feature Cap, 405 or refer to other locations where implementers can find that 406 information. 408 NOTE: Sometimes a SIP feature cap designer might choose to not reveal 409 the implementation details of a SIP feature cap. However, in order 410 to allow multiple implementations to support the SIP feature cap, 411 designers are strongly encouraged to provide the implementation 412 details. 414 4.5.6. Examples 416 It is RECOMMENDED that the SIP feature cap specification provide 417 demonstrative message flow diagrams, paired with complete messages 418 and message descriptions. 420 Note that example flows are by definition informative, and do not 421 replace normative text. 423 5. Feature-Caps Header Field 424 5.1. Introduction 426 The Feature-Caps header field is used by SIP entities to convey 427 support of features and capabilities, using SIP feature caps. SIP 428 feature caps inserted in a Feature-Caps header field indicate that 429 the SIP entity that inserted the header field supports the associated 430 features. 432 NOTE: It is not possible to convey the address of the SIP entity as a 433 Feature-Caps header field parameter. Each feature that requires 434 address information to be conveyed need to define a way to convey 435 that information as part of the associated SIP feature cap value. 437 The SIP feature cap specification MUST specify for which SIP methods 438 and message types, and the associated semantics, the SIP feature cap 439 is applicable. See section [ref-to-reg-temp} for more information. 440 No semantics is defined for SIP feature caps present in SIP methods 441 and message types not covered by the associated SIP feature cap 442 specification. 444 Within a given Feature-Caps header field, SIP feature caps are listed 445 in a non-priority order, and for a given header field any order of 446 listed SIP feature caps have the same meaning. For example, 447 "foo;bar" and "bar;foo" have the same meaning(i.e. that the SIP 448 entity that inserted the feature caps supports the features 449 associated with the "foo" and "bar" SIP feature caps. 451 5.2. User Agent and Proxy Behavior 453 5.2.1. General 455 If the URI in a Contact header field of a request or response 456 represents a UA, the UA MUST NOT indicate supported features and 457 capabilities using a Feature-Caps header field within that request or 458 response. 460 When a UA receives a SIP request, or response, that contains one or 461 more Feature-Caps header fields, the Feature Caps in the header field 462 inform the UA is about the features supported by the entities that 463 inserted the header fields. Procedures how features are invoked are 464 outside the scope of this specification, and MUST be described by 465 individual Feature Cap specifications. 467 When the UA receives the SIP request or the response, the SIP feature 468 caps in the topmost Feature-Caps header field will represent the 469 supported features "closest" to the UA. 471 5.2.2. B2BUA Behavior 473 The procedures in this section applies to UAs that are part of 474 B2BUAs, but where the URI in the Contact header field does not 475 represent the UA, because the B2BUA is also acting as a proxy and 476 inserts its URI e.g. in a Record-Route header field. 478 When a UA sends a SIP request, if the UA wants to indicate support of 479 features towards its downstream SIP entities, it adds a Feature-Caps 480 header field to the request, together with one or more Feature Caps 481 associated with the supported features, before it forwards the 482 request. 484 If the SIP request is triggered by another SIP request that the B2BUA 485 has received, the UA MAY forward those Feature-Caps header field by 486 copying them to the outgoing SIP request, similar to a SIP proxy, 487 before it adds its own Feature-Caps header field to the SIP request. 489 When a UA receives a SIP response, if the UA wants to indicate 490 support of features towards its upstream SIP entities, it adds a 491 Feature-Caps header field to the response, together with one or more 492 Feature Caps associated with the supported features, before it 493 forwards the response. 495 If the SIP response is triggered by another SIP response that the 496 B2BUA has received, the UA MAY forward those Feature-Caps header 497 field by copying them to the outgoing SIP response, similar to a SIP 498 proxy, before it adds its own Feature-Caps header field to the SIP 499 response. 501 5.2.3. Registrar Behavior 503 If a SIP registrar wants to indicate support of features towards its 504 upstream SIP entities, it can insert a Feature-Caps header field, 505 together with Feature Caps associated with the supported features, in 506 a REGISTER response. 508 5.2.4. Proxy behavior 510 When a SIP proxy receives a SIP request, if the proxy wants to 511 indicate support of features towards its downstream SIP entities, it 512 adds a Feature-Caps header field to the request, together with one or 513 more SIP feature caps associated with the supported features, before 514 it forwards the request. 516 When a proxy adds a Feature-Caps header field to a SIP message, it 517 MUST place the header field before any existing Feature-Caps header 518 fields in the request. 520 When a proxy receives a SIP response, if the proxy wants to indicate 521 support of features towards its upstream SIP entities, it adds a 522 Feature-Caps header field to the response, together with one or more 523 SIP feature caps associated with the supported features, before it 524 forwards the response. 526 When a proxy adds a Feature-Caps header field to a SIP response, it 527 MUST place the header field before any existing Feature-Caps header 528 field in the response. 530 5.3. SIP Message Type and Response Code Semantics 532 5.3.1. General 534 This section describes the general usage and semantics of the 535 Feature-Caps header field for different SIP message types and 536 response codes. The usage and semantics of a specific SIP feature 537 cap MUST be described in the associated SIP feature cap 538 specification. 540 NOTE: Future specifications can define usage and semantics of the 541 Feature-Caps header field for SIP methods, response codes and request 542 types not specified in this specification. 544 5.3.2. SIP Dialog 546 The Feature-Caps header field can be used within an initial SIP 547 request for a dialog, within a target refresh SIP request, and within 548 any 18x or 2xx response associated with such requests. 550 If a SIP feature cap is inserted in a Feature-Caps header field of an 551 initial request for a dialog, or within a response of such request, 552 it indicates to the receivers of the request (or response) that the 553 feature associated with the SIP feature cap is supported for the 554 duration of the dialog, until a target refresh request is sent for 555 the dialog, or the dialog is terminated. 557 Unless a SIP feature cap is inserted in a Feature-Caps header field 558 or a target refresh request, or within a response of such request, it 559 indicates to the receivers of the request (or response) that the 560 feature is no long supported for the dialog. 562 For a given dialog a SIP entity MUST insert the same SIP feature caps 563 in all 18x and 2xx responses associated with a given transaction. 565 5.3.3. SIP Registration (REGISTER) 567 The Feature-Caps header field can be used within a SIP REGISTER 568 request, and within the 200 (OK) response associated with such 569 request. 571 If a SIP feature cap is inserted in a Feature-Caps header field of a 572 SIP REGISTER request, or within a response of such request, it 573 indicates to the receivers of the request (or response) that the 574 feature associated with the SIP feature cap is supported for the 575 duration of the registration, and for all SIP transactions associated 576 with the registration, until the registration is re-freshed or 577 terminated. 579 Unless a SIP feature cap is inserted in a Feature-Caps header field 580 or a re-registration, or within a response of such request, it 581 indicates to the receivers of the request (or response) that the 582 feature is no long supported for the registration. 584 5.3.4. SIP Stand-Alone Transactions 586 The Feature-Caps header field can be used within a standalone SIP 587 request, and within any 18x or 2xx response associated with such 588 request. 590 If a SIP feature cap is inserted in a Feature-Caps header field of a 591 standalone request, or within a response of such request, it 592 indicates to the receivers of the request (or response) that the 593 feature associated with the SIP feature cap is supported for the 594 duration of the standalone transaction. 596 5.4. Syntax 598 5.4.1. ABNF 600 The ABNF for the Feature-Caps header fields is: 602 Feature-Caps = ("Feature-Caps" / "fc") HCOLON fc-value 603 *(COMMA fc-value) 604 fc-value = "*" *(SEMI feature-cap) 606 Figure 3: ABNF 608 NOTE: A "*" value means that no information regarding which SIP 609 entity, or domain, that indicate support of features is provided. 611 6. IANA Considerations 613 6.1. Registration of the Feature-Caps header field 615 This specification registers a new SIP header field, Feature-Caps, 616 according to the process of RFC 3261 [RFC3261]. 618 The following is the registration for the Feature-Caps header field: 620 RFC Number: RFC XXX 622 Header Field Name: Feature-Caps Header Field Name: Feature-Caps 624 Compact Form: fc 626 7. Security Considerations 628 SIP feature caps can provide sensitive information about a SIP 629 entity. RFC 3840 cautions against providing sensitive information to 630 another party. Once this information is given out, any use may be 631 made of it. 633 8. Acknowledgements 635 9. Change Log 637 [RFC EDITOR NOTE: Please remove this section when publishing] 639 Changes from draft-holmberg-sipcore-proxy-feature-04/ 640 draft-ietf-sipcore-proxy-feature-00 641 o Media feature tags replaced with SIP feature caps, based on 642 SIPCORE consensus at IETF#83 (Paris). 643 o Editorial corrections and modifications. 645 Changes from draft-holmberg-sipcore-proxy-feature-03 646 o Hadriel Kaplan added as co-author. 647 o Terminology change: instead of talking of proxies, talk about 648 entities which are not represented by the URI in a Contact header 649 field (http://www.ietf.org/mail-archive/web/sipcore/current/ 650 msg04449.html). 651 o Clarification regarding the usage of the header field in 18x/2xx 652 responses (http://www.ietf.org/mail-archive/web/sipcore/current/ 653 msg04449.html). 655 o Specifying that feature support can also be indicated in target 656 refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ 657 current/msg04454.html). 658 o Feature Cap specification registration information added. 660 Changes from draft-holmberg-sipcore-proxy-feature-02 661 o Definition, and usage of, a new header field, instead of Path, 662 Record-Route, Route and Service-Route. 664 Changes from draft-holmberg-sipcore-proxy-feature-01 665 o Requirement section added 666 o Use-cases and examples updated based on work in 3GPP 668 Changes from draft-holmberg-sipcore-proxy-feature-00 669 o Additional use-cases added 670 o Direction section added 672 10. References 674 10.1. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, March 1997. 679 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 680 A., Peterson, J., Sparks, R., Handley, M., and E. 681 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 682 June 2002. 684 10.2. Informative References 686 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 687 Registration Procedure", BCP 31, RFC 2506, March 1999. 689 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 690 "Indicating User Agent Capabilities in the Session 691 Initiation Protocol (SIP)", RFC 3840, August 2004. 693 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 694 Preferences for the Session Initiation Protocol (SIP)", 695 RFC 3841, August 2004. 697 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 698 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 699 May 2008. 701 [3GPP.23.237] 702 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 703 Stage 2", 3GPP TS 23.237 10.9.0, March 2012. 705 [3GPP.24.837] 706 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 707 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 708 10.0.0, April 2011. 710 Authors' Addresses 712 Christer Holmberg 713 Ericsson 714 Hirsalantie 11 715 Jorvas 02420 716 Finland 718 Email: christer.holmberg@ericsson.com 720 Ivo Sedlacek 721 Ericsson 722 Scheelevaegen 19C 723 Lund 22363 724 Sweden 726 Email: ivo.sedlacek@ericsson.com 728 Hadriel Kaplan 729 Acme Packet 730 71 Third Ave. 731 Burlington, MA 01803 732 USA 734 Email: hkaplan@acmepacket.com