idnits 2.17.1 draft-ietf-sipping-capacity-attribute-04.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 666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 690. 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 (March 27, 2007) is 6232 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 519 ** Obsolete normative reference: RFC 4346 (ref. '6') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3851 (ref. '8') (Obsoleted by RFC 5751) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-06 == Outdated reference: A later version (-02) exists of draft-ietf-sip-uri-list-conferencing-01 == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-01 Summary: 3 errors (**), 0 flaws (~~), 4 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 Nokia 4 Intended status: Standards Track G. Camarillo 5 Expires: September 28, 2007 Ericsson 6 March 27, 2007 8 Extensible Markup Language (XML) Format Extension for Representing Copy 9 Control Attributes in Resource Lists 10 draft-ietf-sipping-capacity-attribute-04.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 September 28, 2007. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 12 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 [9] describes a generic framework 79 for carrying Uniform Resource Identifier (URI)-lists in SIP [4] 80 messages. Specifically, the document provides a common framework for 81 specific implementations of URI-list services, such as conferences 82 initiated with INVITE requests [10] or Multiple-recipient MESSAGE 83 requests [11]. 85 Common to all URI-list services is the presence of a SIP request that 86 contains a collection of resources, typically expressed as an XML 87 resource list [7]. SIP requests carrying resource lists can appear 88 either in requests received by the URI-list server, indicating the 89 list of intended recipients, or in each of the requests that the URI- 90 list server sends to recipients, indicating the list of recipients of 91 the same SIP request. 93 Although the XML resource list [7] provides a powerful mechanism for 94 describing a list of resources, there is a need for a copy control 95 attribute to determine whether a resource is receiving a SIP request 96 as a primary recipient, a carbon copy, or a blind carbon copy. This 97 is similar to common e-mail systems, where the sender can categorize 98 each recipient as To, Cc, or Bcc recipient. 100 This document addresses this problem by providing an extension to the 101 XML resource list [7] that enables the sender to supply a copy 102 control attribute that labels each recipient as a "to", "cc", or 103 "bcc" recipient. This attribute indicates whether the recipient is 104 receiving a primary copy of the SIP request, a carbon copy, or a 105 blind carbon copy. Additionally, we provide the sender with the 106 capability of indicating in the URI-list that one or more resources 107 should be anonymized, so that some recipients' URIs are not disclosed 108 to the other recipients. Instead, these URIs are replaced with 109 anonymous URIs. 111 The remainder of this document is organized as follows: Section 2 112 introduces the terminology used throughout this specification. 113 Section 3 gives an overview of operation. Section 4 formally defines 114 an extension to URI-lists. The XML schema definition is provided in 115 Section 5. Section 6 shows examples of the URI-lists with the 116 extensions defined in this document. Section 7 discusses the 117 implications of carrying URI-lists in SIP messages. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in BCP 14, RFC 2119 [1] 124 and indicate requirement levels for compliant implementations. 126 URI-list service: SIP application service that receives a SIP 127 request containing a URI-list and sends a similar SIP request to 128 each URI in the list. 130 Intended recipient: The intended final recipient of the request to 131 be generated by URI-list service. 133 Copy control: An attribute assigned by the sender to a URI in a XML 134 resource list. Its purpose is to indicate to the recipient 135 whether he is getting a primary, carbon, or blind carbon copy of 136 the SIP request. 138 Recipient list or recipient XML resource list: An XML resource list 139 containing the list of intended recipients. The sender sets this 140 list in the SIP request he sends to the URI-list server. 142 Recipient-history list or recipient-history XML resource list: An 143 XML resource list containing the visible list of recipients (i.e., 144 those non-anonymous non-bcc). The URI-list server creates this 145 list, based on the recipient list, and includes it in each of the 146 SIP requests it sends to each recipient. 148 3. Overview of operation 150 Figure 1 depicts a general overview of the operation of a URI-list 151 server. A SIP User Agent Client (UAC) issuer sends a SIP request 152 (F1) to a URI-list server containing a recipient list. The URI-list 153 server generates a SIP request to each recipient, according to the 154 specific SIP method. Each of these SIP requests contains a 155 recipient-history list that indicates the visible list of recipients 156 of the SIP request. 158 +--------+ +---------+ +--------+ +--------+ +--------+ 159 |SIP UAC | | URI-list| |intended| |intended| |intended| 160 | issuer | | server | | recip. | | recip. | | recip. | 161 | | | | | 1 | | 2 | | 3 | 162 +--------+ +---------+ +--------+ +--------+ +--------+ 163 | | | | | 164 | F1. SIP request | | | | 165 | (recipt. list) | | | | 166 | ---------------->| | | | 167 | F2. 2xx response | | | | 168 |<---------------- | F3. SIP request | | | 169 | | (recp-hist.list)| | | 170 | | --------------->| | | 171 | | F4. SIP request | | | 172 | | (recp-hist.list)| | | 173 | | -------------------------->| | 174 | | F5. SIP request | | | 175 | | (recp-hist.list)| | | 176 | | ------------------------------------->| 177 | | F6. 200 OK | | | 178 | |<--------------- | | | 179 | | F7. 200 OK | | | 180 | |<-------------------------- | | 181 | | F8. 200 OK | | | 182 | |<------------------------------------- | 183 | | | | | 184 | | | | | 185 | | | | | 187 Figure 1: Example of operation 189 The URI-list mechanism allows a sender to specify multiple targets 190 for a SIP request by including a recipient XML resource list [7] in 191 the body of the SIP request. This recipient list includes the target 192 URIs of the SIP request (the actual procedures are method specific 193 and outside the scope of this document). Each target URI may also be 194 marked with a copy control attribute to indicate the copy level in 195 which the recipient is receiving the SIP request. This is achieved 196 by the sender qualifying each URI in the URI-list with a 197 'copyControl' attribute. The available values of the 'copyControl' 198 attribute include "to", "cc", and "bcc" (analogous to e-mail). This 199 is discussed in greater detailed in Section 4. When the URI-list 200 server expands the request to each recipient, the URI-list server 201 includes a recipient-history XML resource list built upon the 202 recipient list received from the sender. The recipient-history XML 203 resource list replaces the recipient list in the SIP requests 204 generated by the URI-list server towards each recipient. The URI- 205 list server copies from the recipient list those targets which are 206 marked with the "to" and "cc" copy control level, and pastes them in 207 the recipient-history list. The URI-list server explicitly excludes 208 from the copy those URIs marked with a "bcc" copy control. When a 209 recipient receives the SIP request containing the recipient-history 210 XML resource list, he is able to determine which other visible 211 recipients are getting the same SIP requests, and whether they are 212 marked with the "to" or "cc" copy control level. Later, if needed, 213 the 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 a knowledge to recipients of a SIP 222 request of a number of additional recipients whose URIs have not been 223 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 completely remove that URI from the 240 recipient-history XML resource list. Recipients of the SIP request 241 will not notice that one or more extra URIs also received the 242 request. However, if the sender qualifies a URI with the 'anonymize' 243 attribute in the recipient XML resource list, the URI-list server 244 will replace the URI with an anonymous one in the recipient-history 245 list. Recipients of the SIP request will notice that there have been 246 one or more additional recipients of the same request, but their URIs 247 have not been disclosed. 249 4. Extension to the resource lists data format 251 This document defines an extension to the XML resource list data 252 format [7] that allows the sender to indicate a copy control 253 attribute that qualifies a recipient with a copy control level. We 254 define a new 'copyControl' attribute to the element of the 255 resource list document format [7]. The 'copyControl' attribute has 256 similar semantics to the type of destination address in e-mail 257 systems. It can take the values "to", "cc", and "bcc". A "to" value 258 of the 'copyControl' attribute indicates that the resource is 259 considered a primary recipient of the SIP request. A "cc" value 260 indicates that the resource receives a carbon copy of the SIP 261 request. A "bcc" value indicates that the resource receives a blind 262 carbon copy of the SIP request (i.e., this URI is not disclosed in 263 the recipient-history list). The default 'copyControl' value is 264 "bcc". That is, the absence of a 'copyControl' attribute MUST be 265 treated as if the 'copyControl' was set to "bcc". URI-list servers 266 use URIs marked with the "bcc" 'copyControl' attribute to route SIP 267 requests, but MUST NOT include them in recipient-history lists. 269 A new 'anonymize' attribute can be included in a element of 270 the resource list document format [7]. If set to a "true" value, it 271 provides an indication to the URI-list server for not disclosing the 272 URI itself in a URI-list sent to the recipient, but instead, to 273 anonymize the URI (i.e., making it bogus in the recipient-history XML 274 resource list). URI-list servers can use URIs tagged with the 275 'anonymize' attribute for routing SIP requests, but MUST convert them 276 to an anonymized URI (such as sip:anonymous@anonymous.invalid) in 277 recipient-history lists. The default value of the 'anonymize' 278 attribute is "false". 280 There are occasions where the URI-list server encounters the same URI 281 entry duplicated in a resource list, where duplicated URI entries are 282 tagged with the same or different values of the 'copyControl' 283 attribute. There are no reasonable usages that justify duplicated 284 URIs in resource lists, thus, this is considered an error. URI-list 285 servers MUST NOT send duplicated copies of the same SIP request to 286 the same intended recipient. In case the URI-list server encounters 287 the same URI entry in a resource list, it MUST send at most a single 288 copy of the request to that intended recipient. The URI-list server 289 MUST select the highest precedence value of the 'copyControl' 290 attribute of the duplicated entries for the same intended recipient. 291 The order of precedence of the values of the 'copyControl' attribute 292 is: "to", "cc", and "bcc". Once the URI-list server has selected a 293 value for the 'copyControl' attribute of an intended recipient, the 294 URI-list can continue processing the request. 296 Processing of URIs tagged with a 'copyControl' attribute set to a 297 "bcc" value has higher precedence over the 'anonymize' attribute. 298 Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list 299 server MUST remove that URI from the recipient-history list, and the 300 'anonymize' attribute will be ignored. Therefore, the 'anonymize' 301 attribute is only useful for those URIs tagged with a 'copyControl' 302 of "to" or "cc". 304 A new 'count' attribute can be also included in a element of 305 the resource list document format [7]. It provides the number of 306 equal URIs. Typically, recipient lists created by UACs will not have 307 equal (or duplicate) URI entries, thus, it is not expected to contain 308 URIs tagged with 'count' attributes. However, recipient-history 309 lists can contain duplicated anonymized URIs, therefore, it is 310 expected that recipient-history lists will contain 'count' 311 attributes. The default value of the 'count' attribute is "1". 313 The 'copyControl', 'anonymize', and 'count' attributes SHOULD be 314 included as modifiers of any of the child elements included in the 315 element of a resource list (e.g., attribute of the or 316 elements). 318 Section 5 describes the format of the 'copyControl', 'anonymize', and 319 'count' attributes. Implementations according to this specification 320 MUST support this XML Schema. 322 5. XML Schema 324 325 332 333 334 Adds the copyControl, anonymize, and count attributes 335 to URIs included in a resource list. 336 337 339 342 343 344 345 346 347 348 349 350 352 353 356 358 Figure 2: XML Schema of the extension to the resource list format 360 6. Examples 362 This section shows two examples of URI-lists that can be included in 363 SIP requests. The first example in Figure 3 shows a recipient list 364 that the UAC sends to the URI-list server. This corresponds to a 365 list that will be included in the flow F2 in Figure 1. The recipient 366 list contains a flat list according to the resource list data format 367 [7]. Each resource indicates the copy control of a resource with a 368 'copyControl' attribute. Some of the resources are also marked with 369 the 'anonymize' attribute. This provides an indication to the URI- 370 list service for not disclosing their URIs in a recipient-history 371 list. The last two elements are marked with a 'copyControl' 372 attribute of "bcc". This provides an indication to the URI-list 373 server for removing these URIs in the recipient-history list. 375 376 378 379 380 382 384 385 387 388 389 390 392 Figure 3: Recipient list sent from the UAC to the URI-list server 394 Upon receipt of the SIP request containing the recipient list of 395 Figure 3 the URI-list server creates a SIP request to each of the 396 URIs listed in the recipient list (so, in our example, it creates 7 397 SIP requests). The URI-list server processes the recipient list and 398 creates a recipient-history list that is included in each of the 399 outgoing SIP requests. The process is as follows: the URI-list 400 server creates a new recipient-history list, based on the recipient 401 list, but with changes. First it copies all the URIs ( 402 elements) marked with the "to" or "cc" 'copyControl' attributes, 403 which do not contain an 'anonymize' attribute (or when the 404 'anonymize' attribute is set to "false"). Then all the URIs marked 405 with a 'copyControl' attribute set to "to" and 'anonymize' attribute 406 set to "true" are replaced with an anonymous URI, such as 407 "sip:anonymous@anonymous.invalid". In this entry the URI-list server 408 also adds the original value of the 'copyControl' attribute ("to" in 409 our example), and it adds a 'count' attribute containing the number 410 of anonymous entries in this group ("2" in our example). Then the 411 URI-list server does the same operation to the URIs tagged with the 412 'copyControl' attribute set to "cc" and 'anonymize' attribute set to 413 "true", adding also the 'count' attribute containing the number of 414 anonymous attributes in this group ("1" in the example). Last, the 415 URI-list server completely removes URIs marked with the "bcc" 416 'copyControl' attribute. The resulting recipient-history list is 417 shown in Figure 4. 419 420 422 423 424 426 427 429 430 432 Figure 4: Recipient-history list sent from the URI-list server to 433 each recipient 435 7. Carrying URI-lists in SIP 437 A SIP UAC (User Agent Client) that composes a SIP request can include 438 a URI-list with the extensions specified in this document to indicate 439 the list of intended recipients. On doing so, as specified in the 440 Framework and Security Considerations for SIP URI-List Services [9], 441 the UAC adds a Content-Disposition [2] header field set to the value 442 'recipient-list'. Typically UACs send these 'recipient-list' bodies 443 to URI-list services (this corresponds to flow F1 in Figure 1). A 444 body whose Content-Disposition type is 'recipient-list' contains a 445 URI-list that includes the intended recipients of the SIP request, 446 something known throughout this document as a recipient list. The 447 element in the URI-list MAY also include a 'copyControl' and 448 'anonymize' attributes, as specified in Section 4. 450 To be able to inform intended recipients of who else is receiving a 451 copy of the SIP request, we define a new mail disposition type to be 452 included in a Content-Disposition [2] header field of a SIP request. 453 The value of this new disposition type is 'recipient-list-history' 454 and its purpose is to indicate a list of recipients that a SIP 455 request was sent to, something known throughout this document as a 456 recipient-history list. A body whose Content-Disposition type is 457 'recipient-list-history' contains a URI-list with the visible 458 (including anonymized) recipients of the SIP request. The 459 element in the URI-list MAY also include a 'copyControl' and 'count' 460 attributes, as specified in Section 4. 462 On sending a SIP request that contains a recipient-history list, if 463 the intended recipient does not support this specification, the SIP 464 request should not fail. In order to ensure successful receipt of 465 the SIP requests that include 'recipient-list-history' bodies, User 466 Agents (such as URI-list servers) that build SIP requests with the 467 Content-Disposition header field set to 'recipient-list-history' 468 SHOULD add a 'handling' parameter [3] set to "optional". Otherwise, 469 the SIP request could fail and never be received by the intended 470 recipient. 472 8. Security Considerations 474 The Framework and Security Considerations for SIP URI-List Services 475 [9] discusses issues related to SIP URI-list services. 476 Implementations of this specification MUST follow the security- 477 related rules in the Framework and Security Considerations for SIP 478 URI-List Services [9]. These rules include mandatory authentication 479 and authorization of clients, and opt-in lists. 481 User Agent Clients SHOULD NOT hand SIP requests containing URI-list 482 services to unauthenticated and untrusted parties. This is to avoid 483 man-in-the-middle attacks or acquiring URI-lists for performing SPAM 484 attacks. 486 URI-lists may contain private information, such as SIP URIs. It is 487 therefore not desirable that these URI-lists are known by third 488 parties. Eavesdroppers are able to watch URI-lists contained in SIP 489 requests unless the SIP message is sent over a secured channel, by 490 using any of the available SIP mechanisms, such as Transport Layer 491 Security (TLS) [6], or unless the URI-list body itself is encrypted 492 with, e.g., S/MIME [8]. Therefore, it is RECOMMENDED that URI-list 493 bodies are encrypted with S/MIME [8] or that the SIP request is 494 encrypted with TLS [6] or any other suitable encryption mechanism. 496 Note that this URI-list does not indicate the actual participants in 497 the session. It indicates only the URIs invited and that might 498 accept the request. It does not assert that these parties actually 499 exist, that they are reachable at the given URI, or that they have 500 accepted the invitation. No inferences about billing should be made 501 from this information. It is subject to spoofing by loading the list 502 with falsified content. 504 9. IANA Considerations 506 The following sections instruct the IANA to register: a new 507 disposition type, a new XML namespace, and a new XML schema. 509 9.1. Disposition Type Registration 511 Section 7 defines a new 'recipient-list-history' value of the Mail 512 Content Disposition Values registry. This value should be registered 513 in the IANA registry of Mail Content Disposition Values with the 514 following registration data: 516 +------------------------+------------------------------+-----------+ 517 | Name | Description | Reference | 518 +------------------------+------------------------------+-----------+ 519 | recipient-list-history | the body contains a list of | [RFCXXXX] | 520 | | URIs that indicates the | | 521 | | recipients of the SIP | | 522 | | request | | 523 +------------------------+------------------------------+-----------+ 525 Table 1: Registration of the 'recipient-list-history' Mail Content 526 Disposition Value 528 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 529 number of this specification. 531 9.2. XML Namespace Registration 533 This section registers a new XML namespace in the IANA XML registry, 534 as per the guidelines in RFC 3688 [5]. 536 URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol 538 Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), 539 Miguel Garcia-Martin (miguel.an.garcia@nokia.com). 541 XML: 543 BEGIN 544 545 547 548 549 551 Copy Control Namespace 552 553 554

Namespace for the Copy Control Attribute Extension 555 in Resource Lists

556

urn:ietf:params:xml:ns:copycontrol

557

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

560 561 562 END 564 9.3. XML Schema Registration 566 This section registers a new XML schema in the IANA XML registry per 567 the procedures in RFC 3688 [5]. 569 URI: urn:ietf:params:xml:schema:copycontrol 571 Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), 572 Miguel Garcia-Martin (miguel.an.garcia@nokia.com). 574 The XML for this schema can be found as the sole content of 575 Section 5. 577 10. Acknowledgements 579 Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, 580 Brian Rosen, Mary Barnes, and James Polk for reviewing this document 581 and providing helpful comments. 583 11. References 584 11.1. Normative References 586 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 587 Levels", BCP 14, RFC 2119, March 1997. 589 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 590 Presentation Information in Internet Messages: The Content- 591 Disposition Header Field", RFC 2183, August 1997. 593 [3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 594 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 595 Objects", RFC 3204, December 2001. 597 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 598 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 599 Session Initiation Protocol", RFC 3261, June 2002. 601 [5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 602 January 2004. 604 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 605 Protocol Version 1.1", RFC 4346, April 2006. 607 [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for 608 Representing Resource Lists", 609 draft-ietf-simple-xcap-list-usage-05 (work in progress), 610 February 2005. 612 [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 613 (S/MIME) Version 3.1 Message Specification", RFC 3851, 614 July 2004. 616 [9] Camarillo, G. and A. Roach, "Framework and Security 617 Considerations for Session Initiation Protocol (SIP) Uniform 618 Resource Identifier (URI)-List Services", 619 draft-ietf-sipping-uri-services-06 (work in progress), 620 September 2006. 622 11.2. Informational References 624 [10] Camarillo, G. and A. Johnston, "Conference Establishment Using 625 Request-Contained Lists in the Session Initiation Protocol 626 (SIP)", draft-ietf-sip-uri-list-conferencing-01 (work in 627 progress), January 2007. 629 [11] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 630 Requests in the Session Initiation Protocol (SIP)", 631 draft-ietf-sip-uri-list-message-01 (work in progress), 632 January 2007. 634 Authors' Addresses 636 Miguel A. Garcia-Martin 637 Nokia 638 P.O.Box 407 639 NOKIA GROUP, FIN 00045 640 Finland 642 Email: miguel.an.garcia@nokia.com 644 Gonzalo Camarillo 645 Ericsson 646 Hirsalantie 11 647 Jorvas 02420 648 Finland 650 Email: Gonzalo.Camarillo@ericsson.com 652 Full Copyright Statement 654 Copyright (C) The IETF Trust (2007). 656 This document is subject to the rights, licenses and restrictions 657 contained in BCP 78, and except as set forth therein, the authors 658 retain all their rights. 660 This document and the information contained herein are provided on an 661 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 662 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 663 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 664 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 665 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 666 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 668 Intellectual Property 670 The IETF takes no position regarding the validity or scope of any 671 Intellectual Property Rights or other rights that might be claimed to 672 pertain to the implementation or use of the technology described in 673 this document or the extent to which any license under such rights 674 might or might not be available; nor does it represent that it has 675 made any independent effort to identify any such rights. Information 676 on the procedures with respect to rights in RFC documents can be 677 found in BCP 78 and BCP 79. 679 Copies of IPR disclosures made to the IETF Secretariat and any 680 assurances of licenses to be made available, or the result of an 681 attempt made to obtain a general license or permission for the use of 682 such proprietary rights by implementers or users of this 683 specification can be obtained from the IETF on-line IPR repository at 684 http://www.ietf.org/ipr. 686 The IETF invites any interested party to bring to its attention any 687 copyrights, patents or patent applications, or other proprietary 688 rights that may cover technology that may be required to implement 689 this standard. Please address the information to the IETF at 690 ietf-ipr@ietf.org. 692 Acknowledgment 694 Funding for the RFC Editor function is provided by the IETF 695 Administrative Support Activity (IASA).