idnits 2.17.1 draft-ietf-cuss-sip-uui-17.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 (June 3, 2014) is 3608 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) == Missing Reference: 'RFCXXXX' is mentioned on line 581, but not defined ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-11) exists of draft-ietf-cuss-sip-uui-isdn-08 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Johnston 3 Internet-Draft Avaya 4 Intended status: Standards Track J. Rafferty 5 Expires: December 5, 2014 Human Communications 6 June 3, 2014 8 A Mechanism for Transporting User to User Call Control Information in 9 SIP 10 draft-ietf-cuss-sip-uui-17 12 Abstract 14 There is a class of applications which benefit from using SIP to 15 exchange User to User Information (UUI) data during session 16 establishment. This information, known as call control UUI data, is 17 a small piece of data inserted by an application initiating the 18 session, and utilized by an application accepting the session. The 19 syntax and semantics for the UUI data used by a specific application 20 are defined by a UUI package. This UUI data is opaque to SIP and its 21 function is unrelated to any basic SIP function. This document 22 defines a new SIP header field, User-to-User, to transport UUI data, 23 along with an extension mechanism. 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 December 5, 2014. 42 Copyright Notice 44 Copyright (c) 2014 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 4 62 4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 6 64 4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7 65 4.3. Source Identity of UUI data . . . . . . . . . . . . . . . 7 66 5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 9 67 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 6.1. Registration of User-to-User Header Field . . . . . . . . 11 70 6.2. Registration of User-to-User Header Field Parameters . . . 11 71 6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 12 72 6.4. Registration of UUI Content Parameters . . . . . . . . . . 12 73 6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12 74 6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 14 77 8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 14 78 8.2. Why Other Protocol Encapsulation UUI Mechanisms are 79 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 15 81 8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 16 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Overview 90 This document describes the transport of User to User Information 91 (UUI) data using SIP [RFC3261]. It defines a mechanism for the 92 transport of general application UUI data and for the transport of 93 call control related ITU-T Q.931 User to User Information Element (UU 94 IE) [Q931] and ITU-T Q.763 User to User Information Parameter [Q763] 95 data in SIP. UUI data is widely used in the PSTN today for contact 96 centers and call centers. There is also a trend for the related 97 applications to transition from ISDN to SIP. The UUI extension for 98 SIP may also be used for native SIP UAs implementing similar services 99 and to interwork with ISDN services. Note that in most cases, there 100 is an a priori understanding between the UAs in regard to what to do 101 with received UUI data. This document enables definition of packages 102 and related attributes that can make such understandings more 103 explicit. 105 The UUI mechanism is designed to meet the use cases, requirements, 106 and call flows for SIP call control UUI detailed in [RFC6567]. All 107 references to requirement numbers (REQ-N) and figure numbers refer to 108 [RFC6567]. 110 The mechanism is a new SIP header field, along with a new SIP option 111 tag. The header field carries the UUI data, along with parameters 112 indicating the encoding of the UUI data, the UUI package, and 113 optionally the content of the UUI data. The package definition 114 contains details about how a particular application can utilize the 115 UUI mechanism. The header field can be included (sometimes called 116 "escaped") into URIs supporting referral and redirection scenarios. 117 In these scenarios, the History-Info header field is used to indicate 118 the inserter of the UUI data. The SIP option tag can be used to 119 indicate support for the header field. Support for the UUI header 120 field indicates that a UA is able to extract the information in the 121 UUI data and pass it up the protocol stack. Individual packages 122 using the UUI mechanism can utilize SIP media feature tags to 123 indicate that a UA supports a particular UUI package. Guidelines for 124 defining UUI packages are provided. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14, RFC 2119 [RFC2119]. 133 Note that the tag convention from SIP Torture Test 134 Messages [RFC4475] is used to show that there are no line breaks in 135 the actual message syntax. 137 3. Requirements Discussion 139 This section describes how the User-to-User header field meets the 140 requirements in [RFC6567]. The header field can be included in 141 INVITE requests and responses and BYE requests and responses, meeting 142 REQ-1 and REQ-2. 144 For redirection and referral use cases and REQ-3, the header field is 145 included (escaped) within the Contact or Refer-To URI. The details 146 of this mechanism as it applies for redirection and referral use 147 cases are covered in Section 4.1. 149 Since SIP proxy forwarding and retargeting does not affect header 150 fields, the header field meets REQ-4. 152 The UUI header field will carry the UUI data and not a pointer to the 153 data, so REQ-5 is met. 155 Since the basic design of the UUI header field is similar to the ISDN 156 UUI service, interworking with PSTN protocols is straightforward and 157 is documented in a separate specification 158 [I-D.ietf-cuss-sip-uui-isdn], meeting REQ-6. 160 Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the 161 mechanism and supported packages, and hence applications. REQ-7 162 relates to support of the UUI header field, while REQ-8 relates to 163 routing based on support of the UUI header field. REQ-7 is met by 164 defining a new SIP option tag 'uui'. The use of a Require:uui in a 165 request, or Supported:uui in an OPTIONS response could be used to 166 require or discover support of the mechanism. The presence of a 167 Supported:uui or Require:uui header field can be used by proxies to 168 route to an appropriate UA, meeting REQ-8. However, note that only 169 UAs are expected to understand the UUI data - proxies and other 170 intermediaries do not. REQ-10 is met by utilizing SIP feature tags 171 [RFC3840]. For example, the feature tag 'sip.uui-isdn' could be used 172 to indicate support of the ISDN UUI package, or 'sip.uui-pk1' could 173 be used to indicate support for a particular package, pk1. 175 Proxies commonly apply policy to the presence of certain SIP header 176 fields in requests by either passing them or removing them from 177 requests. REQ-9 is met by allowing proxies and other intermediaries 178 to remove UUI header fields in a request or response based on policy. 180 Carrying UUI data elements of at least 129 octets is trivial in the 181 UUI header field, meeting REQ-11. Note that avoiding having very 182 large UUI data elements is a good idea, as SIP header fields have 183 traditionally not been large. 185 To meet REQ-12 for the redirection and referral use cases, the 186 History-Info header field [RFC7044] can be used. In these 187 retargeting cases, the changed Request-URI will be recorded in the 188 History-Info header field along with the identity of the element that 189 performed the retargeting. 191 The requirement for integrity protection in REQ-13 could be met by 192 the use of an S/MIME signature over a subset of header fields, as 193 defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity 194 using S/MIME: Tunneling SIP". Note that the lack of deployment of 195 S/MIME with SIP means that in general REQ-13 is not met. The 196 requirement of REQ-14 for end-to-end privacy could be met using 197 S/MIME or using encryption at the application layer. Note that the 198 use of S/MIME to secure the UUI data will result in an additional 199 body being added to the request. Hop-wise Transport Layer Security 200 (TLS) [RFC5246] allows the header field to meet REQ-15 for hop-by-hop 201 security. 203 4. Normative Definition 205 This document defines a new SIP header field "User-to-User" to 206 transport call control UUI data to meet the requirements in 207 [RFC6567]. 209 To help tag and identify the UUI data used with this header field, 210 "purpose", "content", and "encoding" header field parameters are 211 defined. The "purpose" header field parameter identifies the package 212 which defines the generation and usage of the UUI data for a 213 particular application. The value of the "purpose" parameter is the 214 package name, as registered in the uui-packages sub-registry defined 215 in Section 6.3. For the case of interworking with the ISDN UUI 216 Service, the ISDN UUI Service interworking package is used. The 217 default value for the "purpose" header field is "isdn-uui" as defined 218 in [I-D.ietf-cuss-sip-uui-isdn]. If the "purpose" header field 219 parameter is not present, the ISDN UUI MUST be used. The "content" 220 header field parameter identifies the actual content of the UUI data. 221 If not present, the default content defined for the package MUST be 222 used. Newly defined UUI packages MUST define or reference at least a 223 default "content" value. The "encoding" header field parameter 224 indicates the method of encoding the information in the UUI data 225 associated with a particular "content" value. This specification 226 only defines "encoding=hex". If the "encoding" header field 227 parameter is not present, the default encoding defined for the 228 package MUST be used. 230 UUI data is considered an opaque series of octets. This mechanism 231 MUST NOT be used to convey a URL or URI, since the Call-Info header 232 field in [RFC3261] already supports this use case. 234 4.1. Syntax for UUI Header Field 236 The User-to-User (UUI) header field can be present in INVITE requests 237 and responses and in BYE requests and responses. Note that when the 238 UUI header is used in responses, it can only be utilized in end-to- 239 end responses, e.g. 1xx (excluding 100), 2xx, and 3xx responses. 241 The following syntax specification uses the Augmented Backus-Naur 242 Form (ABNF) as described in RFC 5234 and extends RFC 3261 (where 243 token, quoted-string, and generic-param are defined). 245 UUI = "User-to-User" HCOLON uui-value *(COMMA uui-value) 246 uui-value = uui-data *(SEMI uui-param) 247 uui-data = token / quoted-string 248 uui-param = pkg-param / cont-param / enc-param / generic-param 249 pkg-param = "purpose" EQUAL pkg-param-value 250 pkg-param-value = token 251 cont-param = "content" EQUAL cont-param-value 252 cont-param-value = token 253 enc-param = "encoding" EQUAL enc-param-value 254 enc-param-value = token / "hex" 256 Each package defines how many User-to-User header fields of each 257 package may be present in a request or a response. A sender MAY 258 include multiple User-to-User header fields, and a receiver MUST be 259 prepared to receive multiple User-to-User header fields. Consistent 260 with the rules of SIP syntax, the syntax defined in this document 261 allows any combination of individual User-to-User header fields or 262 User-to-User header fields with multiple comma separated UUI data 263 elements. Any size limitations on the UUI data for a particular 264 purpose are to be defined by the related UUI package. 266 UAs SHALL ignore UUI data from packages or encoding that they do not 267 understand. 269 For redirection use cases, the header field is included (escaped) 270 within the Contact URI. For referral use cases, the header field is 271 included (escaped) within the Refer-To URI. For example, if a UA 272 supports this specification, it SHOULD include any UUI data included 273 in a redirection URI (if the UUI data and encoding is understood). 274 Note that redirection can occur multiple times to a request. 275 Currently, UAs that support attended transfer support the ability to 276 include a Replaces header field [RFC3891] into a Refer-To URI, and 277 when acting upon this URI, add the Replaces header field to the 278 triggered INVITE. This sort of logic and behavior is utilized for 279 the UUI header field (that is, the UUI header field is included in 280 the triggered INVITE). The UA processing the REFER [RFC3515] or the 281 3xx response to the INVITE SHOULD support the UUI mechanism. If the 282 REFER or redirect target does not support UUI, the UUI header will be 283 discarded as per [RFC3261]. However, this may limit the utility of 284 use cases which depend upon the UUI being supported by all elements. 286 Here is an example of an included User-to-User header field from the 287 redirection response F2 of Figure 2: 289 290 Contact: 293 295 The resulting INVITE F4 would contain: 297 User-to-User: 56a390f3d2b7310023a2;encoding=hex;purpose=foo;content=bar 299 4.2. Hex Encoding Definition 301 This specification defines hex encoding of UUI data. When the value 302 of 'hex' is used in the 'encoding' parameter of a header field, the 303 data is encoded using base16 encoding according to Section 8 of 304 [RFC4648]. The hex-encoded value is normally represented using the 305 'token' construction from RFC 3261, although the 'quoted-string' 306 construction is permitted, in which case the quotes MUST be ignored. 308 If a canonicalized version of a normally case-insensitive hex encoded 309 UUI data object is needed for a digital signature or integrity 310 checking, then the base16 encoding with all upper case MUST be used. 312 4.3. Source Identity of UUI data 314 It is important for the recipient of UUI data to know the identity of 315 the UA that inserted the UUI data. In a request without a History- 316 Info header field, the identity of the entity which inserted the UUI 317 data will be assumed to be the source of the SIP message. For a SIP 318 request, typically this is the UA identified by the URI in the From 319 header field or a P-Asserted-Identity [RFC3325] header field. In a 320 request with a History-Info header field, the recipient needs to 321 parse the Targeted-to-URIs present (hi-targeted-to-uri defined in 322 [RFC7044]) to see if any included User-to-User header fields are 323 present. If an included User-to-User header field is present and 324 matches the UUI data in the request, this indicates that redirection 325 has taken place, resulting in the inclusion of UUI data in the 326 request. The inserter of the UUI data will be the UA identified by 327 the Targeted-to-URI of the History-Info element prior to the element 328 with the included UUI data. In a response, the inserter of the UUI 329 data will be the identity of the UA that generated the response. 330 Typically, this is the UA identified in the To header field of the 331 response. Note that any updates to this identity by use of the SIP 332 Connected Identity extension [RFC4916] or others will update this 333 information. 335 For an example of History-Info and redirection, consider Figure 2 336 from [RFC6567] where the Originating UA is Carol, the Redirector Bob, 337 and the Terminating UA Alice. The INVITE F4 containing UUI data 338 could be: 340 INVITE sips:alice@example.com SIP/2.0 341 Via: SIP/2.0/TLS lab.example.com:5061 342 ;branch=z9hG4bKnashds9 343 To: Bob 344 From: Carol ;tag=323sf33k2 345 Call-ID: dfaosidfoiwe83ifkdf 346 Max-Forwards: 70 347 Contact: 348 Supported: histinfo 349 User-to-User: 342342ef34;encoding=hex 350 History-Info: ;index=1 351 352 History-Info: ;index=1.1;rc=1 354 356 Without the redirection captured in the History-Info header field, 357 Alice would conclude the UUI data was inserted by Carol. However, 358 the History-Info containing UUI data (index=1.1) indicates that the 359 inserter was Bob (index=1). 361 To enable maintaining a record of the inserter identity of UUI data, 362 UAs supporting this mechanism SHOULD support History-Info [RFC7044] 363 and include Supported: histinfo in all requests and responses. 365 If a border element such as a proxy or a Back-to-Back User Agent 366 (B2BUA) removes a History-Info header field containing a User-to-User 367 parameter, the UA consuming the UUI data may not be able at SIP level 368 to identify the source of the UUI data. 370 5. Guidelines for UUI Packages 372 UUI packages defined using this SIP UUI mechanism MUST follow the 373 "Standards Action" guideline as defined in [RFC5226] and publish a 374 standards track RFC which describes the usage. The WG chose to adopt 375 this conservative policy while it considers other potential 376 registration policies. Note that this mechanism is not suitable for 377 the transport of arbitrary data between UAs. The following 378 guidelines are provided to help determine if this mechanism is 379 appropriate or not. The SIP UUI mechanism is applicable when all of 380 the following conditions be met: 382 1. The information is generated and consumed by an application 383 during session setup using SIP, but the application is not 384 necessarily SIP aware. 386 2. The behavior of SIP entities that support it is not 387 significantly changed (as discussed in Section 4 of [RFC5727]). 389 3. User Agents (UAs) are the generators and consumers of the UUI 390 data. Proxies and other intermediaries may route based on the 391 presence of a User-to-User header field or a particular package 392 tag but do not otherwise consume or generate the UUI data. 394 4. There are no privacy issues associated with the information 395 being transported (e.g., geolocation or emergency-related 396 information are examples of inappropriate UUI data). 398 5. The UUI data is not being utilized for user-to-user Remote 399 Procedure Call (RPC) calls. 401 UUI packages define the semantics for a particular application usage 402 of UUI data. The content defines the syntax of the UUI data, while 403 the encoding defines the encoding of the UUI data for the content. 404 Each content is defined as a stream of octets, which allows multiple 405 encodings of that content. For example, packages may define: 407 1. The SIP methods and responses in which the UUI data may be 408 present. 410 2. The maximum number of UUI data elements that may be inserted 411 into a request or response. The default is one per encoding. 412 Note that a UA may still receive a request with more than this 413 maximum number due to redirection. The package needs to define 414 how to handle this situation. 416 3. The default values for content and encoding if they are not 417 present. If the same UUI data may be inserted multiple times with 418 different encodings, the package needs to state this. A package 419 may support and define multiple contents and their associated 420 encodings, and reuse contents defined by other packages. 422 4. Any size limitations on the UUI data. Size needs to be 423 specified in terms of the octet stream output of the content, 424 since the size of the resulting uui-data element will vary 425 depending on the encoding scheme. 427 A package MUST define a "purpose" header field value to identify the 428 package in the coding. A package MUST describe the new application 429 which is utilizing the UUI data and provide some use case examples. 430 The default "content" value MUST be defined or referenced in another 431 document for the package. Additional allowed contents MAY also be 432 defined or referenced. Any restrictions on the size of the UUI data 433 MUST be described. In addition, a package MAY define a Media Feature 434 tag per RFC 3840 [RFC3840] to indicate support for this UUI package. 435 For example, the media feature tag sip.uui-pk1 could be defined to 436 indicate support for a UUI package named pk1. The definition of a 437 new SIP option tag solely to identify support for a UUI package is 438 NOT RECOMMENDED unless there are additional SIP behaviors needed to 439 implement this feature. 441 For an example UUI package definition, see 442 [I-D.ietf-cuss-sip-uui-isdn]. 444 5.1. Extensibility 446 New "content" values MUST describe the semantics of the UUI data, 447 valid encodings, and give some example use cases. A previously 448 defined UUI content value can be used in a new package. In this 449 case, the semantics and usage of the content by the new package is 450 defined within the new package. New UUI content types cannot be 451 added to existing packages - instead, a new package would need to be 452 defined. New content values defined are added to the IANA registry 453 with a standards track RFC, which needs to discuss the issues in this 454 section. If no new encoding value is defined for a content, the 455 encoding defaults to "hex" as defined in this document. In this 456 case, the "hex" value will be explicitly stated via the encoding 457 parameter as the encoding for the content. 459 New "encoding" values associated with a new content MUST reference a 460 specific encoding scheme (such as "hex" which is defined in this 461 specification) or define the new encoding scheme. A previously 462 defined UUI encoding value can be used with a newly defined content. 463 In this case, the usage of the encoding is defined by the content 464 definition. New UUI encodings cannot be added to existing contents - 465 instead, a new content would need to be defined. Newly defined 466 encoding values are added to the IANA registry with a standards track 467 RFC, which needs to discuss the issues in this section. 469 6. IANA Considerations 471 6.1. Registration of User-to-User Header Field 473 This document defines a new SIP header field named "User-to-User". 475 The following row shall be added to the "Header Fields" section of 476 the SIP parameter registry: 478 +------------------+--------------+-----------+ 479 | Header Name | Compact Form | Reference | 480 +------------------+--------------+-----------+ 481 | User-to-User | | [RFCXXXX] | 482 +------------------+--------------+-----------+ 484 Editor's Note: [RFCXXXX] should be replaced with the designation of 485 this document. 487 6.2. Registration of User-to-User Header Field Parameters 489 This document defines the parameters for the header field defined in 490 the preceding section. The header field "User-to-User" can contain 491 the parameters "encoding", "content", and "purpose". 493 The following rows shall be added to the "Header Field Parameters and 494 Parameter Values" section of the SIP parameter registry: 496 +------------------+----------------+-------------------+-----------+ 497 | Header Field | Parameter Name | Predefined Values | Reference | 498 +------------------+----------------+-------------------+-----------+ 499 | User-to-User | encoding | yes | [RFCXXXX] | 500 +------------------+----------------+-------------------+-----------+ 501 | User-to-User | content | | [RFCXXXX] | 502 +------------------+----------------+-------------------+-----------+ 503 | User-to-User | purpose | | [RFCXXXX] | 504 +------------------+----------------+-------------------+-----------+ 506 Editor's Note: [RFCXXXX] should be replaced with the designation of 507 this document. 509 6.3. Registration of UUI Packages 511 This specification establishes the uui-packages sub-registry under 512 http://www.iana.org/assignments/sip-parameters. 514 The descriptive text for the table of uui-content is: 516 UUI Packages provides information about the usage of the UUI data in 517 a User-to-User header field [RFCXXXX]. 519 The registration policy for this registry is "Standards Action" as 520 defined in [RFC5226]. 522 +------------+------------------------------------------+-----------+ 523 | Package | Description | Reference | 524 +------------+------------------------------------------+-----------+ 526 6.4. Registration of UUI Content Parameters 528 This specification establishes the uui-content sub-registry under 529 http://www.iana.org/assignments/sip-parameters. 531 The descriptive text for the table of uui-content is: 533 UUI Content provides information about the content of the UUI data in 534 a User-to-User header field [RFCXXXX]. 536 The registration policy for this registry is "Standards Action" as 537 defined in [RFC5226]. 539 +------------+------------------------------------------+-----------+ 540 | Content | Description | Reference | 541 +------------+------------------------------------------+-----------+ 543 6.5. Registration of UUI Encoding Parameters 545 This specification establishes the uui-encoding sub-registry under 546 http://www.iana.org/assignments/sip-parameters and initiates its 547 population with the table below. 549 The descriptive text for the table of uui-encoding is: 551 UUI Encoding provides information about the encoding of the UUI data 552 in a User-to-User header field [RFCXXXX]. 554 The registration policy for this registry is "Standards Action" as 555 defined in [RFC5226]. 557 +-----------+-------------------------------------------+-----------+ 558 | Encoding | Description | Reference | 559 +-----------+-------------------------------------------+-----------+ 560 | hex | The UUI data is encoded using hexadecimal | [RFCXXXX] | 561 +-----------+-------------------------------------------+-----------+ 563 6.6. Registration of SIP Option Tag 565 This specification registers a new SIP option tag, as per the 566 guidelines in Section 27.1 of [RFC3261]. 568 This document defines the SIP option tag "uui". 570 The following row has been added to the "Option Tags" section of the 571 SIP Parameter Registry: 573 +------------+------------------------------------------+-----------+ 574 | Name | Description | Reference | 575 +------------+------------------------------------------+-----------+ 576 | uui | This option tag is used to indicate that | [RFCXXXX] | 577 | | a UA supports and understands the | | 578 | | User-to-User header field. | | 579 +------------+------------------------------------------+-----------+ 581 Editor's Note: [RFCXXXX] should be replaced with the designation of 582 this document. 584 7. Security Considerations 586 UUI data can potentially carry sensitive information that might 587 require confidentiality protection for privacy or integrity 588 protection from third parties that may wish to read or modify the UUI 589 data. [RFC6567] describes three security models which may be 590 applicable for the UUI mechanism. 592 One model treats the SIP layer as untrusted and requires end-to-end 593 integrity protection and/or encryption. This model can be achieved 594 by providing these security services at a layer above SIP. In this 595 case, applications are encouraged to use their own integrity and/or 596 encryption mechanisms before passing it to the SIP layer. 598 The second approach is for the application to pass the UUI without 599 any protection to the SIP layer and require the SIP layer to provide 600 this security. This approach is possible in theory, although its 601 practical use would be extremely limited. To preserve multi-hop or 602 end-to-end confidentiality and integrity of UUI data, approaches 603 using S/MIME or IPsec can be used, as discussed in the review of 604 REQ-13 and REQ-14 in section 3 of this document. However, the lack 605 of deployment of these mechanisms means that applications cannot in 606 general rely on them being present. 608 The third model utilizes a trust domain and relies on perimeter 609 security at the SIP layer. This is the security model of the PSTN 610 and ISDN where UUI is commonly used today. This approach uses hop- 611 by-hop security mechanisms and relies on border elements for 612 filtering and application of policy. Standard deployed SIP security 613 mechanisms such as TLS transport, offer privacy and integrity 614 protection properties on a hop-by-hop basis at the SIP layer. 616 If the UUI data was included by the UA originator of the SIP request 617 or response, normal SIP mechanisms can be used to determine the 618 identity of the inserter of the UUI data. If the UUI data was 619 included by a UA that was not the originator of the request, a 620 History-Info header field can be used to determine the identity of 621 the inserter of the UUI data. UAs can apply policy based on the 622 origin of the UUI data using this information. In short, the UUI 623 data included in an INVITE can be trusted as much as the INVITE 624 itself can be trusted. 626 Note that it is possible that this mechanism could be used as a 627 covert communication channel between UAs, conveying information 628 unknown to the SIP network. 630 8. Appendix - Other Possible Mechanisms 632 Two other possible mechanisms for transporting UUI data will be 633 described: MIME body and URI parameter transport. 635 8.1. Why INFO is Not Used 637 Since the INFO method [RFC6086], was developed for ISUP interworking 638 of user-to-user information, it might seem to be the logical choice 639 here. For non-call control user-to-user information, INFO can be 640 utilized for end to end transport. However, for transport of call 641 control user-to-user information, INFO can not be used. As the call 642 flows in [RFC6567] show, the information is related to an attempt to 643 establish a session and needs to be passed with the session setup 644 request (INVITE), responses to that INVITE, or session termination 645 requests. As a result, it is not possible to use INFO in these 646 cases. 648 8.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used 650 Other protocols have the ability to transport UUI data. For example, 651 consider the ITU-T Q.931 User to User Information Element (UU IE) 652 [Q931] and the ITU-T Q.763 User to User Information Parameter [Q763]. 653 In addition, NSS (Narrowband Signaling System) [Q1980] is also able 654 to transport UUI data. Should one of these protocols be in use, and 655 present in both User Agents, then utilizing these other protocols to 656 transport UUI data might be a logical solution. Essentially, this is 657 just adding an additional layer in the protocol stack. In these 658 cases, SIP is not transporting the UUI data; it is encapsulating 659 another protocol, and that protocol is transporting the UUI data. 660 Once a mechanism to transport that other protocol using SIP exists, 661 the UUI data transport function is essentially obtained without any 662 additional effort or work. 664 However, the CUSS working group believes, consistent with its 665 charter, that SIP needs to have its own native UUI data transport 666 mechanism. It is not reasonable for a SIP UA to have to implement 667 another entire protocol (either ISDN or NSS, for example) just to get 668 the very simple UUI data transport service. Of course, this work 669 does not preclude anyone from using other protocols with SIP to 670 transport UUI data. 672 8.3. MIME body Approach 674 One method of transport is to use a MIME body. This is in keeping 675 with the SIP-T architecture [RFC3372] in which MIME bodies are used 676 to transport ISUP information. Since the INVITE will normally have 677 an SDP message body, the resulting INVITE with SDP and UUI data will 678 be multipart MIME. This is not ideal as many SIP UAs do not support 679 multipart MIME INVITEs. 681 A bigger problem is the insertion of a UUI message body by a redirect 682 server or in a REFER. The body would need to be encoded in the 683 Contact URI of the 3xx response or the Refer-To URI of a REFER. 684 Currently, the authors are not aware of any UAs that support this 685 capability today for any body type. As such, the complete set of 686 semantics for this operation would need to be determined and defined. 687 Some issues will need to be resolved, such as, do all the Content-* 688 header fields have to be included as well? And, what if the included 689 Content-Length does not agree with the included body? 691 Since proxies cannot remove a body from a request or response, it is 692 not clear how this mechanism could meet REQ-9. 694 The requirement for integrity protection could be met by the use of 695 an S/MIME signature over the body, as defined in Section 23.3 of RFC 696 3261 "Securing MIME bodies". Alternatively, this could be achieved 697 using RFC 4474 [RFC4474]. The requirement for end-to-end privacy 698 could be met using S/MIME encryption or using encryption at the 699 application layer. However, note that neither S/MIME or RFC 4474 700 enjoys deployment in SIP today. 702 An example: 704 705 Contact: 707 709 As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5, 710 REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible, 711 although the authors do not have a specific mechanism to propose. 712 Meeting REQ-3 is problematic, but not impossible for this mechanism. 713 However, this mechanism does not seem to be able to meet REQ-9. 715 8.4. URI Parameter 717 Another proposed approach is to encode the UUI data as a URI 718 parameter. This UUI parameter could be included in a Request-URI or 719 in the Contact URI or Refer-To URI. It is not clear how it could be 720 transported in a responses which does not have a Request-URI, or in 721 BYE requests or responses. 723 724 Contact: 726 728 An INVITE sent to this Contact URI would contain UUI data in the 729 Request-URI of the INVITE. The URI parameter has a drawback in that 730 a URI parameter carried in a Request-URI will not survive retargeting 731 by a proxy as shown in Figure 2 of [RFC6567]. That is, if the URI is 732 included with an Address of Record instead of a Contact URI, the URI 733 parameter in the Reqeuest-URI will not be copied over to the Contact 734 URI, resulting in the loss of the information. Note that if this 735 same URI was present in a Refer-To header field, the same loss of 736 information would occur. 738 The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and 739 REQ-11. It is possible the approach could meet REQ-12 and REQ-13. 740 The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and 741 REQ-14. 743 9. Acknowledgements 745 Joanne McMillen was a major contributor and co-author of earlier 746 versions of this document. Thanks to Paul Kyzivat for his 747 contribution of hex encoding rules. Thanks to Spencer Dawkins, Keith 748 Drage, Vijay Gurbani, and Laura Liess for their review of the 749 document. The authors wish to thank Roland Jesske, Celine Serrut- 750 Valette, Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen 751 Jennings, and Mahalingam Mani for their comments. Thanks to Scott 752 Kelly and Joel Halperin for their reviews. 754 10. References 756 10.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, March 1997. 761 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 762 A., Peterson, J., Sparks, R., Handley, M., and E. 763 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 764 June 2002. 766 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 767 Authenticated Identity Management in the Session 768 Initiation Protocol (SIP)", RFC 4474, August 2006. 770 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 771 C. Holmberg, "An Extension to the Session Initiation 772 Protocol (SIP) for Request History Information", RFC 7044, 773 February 2014. 775 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 776 Protocol (SIP)", RFC 4916, June 2007. 778 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 779 "Indicating User Agent Capabilities in the Session 780 Initiation Protocol (SIP)", RFC 3840, August 2004. 782 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 783 Method", RFC 3515, April 2003. 785 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 786 Protocol (SIP) "Replaces" Header", RFC 3891, 787 September 2004. 789 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 790 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 792 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 793 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 794 May 2008. 796 [I-D.ietf-cuss-sip-uui-isdn] 797 Drage, K. and A. Johnston, "Interworking ISDN Call Control 798 User Information with SIP", 799 draft-ietf-cuss-sip-uui-isdn-08 (work in progress), 800 March 2014. 802 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 803 Encodings", RFC 4648, October 2006. 805 10.2. Informative References 807 [Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part 808 formats and codes", 809 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 811 [Q931] "ITU-T Q.931 User to User Information Element (UU IE)", 812 http://www.itu.int/rec/T-REC-Q.931-199805-I/en . 814 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 815 for Telephones (SIP-T): Context and Architectures", 816 BCP 63, RFC 3372, September 2002. 818 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 819 Initiation Protocol (SIP) INFO Method and Package 820 Framework", RFC 6086, January 2011. 822 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 823 and H. Schulzrinne, "Session Initiation Protocol (SIP) 824 Torture Test Messages", RFC 4475, May 2006. 826 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 827 for the Session Initiation Protocol (SIP) and the Real- 828 time Applications and Infrastructure Area", BCP 67, 829 RFC 5727, March 2010. 831 [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) - 832 Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/ 833 sg11aap/history/q1980.1/q1980.1.html . 835 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 836 Extensions to the Session Initiation Protocol (SIP) for 837 Asserted Identity within Trusted Networks", RFC 3325, 838 November 2002. 840 [RFC6567] Johnston, A. and L. Liess, "Problem Statement and 841 Requirements for Transporting User-to-User Call Control 842 Information in SIP", RFC 6567, April 2012. 844 Authors' Addresses 846 Alan Johnston 847 Avaya 848 St. Louis, MO 63124 850 Email: alan.b.johnston@gmail.com 852 James Rafferty 853 Human Communications 854 Norfolk, MA 02056 856 Email: jay@humancomm.com