idnits 2.17.1 draft-ietf-sipping-capacity-attribute-03.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 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 675. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 5, 2006) is 6345 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 504 ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** 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-00 == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-00 Summary: 3 errors (**), 0 flaws (~~), 6 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: June 8, 2007 Ericsson 6 December 5, 2006 8 Extensible Markup Language (XML) Format Extension for Representing Copy 9 Control Attributes in Resource Lists 10 draft-ietf-sipping-capacity-attribute-03.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 8, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 10 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 9.1. Disposition Type Registration . . . . . . . . . . . . . . 12 66 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 12 67 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 13 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 71 11.2. Informational References . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 73 Intellectual Property and Copyright Statements . . . . . . . . . . 16 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 [5] 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 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 122 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 123 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 124 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 125 compliant implementations. 127 URI-list service: SIP application service that receives a SIP 128 request containing a URI-list and sends a similar SIP request to 129 each URI in the list. 131 Intended recipient: The intended final recipient of the request to 132 be generated by URI-list service. 134 Copy control: An attribute assigned by the sender to a URI in a XML 135 resource list. Its purpose is to indicate to the recipient 136 whether he is getting a primary, carbon, or blind carbon copy of 137 the SIP request. 139 Recipient list or recipient XML resource list: An XML resource list 140 containing the list of intended recipients. The sender sets this 141 list in the SIP request he sends to the URI-list server. 143 Recipient-history list or recipient-history XML resource list: An 144 XML resource list containing the visible list of recipients (i.e., 145 those non-anonymous non-bcc). The URI-list server creates this 146 list, based on the recipient list, and includes it in each of the 147 SIP requests it sends to each recipient. 149 3. Overview of operation 151 Figure 1 depicts a general overview of the operation of a URI-list 152 server. A SIP User Agent Client (UAC) issuer sends a SIP request 153 (F1) to a URI-list server containing a recipient list. The URI-list 154 server generates a SIP request to each recipient, according to the 155 specific SIP method. Each of these SIP requests contains a 156 recipient-history list that indicates the visible list of recipients 157 of the SIP request. 159 +--------+ +---------+ +--------+ +--------+ +--------+ 160 |SIP UAC | | URI-list| |intended| |intended| |intended| 161 | issuer | | server | | recip. | | recip. | | recip. | 162 | | | | | 1 | | 2 | | 3 | 163 +--------+ +---------+ +--------+ +--------+ +--------+ 164 | | | | | 165 | F1. SIP request | | | | 166 | (recipt. list) | | | | 167 | ---------------->| | | | 168 | F2. 2xx response | | | | 169 |<---------------- | F3. SIP request | | | 170 | | (recp-hist.list)| | | 171 | | --------------->| | | 172 | | F4. SIP request | | | 173 | | (recp-hist.list)| | | 174 | | -------------------------->| | 175 | | F5. SIP request | | | 176 | | (recp-hist.list)| | | 177 | | ------------------------------------->| 178 | | F6. 200 OK | | | 179 | |<--------------- | | | 180 | | F7. 200 OK | | | 181 | |<-------------------------- | | 182 | | F8. 200 OK | | | 183 | |<------------------------------------- | 184 | | | | | 185 | | | | | 186 | | | | | 188 Figure 1: Example of operation 190 The URI-list mechanism allows a sender to specify multiple targets 191 for a SIP request by including a recipient XML resource list [7] in 192 the body of the SIP request. This recipient list includes the target 193 URIs of the SIP request (the actual procedures are method specific 194 and outside the scope of this document). Each target URI may also be 195 marked with a copy control attribute to indicate the copy level in 196 which the recipient is receiving the SIP request. This is achieved 197 by the sender qualifying each URI in the URI-list with a 198 'copyControl' attribute. The available values of the 'copyControl' 199 attribute include "to", "cc", and "bcc" (analogous to e-mail). This 200 is discussed in greater detailed in Section 4. When the URI-list 201 server expands the request to each recipient, the URI-list server 202 includes a recipient-history XML resource list built upon the 203 recipient list received from the sender. The recipient-history XML 204 resource list replaces the recipient list in the SIP requests 205 generated by the URI-list server towards each recipient. The URI- 206 list server copies from the recipient list those targets which are 207 marked with the "to" and "cc" copy control level, and pastes them in 208 the recipient-history list. The URI-list server explicitly excludes 209 from the copy those URIs marked with a "bcc" copy control. When a 210 recipient receives the SIP request containing the recipient-history 211 XML resource list, he is able to determine which other visible 212 recipients are getting the same SIP requests, and whether they are 213 marked with the "to" or "cc" copy control level. Later, if needed, 214 the recipient can generate a reply to those visible recipients. 216 In addition to the 'copyControl' attribute for a URI in an XML 217 resource list, we define a second boolean attribute called 218 'anonymize'. The sender of a SIP request can mark a URI in a 219 recipient XML resource list with the 'anonymize' attribute to 220 indicate the URI-list server that the URI marked with that attribute 221 is to be replaced with an anonymous URI in the recipient-history XML 222 resource list. This provides a knowledge to recipients of a SIP 223 request of a number of additional recipients whose URIs have not been 224 disclosed. 226 There are cases when the sender marks several URIs with the 227 'anonymize' attribute. The URI-list server can group the anonymized 228 URIs in a single anonymized URI within its copy control level, and 229 provide a count of the number of anonymized URIs. To support this 230 scenario, we define a new 'count' attribute to a URI in the 231 recipient-history XML resource list. It is expected that the 'count' 232 attribute is only used with anonymous URIs, although syntactically it 233 is possible to add a 'count' attribute to any URI in any XML resource 234 list. 236 Initially, it may be thought that the 'anonymize' attribute overlaps 237 with the "bcc" value of the 'copyControl' attribute. However, there 238 are differences between them. If the sender qualifies a URI with a 239 'copyControl' attribute of "bcc" in the recipient XML resource list, 240 the URI-list server will completely remove that URI from the 241 recipient-history XML resource list. Recipients of the SIP request 242 will not notice that one or more extra URIs also received the 243 request. However, if the sender qualifies a URI with the 'anonymize' 244 attribute in the recipient XML resource list, the URI-list server 245 will replace the URI with an anonymous one in the recipient-history 246 list. Recipients of the SIP request will notice that there have been 247 one or more additional recipients of the same request, but their URIs 248 have not been disclosed. 250 4. Extension to the resource lists data format 252 This document defines an extension to the XML resource list data 253 format [7] that allows the sender to indicate a copy control 254 attribute that qualifies a recipient with a copy control level. We 255 define a new 'copyControl' attribute to the element of the 256 resource list document format [7]. The 'copyControl' attribute has 257 similar semantics to the type of destination address in e-mail 258 systems. It can take the values "to", "cc", and "bcc". A "to" value 259 of the 'copyControl' attribute indicates that the resource is 260 considered a primary recipient of the SIP request. A "cc" value 261 indicates that the resource receives a carbon copy of the SIP 262 request. A "bcc" value indicates that the resource receives a blind 263 carbon copy of the SIP request (i.e., this URI is not disclosed in 264 the recipient-history list). The default 'copyControl' value is 265 "bcc". That is, the absence of a 'copyControl' attribute MUST be 266 treated as if the 'copyControl' was set to "bcc". URI-list servers 267 use URIs marked with the "bcc" 'copyControl' attribute to route SIP 268 requests, but MUST NOT include them in recipient-history lists. 270 A new 'anonymize' attribute can be included in a element of 271 the resource list document format [7]. If set to a "true" value, it 272 provides an indication to the URI-list server for not disclosing the 273 URI itself in a URI-list sent to the recipient, but instead, to 274 anonymize the URI (i.e., making it bogus in the recipient-history XML 275 resource list). URI-list servers can use URIs tagged with the 276 'anonymize' attribute for routing SIP requests, but MUST convert them 277 to an anonymized URI (such as sip:anonymous@anonymous.invalid) in 278 recipient-history lists. The default value of the 'anonymize' 279 attribute is "false". 281 Processing of URIs tagged with a 'copyControl' attribute set to a 282 "bcc" value has higher precedence over the 'anonymize' attribute. 283 Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list 284 server MUST remove that URI from the recipient-history list, and the 285 'anonymize' attribute will be ignored. Therefore, the 'anonymize' 286 attribute is only useful for those URIs tagged with a 'copyControl' 287 of "to" or "cc". 289 A new 'count' attribute can be also included in a element of 290 the resource list document format [7]. It provides the number of 291 equal URIs. Typically, recipient lists created by UACs will not have 292 equal (or duplicate) URI entries, thus, it is not expected to contain 293 URIs tagged with 'count' attributes. However, recipient-history 294 lists can contain duplicated anonymized URIs, therefore, it is 295 expected that recipient-history lists will contain 'count' 296 attributes. The default value of the 'count' attribute is "1". 298 The 'copyControl', 'anonymize', and 'count' attributes SHOULD be 299 included as modifiers of any of the child elements included in the 300 element of a resource list (e.g., attribute of the or 301 elements). 303 Section 5 describes the format of the 'copyControl', 'anonymize', and 304 'count' attributes. Implementations according to this specification 305 MUST support this XML Schema. 307 5. XML Schema 309 310 317 318 319 Adds the copyControl, anonymize, and count attributes 320 to URIs included in a resource list. 321 322 324 327 328 329 330 331 332 333 334 335 337 338 341 343 Figure 2: XML Schema of the extension to the resource list format 345 6. Examples 347 This section shows two examples of URI-lists that can be included in 348 SIP requests. The first example in Figure 3 shows a recipient list 349 that the UAC sends to the URI-list server. This corresponds to a 350 list that will be included in the flow F2 in Figure 1. The recipient 351 list contains a flat list according to the resource list data format 352 [7]. Each resource indicates the copy control of a resource with a 353 'copyControl' attribute. Some of the resources are also marked with 354 the 'anonymize' attribute. This provides an indication to the URI- 355 list service for not disclosing their URIs in a recipient-history 356 list. The last two elements are marked with a 'copyControl' 357 attribute of "bcc". This provides an indication to the URI-list 358 server for removing these URIs in the recipient-history list. 360 361 363 364 365 367 369 370 372 373 374 375 377 Figure 3: Recipient list sent from the UAC to the URI-list server 379 Upon receipt of the SIP request containing the recipient list of 380 Figure 3 the URI-list server creates a SIP request to each of the 381 URIs listed in the recipient list (so, in our example, it creates 7 382 SIP requests). The URI-list server processes the recipient list and 383 creates a recipient-history list that is included in each of the 384 outgoing SIP requests. The process is as follows: the URI-list 385 server creates a new recipient-history list, based on the recipient 386 list, but with changes. First it copies all the URIs ( 387 elements) marked with the "to" or "cc" 'copyControl' attributes, 388 which do not contain an 'anonymize' attribute (or when the 389 'anonymize' attribute is set to "false"). Then all the URIs marked 390 with a 'copyControl' attribute set to "to" and 'anonymize' attribute 391 set to "true" are replaced with an anonymous URI, such as 392 "sip:anonymous@anonymous.invalid". In this entry the URI-list server 393 also adds the original value of the 'copyControl' attribute ("to" in 394 our example), and it adds a 'count' attribute containing the number 395 of anonymous entries in this group ("2" in our example). Then the 396 URI-list server does the same operation to the URIs tagged with the 397 'copyControl' attribute set to "cc" and 'anonymize' attribute set to 398 "true", adding also the 'count' attribute containing the number of 399 anonymous attributes in this group ("1" in the example). Last, the 400 URI-list server completely removes URIs marked with the "bcc" 401 'copyControl' attribute. The resulting recipient-history list is 402 shown in Figure 4. 404 405 407 408 409 411 412 414 415 417 Figure 4: Recipient-history list sent from the URI-list server to 418 each recipient 420 7. Carrying URI-lists in SIP 422 A SIP UAC (User Agent Client) that composes a SIP request can include 423 a URI-list with the extensions specified in this document to indicate 424 the list of intended recipients. On doing so, as specified in the 425 Framework and Security Considerations for SIP URI-List Services [9], 426 the UAC adds a Content-Disposition [2] header field set to the value 427 'recipient-list'. Typically UACs send these 'recipient-list' bodies 428 to URI-list services (this corresponds to flow F1 in Figure 1). A 429 body whose Content-Disposition type is 'recipient-list' contains a 430 URI-list that includes the intended recipients of the SIP request, 431 something known throughout this document as a recipient list. The 432 element in the URI-list MAY also include a 'copyControl' and 433 'anonymize' attributes, as specified in Section 4. 435 To be able to inform intended recipients of who else is receiving a 436 copy of the SIP request, we define a new mail disposition type to be 437 included in a Content-Disposition [2] header field of a SIP request. 438 The value of this new disposition type is 'recipient-list-history' 439 and its purpose is to indicate a list of recipients that a SIP 440 request was sent to, something known throughout this document as a 441 recipient-history list. A body whose Content-Disposition type is 442 'recipient-list-history' contains a URI-list with the visible 443 (including anonymized) recipients of the SIP request. The 444 element in the URI-list MAY also include a 'copyControl' and 'count' 445 attributes, as specified in Section 4. 447 On sending a SIP request that contains a recipient-history list, if 448 the intended recipient does not support this specification, the SIP 449 request should not fail. In order to ensure successful receipt of 450 the SIP requests that include 'recipient-list-history' bodies, User 451 Agents (such as URI-list servers) that build SIP requests with the 452 Content-Disposition header field set to 'recipient-list-history' 453 SHOULD add a 'handling' parameter [4] set to "optional". Otherwise, 454 the SIP request could fail and never be received by the intended 455 recipient. 457 8. Security Considerations 459 The Framework and Security Considerations for SIP URI-List Services 460 [9] discusses issues related to SIP URI-list services. 461 Implementations of this specification MUST follow the security- 462 related rules in the Framework and Security Considerations for SIP 463 URI-List Services [9]. These rules include mandatory authentication 464 and authorization of clients, and opt-in lists. 466 User Agent Clients SHOULD NOT hand SIP requests containing URI-list 467 services to unauthenticated and untrusted parties. This is to avoid 468 man-in-the-middle attacks or acquiring URI-lists for performing SPAM 469 attacks. 471 URI-lists may contain private information, such as SIP URIs. It is 472 therefore not desirable that these URI-lists are known by third 473 parties. Eavesdroppers are able to watch URI-lists contained in SIP 474 requests unless the SIP message is sent over a secured channel, by 475 using any of the available SIP mechanisms, such as Transport Layer 476 Security (TLS) [3], or unless the URI-list body itself is encrypted 477 with, e.g., S/MIME [8]. Therefore, it is RECOMMENDED that URI-list 478 bodies are encrypted with S/MIME [8] or that the SIP request is 479 encrypted with TLS [3] or any other suitable encryption mechanism. 481 Note that this URI-list does not indicate the actual participants in 482 the session. It indicates only the URIs invited and that might 483 accept the request. It does not assert that these parties actually 484 exist, that they are reachable at the given URI, or that they have 485 accepted the invitation. No inferences about billing should be made 486 from this information. It is subject to spoofing by loading the list 487 with falsified content. 489 9. IANA Considerations 491 The following sections instruct the IANA to register: a new 492 disposition type, a new XML namespace, and a new XML schema. 494 9.1. Disposition Type Registration 496 Section 7 defines a new 'recipient-list-history' value of the Mail 497 Content Disposition Values registry. This value should be registered 498 in the IANA registry of Mail Content Disposition Values with the 499 following registration data: 501 +------------------------+------------------------------+-----------+ 502 | Name | Description | Reference | 503 +------------------------+------------------------------+-----------+ 504 | recipient-list-history | the body contains a list of | [RFCXXXX] | 505 | | URIs that indicates the | | 506 | | recipients of the SIP | | 507 | | request | | 508 +------------------------+------------------------------+-----------+ 510 Table 1: Registration of the 'recipient-list-history' Mail Content 511 Disposition Value 513 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 514 number of this specification. 516 9.2. XML Namespace Registration 518 This section registers a new XML namespace in the IANA XML registry, 519 as per the guidelines in RFC 3688 [6]. 521 URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol 523 Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), 524 Miguel Garcia-Martin (miguel.an.garcia@nokia.com). 526 XML: 528 BEGIN 529 530 532 533 534 536 Copy Control Namespace 537 538 539

Namespace for the Copy Control Attribute Extension 540 in Resource Lists

541

urn:ietf:params:xml:ns:copycontrol

542

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

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