idnits 2.17.1 draft-ietf-sipping-capacity-attribute-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 774. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1, 2008) is 5747 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 592, but not defined ** Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-06) exists of draft-ietf-sip-body-handling-02 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group M. Garcia-Martin 3 Internet-Draft G. Camarillo 4 Intended status: Standards Track Ericsson 5 Expires: February 2, 2009 August 1, 2008 7 Extensible Markup Language (XML) Format Extension for Representing Copy 8 Control Attributes in Resource Lists 9 draft-ietf-sipping-capacity-attribute-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 2, 2009. 36 Abstract 38 In certain types of multimedia communications, a Session Initiation 39 Protocol (SIP) request is distributed to a group of SIP User Agents 40 (UAs). The sender sends a single SIP request to a server which 41 further distributes the request to the group. This SIP request 42 contains a list of Uniform Resource Identifiers (URIs), which 43 identify the recipients of the SIP request. This URI-list is 44 expressed as a resource list XML document. This specification 45 defines an XML extension to the XML resource list format that allows 46 the sender of the request to qualify a recipient with a copy control 47 level similar to the copy control level of existing e-mail systems. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 54 4. Extension to the resource lists data format . . . . . . . . . 7 55 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 12 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 60 9.1. Disposition Type Registration . . . . . . . . . . . . . . 14 61 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 15 62 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 15 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 66 11.2. Informational References . . . . . . . . . . . . . . . . . 17 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 68 Intellectual Property and Copyright Statements . . . . . . . . . . 18 70 1. Introduction 72 The Framework and Security Considerations for Session Initiation 73 Protocol (SIP) URI-List Services [I-D.ietf-sipping-uri-services] 74 describes a generic framework for carrying Uniform Resource 75 Identifier (URI)-lists in SIP [RFC3261] messages. Specifically, the 76 document provides a common framework for specific implementations of 77 URI-list services, such as conferences initiated with INVITE requests 78 [I-D.ietf-sip-uri-list-conferencing] or Multiple-recipient MESSAGE 79 requests [I-D.ietf-sip-uri-list-message]. 81 Common to all URI-list services is the presence of a SIP request that 82 contains a collection of resources, typically expressed as an XML 83 resource list [RFC4826]. SIP requests carrying resource lists can 84 appear either in requests received by the URI-list server, indicating 85 the list of intended recipients, or in each of the requests that the 86 URI-list server sends to recipients, indicating the list of 87 recipients of the same SIP request. 89 Although the XML resource list [RFC4826] provides a powerful 90 mechanism for describing a list of resources, there is a need for a 91 copy control attribute to determine whether a resource is receiving a 92 SIP request as a primary recipient, a carbon copy, or a blind carbon 93 copy. This is similar to common e-mail systems, where the sender can 94 categorize each recipient as To, Cc, or Bcc recipient. 96 This document addresses this problem by providing an extension to the 97 XML resource list [RFC4826] that enables the sender to supply a copy 98 control attribute that labels each recipient as a "to", "cc", or 99 "bcc" recipient. This attribute indicates whether the recipient is 100 receiving a primary copy of the SIP request, a carbon copy, or a 101 blind carbon copy. Additionally, we provide the sender with the 102 capability of indicating in the URI-list that one or more resources 103 should be anonymized, so that some recipients' URIs are not disclosed 104 to the other recipients. Instead, these URIs are replaced with 105 anonymous URIs. 107 The remainder of this document is organized as follows: Section 2 108 introduces the terminology used throughout this specification. 109 Section 3 gives an overview of operation. Section 4 formally defines 110 an extension to URI-lists. The XML schema definition is provided in 111 Section 5. Section 6 shows examples of the URI-lists with the 112 extensions defined in this document. Section 7 discusses the 113 implications of carrying URI-lists in SIP messages. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in BCP 14, RFC 2119 120 [RFC2119] and indicate requirement levels for compliant 121 implementations. 123 URI-list service: SIP application service that receives a SIP 124 request containing a URI-list and sends a similar SIP request to 125 each URI in the list. 127 Intended recipient: The intended final recipient of the request to 128 be generated by URI-list service. 130 Copy control: An attribute assigned by the sender to a URI in a XML 131 resource list. Its purpose is to indicate to the recipient 132 whether he is getting a primary, carbon, or blind carbon copy of 133 the SIP request. 135 Recipient list or recipient XML resource list: An XML resource list 136 containing the list of intended recipients. The sender sets this 137 list in the SIP request he sends to the URI-list server. 139 Recipient-history list or recipient-history XML resource list: An 140 XML resource list containing the visible list of recipients (i.e., 141 those non-anonymous non-bcc). The URI-list server creates this 142 list, based on the recipient list, and includes it in each of the 143 SIP requests it sends to each recipient. 145 3. Overview of operation 147 Figure 1 depicts a general overview of the operation of a URI-list 148 server. A SIP User Agent Client (UAC) issuer sends a SIP request 149 (F1) to a URI-list server containing a recipient list. The URI-list 150 server generates a SIP request to each recipient, according to the 151 specific SIP method. Each of these SIP requests contains a 152 recipient-history list that indicates the visible list of recipients 153 of the SIP request. 155 +--------+ +---------+ +--------+ +--------+ +--------+ 156 |SIP UAC | | URI-list| |intended| |intended| |intended| 157 | issuer | | server | | recip. | | recip. | | recip. | 158 | | | | | 1 | | 2 | | 3 | 159 +--------+ +---------+ +--------+ +--------+ +--------+ 160 | | | | | 161 | F1. SIP request | | | | 162 | (recipt. list) | | | | 163 | ---------------->| | | | 164 | F2. 2xx response | | | | 165 |<---------------- | F3. SIP request | | | 166 | | (recp-hist.list)| | | 167 | | --------------->| | | 168 | | F4. SIP request | | | 169 | | (recp-hist.list)| | | 170 | | -------------------------->| | 171 | | F5. SIP request | | | 172 | | (recp-hist.list)| | | 173 | | ------------------------------------->| 174 | | F6. 200 OK | | | 175 | |<--------------- | | | 176 | | F7. 200 OK | | | 177 | |<-------------------------- | | 178 | | F8. 200 OK | | | 179 | |<------------------------------------- | 180 | | | | | 181 | | | | | 182 | | | | | 184 Figure 1: Example of operation 186 The URI-list mechanism allows a sender to specify multiple targets 187 for a SIP request by including a recipient XML resource list 188 [RFC4826] in the body of the SIP request. This recipient list 189 includes the target URIs of the SIP request (the actual procedures 190 are method specific and outside the scope of this document). Each 191 target URI may also be marked with a copy control attribute to 192 indicate the copy level in which the recipient is receiving the SIP 193 request. This is achieved by the sender qualifying each URI in the 194 URI-list with a 'copyControl' attribute. The available values of the 195 'copyControl' attribute include "to", "cc", and "bcc" (analogous to 196 e-mail). This is discussed in greater detailed in Section 4. When 197 the URI-list server expands the request to each recipient, the URI- 198 list server includes a recipient-history XML resource list built upon 199 the recipient list received from the sender. The recipient-history 200 XML resource list replaces the recipient list in the SIP requests 201 generated by the URI-list server towards each recipient. The URI- 202 list server copies from the recipient list those targets which are 203 marked with the "to" and "cc" copy control level, and pastes them in 204 the recipient-history list. The URI-list server explicitly excludes 205 from the recipient-history list those URIs marked with a "bcc" copy 206 control, although it is able to preserve the address of a "bcc" 207 tagged URI when it matches the URI of the recipient of the SIP 208 request (this is described later in Section 4). When a recipient 209 receives the SIP request containing the recipient-history XML 210 resource list, he is able to determine which other visible recipients 211 are getting a copy of the SIP request, and whether they are marked 212 with the "to" or "cc" copy control level. Later, if needed, the 213 recipient can generate a reply to those visible recipients. 215 In addition to the 'copyControl' attribute for a URI in an XML 216 resource list, we define a second boolean attribute called 217 'anonymize'. The sender of a SIP request can mark a URI in a 218 recipient XML resource list with the 'anonymize' attribute to 219 indicate the URI-list server that the URI marked with that attribute 220 is to be replaced with an anonymous URI in the recipient-history XML 221 resource list. This provides knowledge to the recipients of a SIP 222 request of the number of additional visible recipients whose URIs 223 have not been disclosed. 225 There are cases when the sender marks several URIs with the 226 'anonymize' attribute. The URI-list server can group the anonymized 227 URIs in a single anonymized URI within its copy control level, and 228 provide a count of the number of anonymized URIs. To support this 229 scenario, we define a new 'count' attribute to a URI in the 230 recipient-history XML resource list. It is expected that the 'count' 231 attribute is only used with anonymous URIs, although syntactically it 232 is possible to add a 'count' attribute to any URI in any XML resource 233 list. 235 Initially, it may be thought that the 'anonymize' attribute overlaps 236 with the "bcc" value of the 'copyControl' attribute. However, there 237 are differences between them. If the sender qualifies a URI with a 238 'copyControl' attribute of "bcc" in the recipient XML resource list, 239 the URI-list server will typically remove that URI from the 240 recipient-history XML resource list (unless the URI-list server 241 decides to preserve a "bcc" marked URI when that URI is itself the 242 recipient of the SIP request). Recipients of the SIP request will 243 not notice that one or more extra "bcc" URIs also received the 244 request. However, if the sender qualifies a URI with the 'anonymize' 245 attribute in the recipient XML resource list, the URI-list server 246 will replace the URI with an anonymous one in the recipient-history 247 list. Recipients of the SIP request will notice that there have been 248 one or more additional recipients of the same request, but their URIs 249 are not disclosed. 251 4. Extension to the resource lists data format 253 This document defines an extension to the XML resource list data 254 format [RFC4826] that allows the sender to indicate a copy control 255 attribute that qualifies a recipient with a copy control level. We 256 define a new 'copyControl' attribute to the element of the 257 resource list document format [RFC4826]. The 'copyControl' attribute 258 has similar semantics to the type of destination address in e-mail 259 systems. It can take the values "to", "cc", and "bcc". A "to" value 260 of the 'copyControl' attribute indicates that the resource is 261 considered a primary recipient of the SIP request. A "cc" value 262 indicates that the resource receives a carbon copy of the SIP 263 request. A "bcc" value indicates that the resource receives a blind 264 carbon copy of the SIP request (i.e., this URI is not disclosed to 265 other recipients of the SIP request). The default 'copyControl' 266 value is "bcc". That is, the absence of a 'copyControl' attribute 267 MUST be treated as if the 'copyControl' was set to "bcc". 269 When creating a recipient-history list, URI-list servers use "bcc" 270 'copyControl' attributes to route SIP requests. In addition, URI- 271 list servers behave similarly to e-mail systems [RFC2822] with 272 respect to the treatment of these URIs marked with a "bcc" copy 273 control, because they have two ways of treating "bcc" marked URIs. 274 URI-list servers MUST treat these "bcc" marked URIs in either of the 275 following two ways: 277 o URI-list servers MUST remove all URIs marked with a "bcc" copy 278 control in recipient-history lists. This mechanism allows URI- 279 list servers to send the same recipient-history list to each 280 recipient of the SIP request. However, recipients who are tagged 281 with "bcc" values are not explicitly informed about it. 282 o URI-list servers MUST preserve with a "bcc" copy control in the 283 recipient-history list the URI that identifies the recipient (if 284 any) and MUST remove the remaining URIs marked with a "bcc" copy 285 control. Consequently, each recipient receives a different 286 recipient-history list. However, recipients who have been marked 287 with a "bcc" copy control are explicitly informed about it. 289 Implementations that are able to receive recipient-history lists must 290 pay attention to the contents of the list. If the recipient's URI is 291 not included in recipient-history list or if it is included but 292 tagged with a "bcc" copy control, then implementations SHOULD prevent 293 the user from replying to all the recipients of the SIP request. 294 This would allow the non-blind recipients to notice the existence of 295 blind recipients of the SIP request. 297 A new 'anonymize' attribute can be included in a element of 298 the resource list document format [RFC4826]. If set to a "true" 299 value, it provides an indication to the URI-list server for not 300 disclosing the URI itself in a URI-list sent to the recipient, but 301 instead, to anonymize the URI (i.e., making it bogus in the 302 recipient-history XML resource list). URI-list servers can use URIs 303 tagged with the 'anonymize' attribute for routing SIP requests, but 304 MUST convert them the SIP URI "sip:anonymous@anonymous.invalid" in 305 recipient-history lists. The default value of the 'anonymize' 306 attribute is "false". 308 There are occasions where the URI-list server encounters the same URI 309 entry duplicated in a resource list, where duplicated URI entries are 310 tagged with the same or different values of the 'copyControl' 311 attribute. There are no reasonable usages that justify duplicated 312 URIs in resource lists, thus, this is considered an error. URI-list 313 servers should not send duplicated copies of the same SIP request to 314 the same intended recipient. In case the URI-list server encounters 315 the same URI entry duplicated in a resource list, it should send at 316 most a single copy of the request to that intended recipient. For 317 each set of duplicated URI entries, the URI-list server MUST select 318 the highest precedence value of the 'copyControl' attribute for the 319 same intended recipient. The order of precedence of the values of 320 the 'copyControl' attribute is: "to", "cc", and "bcc". Once the URI- 321 list server has selected a value for the 'copyControl' attribute of 322 an intended recipient, the URI-list can continue processing the 323 request. 325 Processing of URIs tagged with a 'copyControl' attribute set to a 326 "bcc" value has higher precedence over the 'anonymize' attribute. 327 Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list 328 server MUST remove that URI from the recipient-history list, and the 329 'anonymize' attribute will be ignored. Therefore, the 'anonymize' 330 attribute is only useful for those URIs tagged with a 'copyControl' 331 of "to" or "cc". 333 A new 'count' attribute can be also included in a element of 334 the resource list document format [RFC4826]. It provides the number 335 of equal URIs. Typically, recipient lists created by UACs will not 336 have equal (or duplicate) URI entries, thus, it is not expected to 337 contain URIs tagged with 'count' attributes. However, recipient- 338 history lists can contain duplicated anonymized URIs, therefore, it 339 is expected that recipient-history lists will contain 'count' 340 attributes. The default value of the 'count' attribute is "1". 342 The 'copyControl', 'anonymize', and 'count' attributes SHOULD be 343 included as modifiers of any of the child elements included in the 344 element of a resource list (e.g., attribute of the or 345 elements). 347 Section 5 describes the format of the 'copyControl', 'anonymize', and 348 'count' attributes. Implementations according to this specification 349 MUST support this XML Schema. 351 Implementations that receive recipient-history lists must pay 352 attention to the contents of the list. If the recipient's URI is not 353 included in recipient-history list or if it is included but tagged 354 with a "bcc" copy control, then they SHOULD prevent the user from 355 replying to all the recipients of the SIP request. This would allow 356 the non-blind recipients to notice the existence of blind recipients 357 in the original SIP request. 359 5. XML Schema 360 361 368 369 370 Adds the copyControl, anonymize, and count attributes 371 to URIs included in a resource list. 372 373 375 378 379 380 381 382 383 384 385 386 388 389 392 394 Figure 2: XML Schema of the extension to the resource list format 396 6. Examples 398 This section shows two examples of URI-lists that can be included in 399 SIP requests. The first example in Figure 3 shows a recipient list 400 that the UAC sends to the URI-list server. This corresponds to a 401 list that will be included in the flow F2 in Figure 1. The recipient 402 list contains a flat list according to the resource list data format 403 specified in RFC 4826 [RFC4826]. Each resource indicates the copy 404 control of a resource with a 'copyControl' attribute. Some of the 405 resources are also marked with the 'anonymize' attribute. This 406 provides an indication to the URI-list service for not disclosing 407 their URIs in a recipient-history list. The last two 408 elements are marked with a 'copyControl' attribute of "bcc". This 409 provides an indication to the URI-list server for removing these URIs 410 in the recipient-history list. 412 413 415 416 417 419 421 422 424 425 426 427 429 Figure 3: Recipient list sent from the UAC to the URI-list server 431 Upon receipt of the SIP request containing the recipient list of 432 Figure 3 the URI-list server creates a SIP request to each of the 433 URIs listed in the recipient list (so, in our example, it creates 7 434 SIP requests). The URI-list server processes the recipient list and 435 creates a recipient-history list that is included in each of the 436 outgoing SIP requests. The process is as follows: the URI-list 437 server creates a new recipient-history list, based on the recipient 438 list, but with changes. First it copies all the URIs ( 439 elements) marked with the "to" or "cc" 'copyControl' attributes, 440 which do not contain an 'anonymize' attribute (or when the 441 'anonymize' attribute is set to "false"). Then all the URIs marked 442 with a 'copyControl' attribute set to "to" and 'anonymize' attribute 443 set to "true" are replaced with the SIP anonymous URI 444 "sip:anonymous@anonymous.invalid". In this entry the URI-list server 445 also adds the original value of the 'copyControl' attribute ("to" in 446 our example), and it adds a 'count' attribute containing the number 447 of anonymous entries in this group ("2" in our example). Then the 448 URI-list server does the same operation to the URIs tagged with the 449 'copyControl' attribute set to "cc" and 'anonymize' attribute set to 450 "true", adding also the 'count' attribute containing the number of 451 anonymous attributes in this group ("1" in the example). Last, the 452 URI-list server removes all URIs marked with the "bcc" 'copyControl' 453 attribute. The resulting recipient-history list is shown in 454 Figure 4. 456 457 459 460 461 463 464 466 467 469 Figure 4: Recipient-history list sent from the URI-list server to 470 each recipient 472 7. Carrying URI-lists in SIP 474 A SIP UAC (User Agent Client) that composes a SIP request can include 475 a URI-list with the extensions specified in this document to indicate 476 the list of intended recipients. On doing so, as specified in the 477 Framework and Security Considerations for SIP URI-List Services 478 [I-D.ietf-sipping-uri-services], the UAC adds a Content-Disposition 479 [RFC2183] header field set to the value 'recipient-list'. Typically 480 UACs send these 'recipient-list' bodies to URI-list services (this 481 corresponds to flow F1 in Figure 1). A body whose Content- 482 Disposition type is 'recipient-list' contains a URI-list that 483 includes the intended recipients of the SIP request, something known 484 throughout this document as a recipient list. The element in 485 the URI-list MAY also include a 'copyControl' and 'anonymize' 486 attributes, as specified in Section 4. 488 To be able to inform intended recipients of who else is receiving a 489 copy of the SIP request, we define a new mail disposition type to be 490 included in a Content-Disposition [RFC2183] header field of a SIP 491 request. The value of this new disposition type is 'recipient-list- 492 history' and its purpose is to indicate a list of recipients that a 493 SIP request was sent to, something known throughout this document as 494 a recipient-history list. A body whose Content-Disposition type is 495 'recipient-list-history' contains a URI-list with the visible 496 (including anonymized) recipients of the SIP request. The 497 element in the URI-list MAY also include a 'copyControl' and 'count' 498 attributes, as specified in Section 4. 500 On sending a SIP request that contains a recipient-history list, if 501 the intended recipient does not support this specification, the SIP 502 request should not fail. In order to ensure successful receipt of 503 the SIP requests that include 'recipient-list-history' bodies, User 504 Agents (such as URI-list servers) that build SIP requests with the 505 Content-Disposition header field set to 'recipient-list-history' 506 SHOULD add a 'handling' parameter [RFC3204] set to "optional". 507 Otherwise, the SIP request could fail and never be received by the 508 intended recipient. 510 Even though Message Body Handling in SIP [I-D.ietf-sip-body-handling] 511 mandates support for multipart bodies, legacy recipients may not 512 support them. In such a case, if the request sent by the relay to 513 the recipient needs to contain another body (e.g., a MESSAGE request 514 carrying a message in its body), the relay will not be able to use 515 this extension because the recipient would not be able to process a 516 multipart body with the original body plus the 'recipient-list- 517 history' body. 519 8. Security Considerations 521 The Framework and Security Considerations for SIP URI-List Services 522 [I-D.ietf-sipping-uri-services] discusses issues related to SIP URI- 523 list services. Implementations of this specification MUST follow the 524 security-related rules in the Framework and Security Considerations 525 for SIP URI-List Services [I-D.ietf-sipping-uri-services]. These 526 rules include mandatory authentication and authorization of clients, 527 and opt-in lists. 529 User Agent Clients SHOULD NOT hand SIP requests containing URI-list 530 services to unauthenticated and untrusted parties. This is to avoid 531 man-in-the-middle attacks or acquiring URI-lists for performing SPAM 532 attacks. 534 URI-lists may contain private information, such as SIP URIs. It is 535 therefore not desirable that these URI-lists are known by third 536 parties. Eavesdroppers are able to watch URI-lists contained in SIP 537 requests unless the SIP message is sent over a secured channel, by 538 using any of the available SIP mechanisms, such as Transport Layer 539 Security (TLS) [RFC4346], or unless the URI-list body itself is 540 encrypted with, e.g., S/MIME [RFC3851]. Therefore, it is RECOMMENDED 541 that URI-list bodies are encrypted with S/MIME [RFC3851] or that the 542 SIP request is encrypted with TLS [RFC4346] or any other suitable 543 encryption mechanism. 545 Note that this URI-list does not indicate the actual participants in 546 the session. It indicates only the URIs invited and that might 547 accept the request. It does not assert that these parties actually 548 exist, that they are reachable at the given URI, or that they have 549 accepted the invitation. No inferences about billing should be made 550 from this information. It is subject to spoofing by loading the list 551 with falsified content. 553 Issuers of SIP request use the "bcc" copy control attribute described 554 in Section 4 to facilitate sending SIP requests to recipients without 555 revealing the URIs of one or more of the other recipients. 556 Mishandling this use of "bcc" copy control has implications for 557 confidential information that might be revealed, which could 558 eventually lead to security problems through knowledge of even the 559 existence of a particular URI. For example, if using the first 560 method described in Section 4, where the "bcc" tagged URIs are 561 removed from recipient-history list, blind recipients have no 562 explicit indication that they have been sent a blind copy of the SIP 563 request, except insofar as their URI does not appear in the 564 recipient-history list. Because of this, one of the blind URIs could 565 potentially send a reply to all of the shown recipients and 566 accidentally reveal that the message went to the blind recipient. 567 When the second method from Section 4 is used, the blind recipient's 568 address appears in the recipient-history list of a separate copy of 569 the list. If the "bcc" tagged URI sent contains all of the "bcc" 570 tagged URIs, all of the "bcc" recipients will be seen by each "bcc" 571 recipient. Even if a separate message is sent to each "bcc" 572 recipient with only the individual's URI, implementations still need 573 to be careful to process replies to the message as per Section 4 so 574 as not to accidentally reveal the blind recipient to other 575 recipients. 577 9. IANA Considerations 579 The following sections instruct the IANA to register: a new 580 disposition type, a new XML namespace, and a new XML schema. 582 9.1. Disposition Type Registration 584 Section 7 defines a new 'recipient-list-history' value of the Mail 585 Content Disposition Values registry. This value should be registered 586 in the IANA registry of Mail Content Disposition Values with the 587 following registration data: 589 +------------------------+------------------------------+-----------+ 590 | Name | Description | Reference | 591 +------------------------+------------------------------+-----------+ 592 | recipient-list-history | the body contains a list of | [RFCXXXX] | 593 | | URIs that indicates the | | 594 | | recipients of the SIP | | 595 | | request | | 596 +------------------------+------------------------------+-----------+ 597 Table 1: Registration of the 'recipient-list-history' Mail Content 598 Disposition Value 600 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 601 number of this specification. 603 9.2. XML Namespace Registration 605 This section registers a new XML namespace in the IANA XML registry, 606 as per the guidelines in RFC 3688 [RFC3688]. 608 URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol 610 Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), 611 Miguel Garcia-Martin (miguel.an.garcia@nokia.com). 613 XML: 615 BEGIN 616 617 619 620 621 623 Copy Control Namespace 624 625 626

Namespace for the Copy Control Attribute Extension 627 in Resource Lists

628

urn:ietf:params:xml:ns:copycontrol

629

See RFCXXXX 630 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with 631 the RFC number of this specification.].

632 633 634 END 636 9.3. XML Schema Registration 638 This section registers a new XML schema in the IANA XML registry per 639 the procedures in RFC 3688 [RFC3688]. 641 URI: urn:ietf:params:xml:schema:copycontrol 643 Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), 644 Miguel Garcia-Martin (miguel.an.garcia@nokia.com). 646 The XML for this schema can be found as the sole content of 647 Section 5. 649 10. Acknowledgements 651 Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, 652 Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, and Chris 653 Newman for reviewing this document and providing helpful comments. 655 11. References 657 11.1. Normative References 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 663 Presentation Information in Internet Messages: The 664 Content-Disposition Header Field", RFC 2183, August 1997. 666 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 667 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 668 and QSIG Objects", RFC 3204, December 2001. 670 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 671 A., Peterson, J., Sparks, R., Handley, M., and E. 672 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 673 June 2002. 675 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 676 January 2004. 678 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 679 Extensions (S/MIME) Version 3.1 Message Specification", 680 RFC 3851, July 2004. 682 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 683 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 685 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 686 for Representing Resource Lists", RFC 4826, May 2007. 688 [I-D.ietf-sipping-uri-services] 689 Camarillo, G. and A. Roach, "Framework and Security 690 Considerations for Session Initiation Protocol (SIP) 691 Uniform Resource Identifier (URI)-List Services", 692 draft-ietf-sipping-uri-services-07 (work in progress), 693 November 2007. 695 11.2. Informational References 697 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 698 April 2001. 700 [I-D.ietf-sip-uri-list-conferencing] 701 Camarillo, G. and A. Johnston, "Conference Establishment 702 Using Request-Contained Lists in the Session Initiation 703 Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-02 704 (work in progress), November 2007. 706 [I-D.ietf-sip-uri-list-message] 707 Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 708 MESSAGE Requests in the Session Initiation Protocol 709 (SIP)", draft-ietf-sip-uri-list-message-03 (work in 710 progress), December 2007. 712 [I-D.ietf-sip-body-handling] 713 Camarillo, G., "Message Body Handling in the Session 714 Initiation Protocol (SIP)", 715 draft-ietf-sip-body-handling-02 (work in progress), 716 May 2008. 718 Authors' Addresses 720 Miguel A. Garcia-Martin 721 Ericsson 722 Via de los Poblados 13 723 Madrid 28033 724 Spain 726 Email: miguel.a.garcia@ericsson.com 728 Gonzalo Camarillo 729 Ericsson 730 Hirsalantie 11 731 Jorvas 02420 732 Finland 734 Email: Gonzalo.Camarillo@ericsson.com 736 Full Copyright Statement 738 Copyright (C) The IETF Trust (2008). 740 This document is subject to the rights, licenses and restrictions 741 contained in BCP 78, and except as set forth therein, the authors 742 retain all their rights. 744 This document and the information contained herein are provided on an 745 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 746 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 747 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 748 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 749 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 750 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 752 Intellectual Property 754 The IETF takes no position regarding the validity or scope of any 755 Intellectual Property Rights or other rights that might be claimed to 756 pertain to the implementation or use of the technology described in 757 this document or the extent to which any license under such rights 758 might or might not be available; nor does it represent that it has 759 made any independent effort to identify any such rights. Information 760 on the procedures with respect to rights in RFC documents can be 761 found in BCP 78 and BCP 79. 763 Copies of IPR disclosures made to the IETF Secretariat and any 764 assurances of licenses to be made available, or the result of an 765 attempt made to obtain a general license or permission for the use of 766 such proprietary rights by implementers or users of this 767 specification can be obtained from the IETF on-line IPR repository at 768 http://www.ietf.org/ipr. 770 The IETF invites any interested party to bring to its attention any 771 copyrights, patents or patent applications, or other proprietary 772 rights that may cover technology that may be required to implement 773 this standard. Please address the information to the IETF at 774 ietf-ipr@ietf.org.