idnits 2.17.1 draft-ietf-sipping-capacity-attribute-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 714. 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 (December 18, 2007) is 5964 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 535, but not defined ** Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-02 == Outdated reference: A later version (-06) exists of draft-ietf-sip-body-handling-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Nokia Siemens Networks 4 Intended status: Standards Track G. Camarillo 5 Expires: June 20, 2008 Ericsson 6 December 18, 2007 8 Extensible Markup Language (XML) Format Extension for Representing Copy 9 Control Attributes in Resource Lists 10 draft-ietf-sipping-capacity-attribute-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 20, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 In certain types of multimedia communications, a Session Initiation 44 Protocol (SIP) request is distributed to a group of SIP User Agents 45 (UAs). The sender sends a single SIP request to a server which 46 further distributes the request to the group. This SIP request 47 contains a list of Uniform Resource Identifiers (URIs), which 48 identify the recipients of the SIP request. This URI-list is 49 expressed as a resource list XML document. This specification 50 defines an XML extension to the XML resource list format that allows 51 the sender of the request to qualify a recipient with a copy control 52 level similar to the copy control level of existing e-mail systems. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 59 4. Extension to the resource lists data format . . . . . . . . . 6 60 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 11 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 9.1. Disposition Type Registration . . . . . . . . . . . . . . 13 66 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13 67 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 11.2. Informational References . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 73 Intellectual Property and Copyright Statements . . . . . . . . . . 17 75 1. Introduction 77 The Framework and Security Considerations for Session Initiation 78 Protocol (SIP) URI-List Services [I-D.ietf-sipping-uri-services] 79 describes a generic framework for carrying Uniform Resource 80 Identifier (URI)-lists in SIP [RFC3261] messages. Specifically, the 81 document provides a common framework for specific implementations of 82 URI-list services, such as conferences initiated with INVITE requests 83 [I-D.ietf-sip-uri-list-conferencing] or Multiple-recipient MESSAGE 84 requests [I-D.ietf-sip-uri-list-message]. 86 Common to all URI-list services is the presence of a SIP request that 87 contains a collection of resources, typically expressed as an XML 88 resource list [RFC4826]. SIP requests carrying resource lists can 89 appear either in requests received by the URI-list server, indicating 90 the list of intended recipients, or in each of the requests that the 91 URI-list server sends to recipients, indicating the list of 92 recipients of the same SIP request. 94 Although the XML resource list [RFC4826] provides a powerful 95 mechanism for describing a list of resources, there is a need for a 96 copy control attribute to determine whether a resource is receiving a 97 SIP request as a primary recipient, a carbon copy, or a blind carbon 98 copy. This is similar to common e-mail systems, where the sender can 99 categorize each recipient as To, Cc, or Bcc recipient. 101 This document addresses this problem by providing an extension to the 102 XML resource list [RFC4826] that enables the sender to supply a copy 103 control attribute that labels each recipient as a "to", "cc", or 104 "bcc" recipient. This attribute indicates whether the recipient is 105 receiving a primary copy of the SIP request, a carbon copy, or a 106 blind carbon copy. Additionally, we provide the sender with the 107 capability of indicating in the URI-list that one or more resources 108 should be anonymized, so that some recipients' URIs are not disclosed 109 to the other recipients. Instead, these URIs are replaced with 110 anonymous URIs. 112 The remainder of this document is organized as follows: Section 2 113 introduces the terminology used throughout this specification. 114 Section 3 gives an overview of operation. Section 4 formally defines 115 an extension to URI-lists. The XML schema definition is provided in 116 Section 5. Section 6 shows examples of the URI-lists with the 117 extensions defined in this document. Section 7 discusses the 118 implications of carrying URI-lists in SIP messages. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in BCP 14, RFC 2119 125 [RFC2119] and indicate requirement levels for compliant 126 implementations. 128 URI-list service: SIP application service that receives a SIP 129 request containing a URI-list and sends a similar SIP request to 130 each URI in the list. 132 Intended recipient: The intended final recipient of the request to 133 be generated by URI-list service. 135 Copy control: An attribute assigned by the sender to a URI in a XML 136 resource list. Its purpose is to indicate to the recipient 137 whether he is getting a primary, carbon, or blind carbon copy of 138 the SIP request. 140 Recipient list or recipient XML resource list: An XML resource list 141 containing the list of intended recipients. The sender sets this 142 list in the SIP request he sends to the URI-list server. 144 Recipient-history list or recipient-history XML resource list: An 145 XML resource list containing the visible list of recipients (i.e., 146 those non-anonymous non-bcc). The URI-list server creates this 147 list, based on the recipient list, and includes it in each of the 148 SIP requests it sends to each recipient. 150 3. Overview of operation 152 Figure 1 depicts a general overview of the operation of a URI-list 153 server. A SIP User Agent Client (UAC) issuer sends a SIP request 154 (F1) to a URI-list server containing a recipient list. The URI-list 155 server generates a SIP request to each recipient, according to the 156 specific SIP method. Each of these SIP requests contains a 157 recipient-history list that indicates the visible list of recipients 158 of the SIP request. 160 +--------+ +---------+ +--------+ +--------+ +--------+ 161 |SIP UAC | | URI-list| |intended| |intended| |intended| 162 | issuer | | server | | recip. | | recip. | | recip. | 163 | | | | | 1 | | 2 | | 3 | 164 +--------+ +---------+ +--------+ +--------+ +--------+ 165 | | | | | 166 | F1. SIP request | | | | 167 | (recipt. list) | | | | 168 | ---------------->| | | | 169 | F2. 2xx response | | | | 170 |<---------------- | F3. SIP request | | | 171 | | (recp-hist.list)| | | 172 | | --------------->| | | 173 | | F4. SIP request | | | 174 | | (recp-hist.list)| | | 175 | | -------------------------->| | 176 | | F5. SIP request | | | 177 | | (recp-hist.list)| | | 178 | | ------------------------------------->| 179 | | F6. 200 OK | | | 180 | |<--------------- | | | 181 | | F7. 200 OK | | | 182 | |<-------------------------- | | 183 | | F8. 200 OK | | | 184 | |<------------------------------------- | 185 | | | | | 186 | | | | | 187 | | | | | 189 Figure 1: Example of operation 191 The URI-list mechanism allows a sender to specify multiple targets 192 for a SIP request by including a recipient XML resource list 193 [RFC4826] in the body of the SIP request. This recipient list 194 includes the target URIs of the SIP request (the actual procedures 195 are method specific and outside the scope of this document). Each 196 target URI may also be marked with a copy control attribute to 197 indicate the copy level in which the recipient is receiving the SIP 198 request. This is achieved by the sender qualifying each URI in the 199 URI-list with a 'copyControl' attribute. The available values of the 200 'copyControl' attribute include "to", "cc", and "bcc" (analogous to 201 e-mail). This is discussed in greater detailed in Section 4. When 202 the URI-list server expands the request to each recipient, the URI- 203 list server includes a recipient-history XML resource list built upon 204 the recipient list received from the sender. The recipient-history 205 XML resource list replaces the recipient list in the SIP requests 206 generated by the URI-list server towards each recipient. The URI- 207 list server copies from the recipient list those targets which are 208 marked with the "to" and "cc" copy control level, and pastes them in 209 the recipient-history list. The URI-list server explicitly excludes 210 from the copy those URIs marked with a "bcc" copy control. When a 211 recipient receives the SIP request containing the recipient-history 212 XML resource list, he is able to determine which other visible 213 recipients are getting the same SIP requests, and whether they are 214 marked with the "to" or "cc" copy control level. Later, if needed, 215 the recipient can generate a reply to those visible recipients. 217 In addition to the 'copyControl' attribute for a URI in an XML 218 resource list, we define a second boolean attribute called 219 'anonymize'. The sender of a SIP request can mark a URI in a 220 recipient XML resource list with the 'anonymize' attribute to 221 indicate the URI-list server that the URI marked with that attribute 222 is to be replaced with an anonymous URI in the recipient-history XML 223 resource list. This provides knowledge to the recipients of a SIP 224 request of the number of additional visible recipients whose URIs 225 have not been disclosed. 227 There are cases when the sender marks several URIs with the 228 'anonymize' attribute. The URI-list server can group the anonymized 229 URIs in a single anonymized URI within its copy control level, and 230 provide a count of the number of anonymized URIs. To support this 231 scenario, we define a new 'count' attribute to a URI in the 232 recipient-history XML resource list. It is expected that the 'count' 233 attribute is only used with anonymous URIs, although syntactically it 234 is possible to add a 'count' attribute to any URI in any XML resource 235 list. 237 Initially, it may be thought that the 'anonymize' attribute overlaps 238 with the "bcc" value of the 'copyControl' attribute. However, there 239 are differences between them. If the sender qualifies a URI with a 240 'copyControl' attribute of "bcc" in the recipient XML resource list, 241 the URI-list server will completely remove that URI from the 242 recipient-history XML resource list. Recipients of the SIP request 243 will not notice that one or more extra 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 have not been 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 in 265 the recipient-history list). The default 'copyControl' value is 266 "bcc". That is, the absence of a 'copyControl' attribute MUST be 267 treated as if the 'copyControl' was set to "bcc". URI-list servers 268 use URIs marked with the "bcc" 'copyControl' attribute to route SIP 269 requests, but MUST NOT include them in recipient-history lists. 271 A new 'anonymize' attribute can be included in a element of 272 the resource list document format [RFC4826]. If set to a "true" 273 value, it provides an indication to the URI-list server for not 274 disclosing the URI itself in a URI-list sent to the recipient, but 275 instead, to anonymize the URI (i.e., making it bogus in the 276 recipient-history XML resource list). URI-list servers can use URIs 277 tagged with the 'anonymize' attribute for routing SIP requests, but 278 MUST convert them the SIP URI "sip:anonymous@anonymous.invalid" in 279 recipient-history lists. The default value of the 'anonymize' 280 attribute is "false". 282 There are occasions where the URI-list server encounters the same URI 283 entry duplicated in a resource list, where duplicated URI entries are 284 tagged with the same or different values of the 'copyControl' 285 attribute. There are no reasonable usages that justify duplicated 286 URIs in resource lists, thus, this is considered an error. URI-list 287 servers should not send duplicated copies of the same SIP request to 288 the same intended recipient. In case the URI-list server encounters 289 the same URI entry duplicated in a resource list, it should send at 290 most a single copy of the request to that intended recipient. For 291 each set of duplicated URI entries, the URI-list server MUST select 292 the highest precedence value of the 'copyControl' attribute for the 293 same intended recipient. The order of precedence of the values of 294 the 'copyControl' attribute is: "to", "cc", and "bcc". Once the URI- 295 list server has selected a value for the 'copyControl' attribute of 296 an intended recipient, the URI-list can continue processing the 297 request. 299 Processing of URIs tagged with a 'copyControl' attribute set to a 300 "bcc" value has higher precedence over the 'anonymize' attribute. 301 Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list 302 server MUST remove that URI from the recipient-history list, and the 303 'anonymize' attribute will be ignored. Therefore, the 'anonymize' 304 attribute is only useful for those URIs tagged with a 'copyControl' 305 of "to" or "cc". 307 A new 'count' attribute can be also included in a element of 308 the resource list document format [RFC4826]. It provides the number 309 of equal URIs. Typically, recipient lists created by UACs will not 310 have equal (or duplicate) URI entries, thus, it is not expected to 311 contain URIs tagged with 'count' attributes. However, recipient- 312 history lists can contain duplicated anonymized URIs, therefore, it 313 is expected that recipient-history lists will contain 'count' 314 attributes. The default value of the 'count' attribute is "1". 316 The 'copyControl', 'anonymize', and 'count' attributes SHOULD be 317 included as modifiers of any of the child elements included in the 318 element of a resource list (e.g., attribute of the or 319 elements). 321 Section 5 describes the format of the 'copyControl', 'anonymize', and 322 'count' attributes. Implementations according to this specification 323 MUST support this XML Schema. 325 5. XML Schema 327 328 335 336 337 Adds the copyControl, anonymize, and count attributes 338 to URIs included in a resource list. 339 340 342 345 346 347 348 349 350 351 352 353 355 356 359 361 Figure 2: XML Schema of the extension to the resource list format 363 6. Examples 365 This section shows two examples of URI-lists that can be included in 366 SIP requests. The first example in Figure 3 shows a recipient list 367 that the UAC sends to the URI-list server. This corresponds to a 368 list that will be included in the flow F2 in Figure 1. The recipient 369 list contains a flat list according to the resource list data format 370 specified in RFC 4826 [RFC4826]. Each resource indicates the copy 371 control of a resource with a 'copyControl' attribute. Some of the 372 resources are also marked with the 'anonymize' attribute. This 373 provides an indication to the URI-list service for not disclosing 374 their URIs in a recipient-history list. The last two 375 elements are marked with a 'copyControl' attribute of "bcc". This 376 provides an indication to the URI-list server for removing these URIs 377 in the recipient-history list. 379 380 382 383 384 386 388 389 391 392 393 394 396 Figure 3: Recipient list sent from the UAC to the URI-list server 398 Upon receipt of the SIP request containing the recipient list of 399 Figure 3 the URI-list server creates a SIP request to each of the 400 URIs listed in the recipient list (so, in our example, it creates 7 401 SIP requests). The URI-list server processes the recipient list and 402 creates a recipient-history list that is included in each of the 403 outgoing SIP requests. The process is as follows: the URI-list 404 server creates a new recipient-history list, based on the recipient 405 list, but with changes. First it copies all the URIs ( 406 elements) marked with the "to" or "cc" 'copyControl' attributes, 407 which do not contain an 'anonymize' attribute (or when the 408 'anonymize' attribute is set to "false"). Then all the URIs marked 409 with a 'copyControl' attribute set to "to" and 'anonymize' attribute 410 set to "true" are replaced with the SIP anonymous URI 411 "sip:anonymous@anonymous.invalid". In this entry the URI-list server 412 also adds the original value of the 'copyControl' attribute ("to" in 413 our example), and it adds a 'count' attribute containing the number 414 of anonymous entries in this group ("2" in our example). Then the 415 URI-list server does the same operation to the URIs tagged with the 416 'copyControl' attribute set to "cc" and 'anonymize' attribute set to 417 "true", adding also the 'count' attribute containing the number of 418 anonymous attributes in this group ("1" in the example). Last, the 419 URI-list server completely removes URIs marked with the "bcc" 420 'copyControl' attribute. The resulting recipient-history list is 421 shown in Figure 4. 423 424 426 427 428 430 431 433 434 436 Figure 4: Recipient-history list sent from the URI-list server to 437 each recipient 439 7. Carrying URI-lists in SIP 441 A SIP UAC (User Agent Client) that composes a SIP request can include 442 a URI-list with the extensions specified in this document to indicate 443 the list of intended recipients. On doing so, as specified in the 444 Framework and Security Considerations for SIP URI-List Services 445 [I-D.ietf-sipping-uri-services], the UAC adds a Content-Disposition 446 [RFC2183] header field set to the value 'recipient-list'. Typically 447 UACs send these 'recipient-list' bodies to URI-list services (this 448 corresponds to flow F1 in Figure 1). A body whose Content- 449 Disposition type is 'recipient-list' contains a URI-list that 450 includes the intended recipients of the SIP request, something known 451 throughout this document as a recipient list. The element in 452 the URI-list MAY also include a 'copyControl' and 'anonymize' 453 attributes, as specified in Section 4. 455 To be able to inform intended recipients of who else is receiving a 456 copy of the SIP request, we define a new mail disposition type to be 457 included in a Content-Disposition [RFC2183] header field of a SIP 458 request. The value of this new disposition type is 'recipient-list- 459 history' and its purpose is to indicate a list of recipients that a 460 SIP request was sent to, something known throughout this document as 461 a recipient-history list. A body whose Content-Disposition type is 462 'recipient-list-history' contains a URI-list with the visible 463 (including anonymized) recipients of the SIP request. The 464 element in the URI-list MAY also include a 'copyControl' and 'count' 465 attributes, as specified in Section 4. 467 On sending a SIP request that contains a recipient-history list, if 468 the intended recipient does not support this specification, the SIP 469 request should not fail. In order to ensure successful receipt of 470 the SIP requests that include 'recipient-list-history' bodies, User 471 Agents (such as URI-list servers) that build SIP requests with the 472 Content-Disposition header field set to 'recipient-list-history' 473 SHOULD add a 'handling' parameter [RFC3204] set to "optional". 474 Otherwise, the SIP request could fail and never be received by the 475 intended recipient. 477 Even though Message Body Handling in SIP [I-D.ietf-sip-body-handling] 478 mandates support for multipart bodies, legacy recipients may not 479 support them. In such a case, if the request sent by the relay to 480 the recipient needs to contain another body (e.g., a MESSAGE request 481 carrying a message in its body), the relay will not be able to use 482 this extension because the recipient would not be able to process a 483 multipart body with the original body plus the 'recipient-list- 484 history' body. 486 8. Security Considerations 488 The Framework and Security Considerations for SIP URI-List Services 489 [I-D.ietf-sipping-uri-services] discusses issues related to SIP URI- 490 list services. Implementations of this specification MUST follow the 491 security-related rules in the Framework and Security Considerations 492 for SIP URI-List Services [I-D.ietf-sipping-uri-services]. These 493 rules include mandatory authentication and authorization of clients, 494 and opt-in lists. 496 User Agent Clients SHOULD NOT hand SIP requests containing URI-list 497 services to unauthenticated and untrusted parties. This is to avoid 498 man-in-the-middle attacks or acquiring URI-lists for performing SPAM 499 attacks. 501 URI-lists may contain private information, such as SIP URIs. It is 502 therefore not desirable that these URI-lists are known by third 503 parties. Eavesdroppers are able to watch URI-lists contained in SIP 504 requests unless the SIP message is sent over a secured channel, by 505 using any of the available SIP mechanisms, such as Transport Layer 506 Security (TLS) [RFC4346], or unless the URI-list body itself is 507 encrypted with, e.g., S/MIME [RFC3851]. Therefore, it is RECOMMENDED 508 that URI-list bodies are encrypted with S/MIME [RFC3851] or that the 509 SIP request is encrypted with TLS [RFC4346] or any other suitable 510 encryption mechanism. 512 Note that this URI-list does not indicate the actual participants in 513 the session. It indicates only the URIs invited and that might 514 accept the request. It does not assert that these parties actually 515 exist, that they are reachable at the given URI, or that they have 516 accepted the invitation. No inferences about billing should be made 517 from this information. It is subject to spoofing by loading the list 518 with falsified content. 520 9. IANA Considerations 522 The following sections instruct the IANA to register: a new 523 disposition type, a new XML namespace, and a new XML schema. 525 9.1. Disposition Type Registration 527 Section 7 defines a new 'recipient-list-history' value of the Mail 528 Content Disposition Values registry. This value should be registered 529 in the IANA registry of Mail Content Disposition Values with the 530 following registration data: 532 +------------------------+------------------------------+-----------+ 533 | Name | Description | Reference | 534 +------------------------+------------------------------+-----------+ 535 | recipient-list-history | the body contains a list of | [RFCXXXX] | 536 | | URIs that indicates the | | 537 | | recipients of the SIP | | 538 | | request | | 539 +------------------------+------------------------------+-----------+ 541 Table 1: Registration of the 'recipient-list-history' Mail Content 542 Disposition Value 544 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 545 number of this specification. 547 9.2. XML Namespace Registration 549 This section registers a new XML namespace in the IANA XML registry, 550 as per the guidelines in RFC 3688 [RFC3688]. 552 URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol 554 Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), 555 Miguel Garcia-Martin (miguel.an.garcia@nokia.com). 557 XML: 559 BEGIN 560 561 563 564 565 567 Copy Control Namespace 568 569 570

Namespace for the Copy Control Attribute Extension 571 in Resource Lists

572

urn:ietf:params:xml:ns:copycontrol

573

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

576 577 578 END 580 9.3. XML Schema Registration 582 This section registers a new XML schema in the IANA XML registry per 583 the procedures in RFC 3688 [RFC3688]. 585 URI: urn:ietf:params:xml:schema:copycontrol 587 Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), 588 Miguel Garcia-Martin (miguel.an.garcia@nokia.com). 590 The XML for this schema can be found as the sole content of 591 Section 5. 593 10. Acknowledgements 595 Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, 596 Brian Rosen, Mary Barnes, James Polk, and Brian E. Carpenter for 597 reviewing this document and providing helpful comments. 599 11. References 600 11.1. Normative References 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, March 1997. 605 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 606 Presentation Information in Internet Messages: The 607 Content-Disposition Header Field", RFC 2183, August 1997. 609 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 610 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 611 and QSIG Objects", RFC 3204, December 2001. 613 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 614 A., Peterson, J., Sparks, R., Handley, M., and E. 615 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 616 June 2002. 618 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 619 January 2004. 621 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 622 Extensions (S/MIME) Version 3.1 Message Specification", 623 RFC 3851, July 2004. 625 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 626 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 628 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 629 for Representing Resource Lists", RFC 4826, May 2007. 631 [I-D.ietf-sipping-uri-services] 632 Camarillo, G. and A. Roach, "Framework and Security 633 Considerations for Session Initiation Protocol (SIP) 634 Uniform Resource Identifier (URI)-List Services", 635 draft-ietf-sipping-uri-services-07 (work in progress), 636 November 2007. 638 11.2. Informational References 640 [I-D.ietf-sip-uri-list-conferencing] 641 Camarillo, G. and A. Johnston, "Conference Establishment 642 Using Request-Contained Lists in the Session Initiation 643 Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-02 644 (work in progress), November 2007. 646 [I-D.ietf-sip-uri-list-message] 647 Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 648 MESSAGE Requests in the Session Initiation Protocol 649 (SIP)", draft-ietf-sip-uri-list-message-02 (work in 650 progress), November 2007. 652 [I-D.ietf-sip-body-handling] 653 Camarillo, G., "Message Body Handling in the Session 654 Initiation Protocol (SIP)", 655 draft-ietf-sip-body-handling-00 (work in progress), 656 August 2007. 658 Authors' Addresses 660 Miguel A. Garcia-Martin 661 Nokia Siemens Networks 662 P.O.Box 6 663 Nokia Siemens Networks, FIN 02022 664 Finland 666 Email: miguel.garcia@nsn.com 668 Gonzalo Camarillo 669 Ericsson 670 Hirsalantie 11 671 Jorvas 02420 672 Finland 674 Email: Gonzalo.Camarillo@ericsson.com 676 Full Copyright Statement 678 Copyright (C) The IETF Trust (2007). 680 This document is subject to the rights, licenses and restrictions 681 contained in BCP 78, and except as set forth therein, the authors 682 retain all their rights. 684 This document and the information contained herein are provided on an 685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 687 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 688 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 689 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 692 Intellectual Property 694 The IETF takes no position regarding the validity or scope of any 695 Intellectual Property Rights or other rights that might be claimed to 696 pertain to the implementation or use of the technology described in 697 this document or the extent to which any license under such rights 698 might or might not be available; nor does it represent that it has 699 made any independent effort to identify any such rights. Information 700 on the procedures with respect to rights in RFC documents can be 701 found in BCP 78 and BCP 79. 703 Copies of IPR disclosures made to the IETF Secretariat and any 704 assurances of licenses to be made available, or the result of an 705 attempt made to obtain a general license or permission for the use of 706 such proprietary rights by implementers or users of this 707 specification can be obtained from the IETF on-line IPR repository at 708 http://www.ietf.org/ipr. 710 The IETF invites any interested party to bring to its attention any 711 copyrights, patents or patent applications, or other proprietary 712 rights that may cover technology that may be required to implement 713 this standard. Please address the information to the IETF at 714 ietf-ipr@ietf.org. 716 Acknowledgment 718 Funding for the RFC Editor function is provided by the IETF 719 Administrative Support Activity (IASA).