idnits 2.17.1 draft-holmberg-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2011) is 4490 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: June 15, 2012 H. Kaplan 6 Acme Packet 7 December 13, 2011 9 Indication of features supported by proxy 10 draft-holmberg-sipcore-proxy-feature-04.txt 12 Abstract 14 This document defines a new SIP header field, Feature-Caps, that can 15 be used by SIP entities to indicate support of features and 16 capabilities, in cases where the Contact header field contains a URI 17 that does not represent the SIP entity that wants to indicate support 18 of its features and capabilities. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 15, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. User Agent (UA) Behavior . . . . . . . . . . . . . . . . . . . 3 58 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . . . 4 60 4.3. Registrar Behavior . . . . . . . . . . . . . . . . . . . . 4 61 5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Feature-Caps Header Field Definition . . . . . . . . . . . . . 5 63 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.3. SIP Registration (REGISTER) . . . . . . . . . . . . . . . 6 66 6.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . . . 6 67 6.5. SIP Capability Query (OPTIONS) . . . . . . . . . . . . . . 6 68 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8. Feature Tag Usage With Feature-Caps . . . . . . . . . . . . . 7 72 9. Feature Tag Requirements . . . . . . . . . . . . . . . . . . . 7 73 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9.2. Overall Description . . . . . . . . . . . . . . . . . . . 8 75 9.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 76 9.4. Feature Tag Name . . . . . . . . . . . . . . . . . . . . . 8 77 9.5. Feature Tag Values . . . . . . . . . . . . . . . . . . . . 8 78 9.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 8 79 9.7. Feature Tag Usage Restrictions . . . . . . . . . . . . . . 9 80 9.8. Feature Tag Security Considerations . . . . . . . . . . . 9 81 9.9. Implementation Details . . . . . . . . . . . . . . . . . . 9 82 9.10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 10.1. Registration of the Feature-Caps header field . . . . . . 10 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 87 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 14.1. Normative References . . . . . . . . . . . . . . . . . . . 11 90 14.2. Informative References . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Introduction 95 The Session Initiation Protocol (SIP) "Caller Preferences" extension, 96 defined in RFC 3840 [RFC3840], provides a mechanism that allows a SIP 97 message to convey information relating to the originator's features 98 and capabilities, using the Contact header field. 100 This document defines a new SIP header field, Feature-Caps, that can 101 be used by SIP entities to indicate support of features and 102 capabilities, in cases where the Contact header field contains a URI 103 that does not represent the SIP entity that wants to indicate support 104 of its features and capabilities. Such cases are: 106 o - The SIP entity acts as a SIP proxy. 107 o - The SIP entity acts as a SIP registrar. 108 o - The SIP entity acts as a B2BUA, where the Contact header field 109 URI represents another SIP entity. 111 2. Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in BCP 14, RFC 2119 116 [RFC2119]. 118 3. Definitions 120 Downstream SIP entity: SIP entity in the direction towards which a 121 SIP request is sent. 123 Upstream SIP entity: SIP entity in the direction from which a SIP 124 request is received. 126 4. User Agent (UA) Behavior 128 4.1. General 130 If the URI in a Contact header field of a request or response 131 represents a UA, the UA MUST NOT indicate supported features and 132 capabilities using a Feature-Caps header field within that request or 133 response. 135 When a UA receives a SIP request, or response, that contains one or 136 more Feature-Caps header fields, the Feature Tags in the header field 137 inform the UA is about the features supported by the entities that 138 inserted the header fields. Procedures how features are invoked are 139 outside the scope of this specification, and MUST be described by 140 individual Feature Tag specifications. 142 When the UA receives the SIP request or the response, the feature 143 tags in the topmost Feature-Caps header field will represent the 144 supported features "closest" to the UA. 146 4.2. B2BUA Behavior 148 The procedures in this section applies to UAs that are part of 149 B2BUAs, but where the URI in the Contact header field does not 150 represent the UA, because the B2BUA is also acting as a proxy and 151 inserts its URI e.g. in a Record-Route header field. 153 When a UA sends a SIP request, if the UA wants to indicate support of 154 features towards its downstream SIP entities, it adds a Feature-Caps 155 header field to the request, together with one or more Feature Tags 156 associated with the supported features, before it forwards the 157 request. 159 If the SIP request is triggered by another SIP request that the B2BUA 160 has received, the UA MAY forward those Feature-Caps header field by 161 copying them to the outgoing SIP request, similar to a SIP proxy, 162 before it adds its own Feature-Caps header field to the SIP request. 164 When a UA receives a SIP response, if the UA wants to indicate 165 support of features towards its upstream SIP entities, it adds a 166 Feature-Caps header field to the response, together with one or more 167 Feature Tags associated with the supported features, before it 168 forwards the response. 170 If the SIP response is triggered by another SIP response that the 171 B2BUA has received, the UA MAY forward those Feature-Caps header 172 field by copying them to the outgoing SIP response, similar to a SIP 173 proxy, before it adds its own Feature-Caps header field to the SIP 174 response. 176 4.3. Registrar Behavior 178 If a SIP registrar wants to indicate support of features towards its 179 upstream SIP entities, it can insert a Feature-Caps header field, 180 together with Feature Tags associated with the supported features, in 181 a REGISTER response. 183 5. Proxy behavior 185 When a proxy receives a SIP request, if the proxy wants to indicate 186 support of features towards its downstream SIP entities, it adds a 187 Feature-Caps header field to the request, together with one or more 188 Feature Tags associated with the supported features, before it 189 forwards the request. 191 When a proxy adds a Feature-Caps header field to a SIP request, it 192 MUST place the header field before any existing Feature-Caps header 193 field in the request. 195 When a proxy receives a SIP response, if the proxy wants to indicate 196 support of features towards its upstream SIP entities, it adds a 197 Feature-Caps header field to the response, together with one or more 198 Feature Tags associated with the supported features, before it 199 forwards the response. 201 When a proxy adds a Feature-Caps header field to a SIP response, it 202 MUST place the header field before any existing Feature-Caps header 203 field in the response. 205 6. Feature-Caps Header Field Definition 207 6.1. General 209 This section describes how the Feature-Caps header field is used, and 210 the associated semantics, with different SIP methods and response 211 codes. 213 NOTE: Future specification can define usage semantics of the Feature- 214 Caps header fields for SIP methods, response codes and request types 215 not specified in this specification. 217 6.2. SIP Dialog 219 The Feature-Caps header field can be used within an initial SIP 220 request for a dialog, within a target refresh SIP request, and within 221 any 18x or 2xx response associated with such requests. 223 If a Feature Tag is inserted in a Feature-Caps header field of such 224 request or such response, the feature associated with the Feature Tag 225 MUST be supported for the dialog, until the next time the dialog 226 target is refreshed, or the dialog is terminated. 228 For a given dialog the entity MUST use the same Feature-Caps header 229 field value (if included) in all 18x and 2xx responses for the same 230 transaction. 232 6.3. SIP Registration (REGISTER) 234 The Feature-Caps header field can be used within a SIP REGISTER 235 request, and within the 200 (OK) response of such request. 237 If a Feature Tag is inserted in a Feature-Caps header field of a SIP 238 REGISTER request or response, the feature associated with the Feature 239 Tag MUST be supported for the registration, and all SIP transactions 240 associated with the registration, until the registration is re- 241 freshed or terminated. 243 6.4. SIP Stand-Alone Transactions 245 The Feature-Caps header field can be used within an request for 246 standalone SIP transaction, and within any 18x or 2xx response 247 associated with such request. 249 If a Feature Tag is inserted in a Feature-Caps header field of an 250 request or response for a standalone transaction, the feature 251 associated with the Feature Tag MUST be supported for the duration of 252 the standalone transaction. 254 6.5. SIP Capability Query (OPTIONS) 256 7. Syntax 258 7.1. General 260 Each value of a Feature-Caps header field MUST contain a "*" value, 261 followed by one or more Feature Tags, associated with the supported 262 features, separated by semicolon (";"). 264 NOTE: A "*" value means that no information regarding which proxy, or 265 domain, that support the features associated with the Feature Tags, 266 is provided. 268 NOTE: When used in a Contact header field, a "*" value has an "any 269 URI" meaning. When used in a Feature-Caps header field, it simply 270 means that no URI information is provided. 272 7.2. ABNF 274 The ABNF for the Feature-Caps header fields is: 276 Feature-Caps = ("Feature-Caps" / "fc") HCOLON fc-value 277 *(COMMA fc-value) 278 fc-value = "*" *(SEMI feature-param) 279 ;;feature-param from RFC 3840 281 Figure 1: ABNF 283 8. Feature Tag Usage With Feature-Caps 285 Feature tags inserted in a Feature-Caps header field indicate that 286 the SIP entity that inserted the header field supports the associated 287 features. 289 In order to use a Feature Tag in a Feature-Caps header field, the 290 Feature Tag specification MUST specify the semantics of the feature 291 tag when inserted in the Feature-Caps header field. Unless the 292 feature specification defines such semantics, a the Feature Tag MUST 293 NOT be used in a Feature-Caps header field. 295 Within a given Feature-Caps header field, Feature Tags are listed in 296 a non-priority order, and for a given header field any order of 297 listed Feature Tags have the same meaning. For example, "foo;bar" 298 and "bar;foo" have the same meaning (i.e. that the entity that 299 inserted the Feature Tags supports the features associated with the 300 "foo" and "bar" Feature Tags. 302 9. Feature Tag Requirements 304 9.1. General 306 This section provides guidance on how to define an Feature Tag, and 307 what information needs to exist in an Feature Tag specification. 309 It is bad practice for Feature Tag specifications to repeat 310 procedures defined in this document, unless needed for clarification 311 or emphasis purpose. 313 Feature Tag specifications MUST NOT weaken any behavior designated 314 with "SHOULD" or "MUST" in this specification. However, Feature Tags 315 specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" 316 requirements to "MUST" strength if features associated with the 317 Feature Tag require it. 319 Feature Tag specifications MUST address the issues defined in the 320 following subsections, or document why an issue is not applicable for 321 the specific Feature Tag. 323 9.2. Overall Description 325 The Feature Tag specification MUST contain an overall description of 326 the Feature Tag: a description of the feature associated with the 327 Feature Tag, and a description what information is carried in 328 associated Feature Tag values (if any). 330 9.3. Applicability 332 The Feature Tag specification MUST describe why the support of the 333 feature can not be indicated in a SIP Contact header field [RFC3261], 334 using the mechanism defined in RFC 3840. The reason is either that 335 the entity inserting the Feature Tag is acting as a SIP proxy, or SIP 336 registrar, or a B2BUA but is not represented by the URI in the 337 Contact header field. 339 9.4. Feature Tag Name 341 The Feature Tag specification MUST define an Feature Tag name, which 342 entities use as a header field value to identify the Feature Tag in 343 the Feature-Caps header field. The Feature Tag name MUST conform to 344 the ABNF defined in Section 7.2. 346 9.5. Feature Tag Values 348 The Feature Tag specification MAY define Feature Tag values, 349 associated with the Feature Tag. A Feature Tag value MUST conform to 350 the ABNF defined in Section 7.2. 352 The Feature Tag specification MUST define the syntax and semantics of 353 the values associated with the Feature Tag. In addition, the 354 specification MUST define whether there are restrictions regarding 355 the usage of specific values. 357 Feature Tags can share value defined for other Feature Tags, but the 358 value is Feature Tag specific, and the value semantics MUST be 359 defined for each Feature Tag tag uses the value. 361 9.6. SIP Option Tags 363 The Feature Tag specification MAY define SIP option tags, which can 364 be used as describe in RFC 3261. 366 The registration requirements for option tags are defined in RFC 5727 367 [RFC5727]. 369 9.7. Feature Tag Usage Restrictions 371 If there are restrictions on how entities can insert a Feature Tag, 372 the Feature Tag specification MUST document such restrictions. 374 There can be restrictions related to whether entities are allowed to 375 insert Feature Tags in registration related messages, standalone 376 transaction messages, or dialog related messages, whether entities 377 are allowed to insert Feature Tags in requests or responses, whether 378 entities also need to support other features in order to insert a 379 Feature Tag, and whether entities are allowed to insert Feature Tags 380 togheter with other Feature Tags. 382 9.8. Feature Tag Security Considerations 384 If the information carried in a Feature Tag requires a certain level 385 of security, the Feature Tag specification MUST describe the 386 mechanisms that entities need to use in order to provide the required 387 security. 389 If the Feature Tag specification does not require any additional 390 security, other than what the underlying SIP protocol provides, this 391 MUST be stated in the Feature Tag specification. 393 9.9. Implementation Details 395 It is strongly RECOMMENDED that the Feature Tag specification defines 396 the procedure regarding how implementors shall implement and use the 397 Feature Tag, or refer to other locations where implementors can find 398 that information. 400 NOTE: Sometimes an Feature Tag designer might choose to not reveal 401 the details of an Feature Tag. However, in order to allow multiple 402 implementations to support the Feature Tag, Feature Tag designers are 403 strongly encouraged to provide the implementation details. 405 9.10. Examples 407 It is RECOMMENDED that the Feature Tag specification provide 408 demonstrative message flow diagrams, paired with complete messages 409 and message descriptions. 411 Note that example flows are by definition informative, and do not 412 replace normative text. 414 10. IANA Considerations 416 10.1. Registration of the Feature-Caps header field 418 This specification registers a new SIP header field, Feature-Caps, 419 according to the process of RFC 3261 [RFC3261]. 421 The following is the registration for the Feature-Caps header field: 423 RFC Number: RFC XXX 425 Header Field Name: Feature-Caps 427 Compact Form: fc 429 11. Security Considerations 431 Feature tags can provide sensitive information about a SIP entity. 432 RFC 3840 cautions against providing sensitive information to another 433 party. Once this information is given out, any use may be made of 434 it. 436 12. Acknowledgements 438 13. Change Log 440 [RFC EDITOR NOTE: Please remove this section when publishing] 442 Changes from draft-holmberg-sipcore-proxy-feature-03 443 o Hadriel Kaplan added as co-author. 444 o Terminology change: instead of talking of proxies, talk about 445 entities which are not represented by the URI in a Contact header 446 field (http://www.ietf.org/mail-archive/web/sipcore/current/ 447 msg04449.html). 448 o Clarification regarding the usage of the header field in 18x/2xx 449 responses (http://www.ietf.org/mail-archive/web/sipcore/current/ 450 msg04449.html). 451 o Specifying that feature support can also be indicated in target 452 refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ 453 current/msg04454.html). 454 o Feature Tag specification registration information added. 456 Changes from draft-holmberg-sipcore-proxy-feature-02 457 o Definition, and usage of, a new header field, instead of Path, 458 Record-Route, Route and Service-Route. 460 Changes from draft-holmberg-sipcore-proxy-feature-01 461 o Requirement section added 462 o Use-cases and examples updated based on work in 3GPP 464 Changes from draft-holmberg-sipcore-proxy-feature-00 465 o Additional use-cases added 466 o Direction section added 468 14. References 470 14.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 476 A., Peterson, J., Sparks, R., Handley, M., and E. 477 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 478 June 2002. 480 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 481 "Indicating User Agent Capabilities in the Session 482 Initiation Protocol (SIP)", RFC 3840, August 2004. 484 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 485 for the Session Initiation Protocol (SIP) and the Real- 486 time Applications and Infrastructure Area", BCP 67, 487 RFC 5727, March 2010. 489 14.2. Informative References 491 [3GPP.23.237] 492 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 493 Stage 2", 3GPP TS 23.237 10.7.0, September 2011. 495 [3GPP.24.837] 496 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 497 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 498 10.0.0, April 2011. 500 Authors' Addresses 502 Christer Holmberg 503 Ericsson 504 Hirsalantie 11 505 Jorvas 02420 506 Finland 508 Email: christer.holmberg@ericsson.com 510 Ivo Sedlacek 511 Ericsson 512 Scheelevaegen 19C 513 Lund 22363 514 Sweden 516 Email: ivo.sedlacek@ericsson.com 518 Hadriel Kaplan 519 Acme Packet 520 71 Third Ave. 521 Burlington, MA 01803 522 USA 524 Email: hkaplan@acmepacket.com