idnits 2.17.1 draft-ietf-sip-uri-list-subscribe-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 401. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3265, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3265, updated by this document, for RFC5378 checks: 2001-07-05) -- 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 (January 26, 2007) is 6298 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 306 ** Obsolete normative reference: RFC 3265 (ref. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-06 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Updates: 3265 (if approved) A. Roach 4 Expires: July 30, 2007 Estacado Systems 5 O. Levin 6 Microsoft Corporation 7 January 26, 2007 9 Subscriptions to Request-Contained Resource Lists in the Session 10 Initiation Protocol (SIP) 11 draft-ietf-sip-uri-list-subscribe-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 30, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document specifies a way to create subscription to a list of 45 resources in SIP. This is achieved by including the list of 46 resources in the body of a SUBSCRIBE request. Instead of having a 47 subscriber send a SUBSCRIBE request for each resource individually, 48 the subscriber defines the resource list, subscribes to it, and gets 49 notifications about changes in the resources' state using a single 50 SUBSCRIBE dialog. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. User Agent Client Procedures . . . . . . . . . . . . . . . . . 3 57 3.1. Response Handling . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Subsequent SUBSCRIBE Requests . . . . . . . . . . . . . . 4 59 4. URI-List Document Format . . . . . . . . . . . . . . . . . . . 4 60 5. Resource List Server Behavior . . . . . . . . . . . . . . . . 5 61 5.1. Subsequent SUBSCRIBE Requests . . . . . . . . . . . . . . 5 62 6. Providing a URI to Manipulate a Resource List . . . . . . . . 5 63 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. List-management Purpose Parameter Value . . . . . . . . . 8 67 9.2. Recipient-list-subscribe Option-Tag . . . . . . . . . . . 8 68 10. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Intellectual Property and Copyright Statements . . . . . . . . . . 10 73 1. Introduction 75 RFC 4662 [4] specifies how to establish subscriptions to a 76 homogeneous resource list in SIP (which is specified in RFC 3261 [2]) 77 and defines the procedures for getting notifications about changes in 78 the state of the associated resources. Yet, list creation is outside 79 the scope of RFC 4662 [4]. 81 This document specifies a way to create a list with a set of 82 resources and subscribe to it using a single SIP request. This is 83 achieved by including the list of resources (as defined in RFC xxxx 84 [5]) in the body of the SUBSCRIBE request. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [1]. 92 3. User Agent Client Procedures 94 A UAC (User Agent Client) that wants to create a resource list and 95 subscribe to it using the mechanism described in this document, 96 constructs a SUBSCRIBE request with at least one body, whose 97 disposition is type "recipient-list" as defined in RFC xxxx [5], 98 containing the URI-list. Additionally, the UAC MUST include the 99 'recipient-list-subscribe' option-tag, which is registered with the 100 IANA in Section 9, in a Require header field. The UAC MUST build the 101 remaining of the SUBSCRIBE request following the rules in RFC 3265 102 [3]. 104 The UAC MUST support the "rlmi+xml" format defined in RFC 4662 [4] 105 and signal this by including "rlmi+xml" in the Accept header. The 106 UAC MAY support additional formats and include them in the Accept 107 header field of the SUBSCRIBE request. 109 3.1. Response Handling 111 The status code in the response to the SUBSCRIBE request does not 112 provide any information about whether or not the resource list server 113 was able to successfully subscribe to the URIs in the URI-list. The 114 UAC obtains this information in the notifications sent by the server. 116 3.2. Subsequent SUBSCRIBE Requests 118 The previous sections have specified how to include a URI-list in an 119 initial SUBSCRIBE request to a resource list server in order to 120 subscribe to the state of a set of resources. Once the subscription 121 has been created and a dialog between the UAC and the resource list 122 server has been established, the UAC can send subsequent SUBSCRIBE 123 requests to, for example, extend the duration of the subscription. 125 At this point, there are no semantics associated with resource-list 126 bodies in subsequent SUBSCRIBE requests (although future extensions 127 can define them). Therefore, UACs SHOULD NOT include resource-list 128 bodies in subsequent SUBSCRIBE requests to a resource list server. 130 Note that a difference between an initial SUBSCRIBE request and 131 subsequent ones is that while the initial request is sent to the 132 public URI of the resource list, subsequent ones are sent to the 133 URI provided by the server when the dialog was established. 134 Therefore, from the UAC's point of view, the resource identified 135 by the former URI supports recipient-list bodies while the 136 resource identified by the latter does not support them. 138 4. URI-List Document Format 140 RFC xxxx [5] mandates that each URI-list services specification, such 141 as the subscription service defined here, specifies the default 142 format for the recipient-list bodies used within the particular 143 service. 145 The default format for the recipient-list bodies for the subscription 146 service defined in this document is the resource list format defined 147 in RFC xxxx [6]. UAs (User Agents) generating recipient-list bodies 148 MUST support this format and MAY support other formats. Resource 149 list servers able to handle recipient-list bodies MUST support this 150 format and MAY support other formats. 152 The Extensible Markup Language (XML) Configuration Access Protocol 153 (XCAP) resource list document provides features, such as hierarchical 154 lists and the ability to include entries by reference relative to the 155 XCAP root URI, that are not needed by the subscription service 156 defined here, which only needs to transfer a flat list of URIs 157 between a UA and the resource list server. Therefore, when using the 158 default resource list document, UAs SHOULD use flat lists (i.e., no 159 hierarchical lists) and SHOULD NOT use elements. A 160 resource list server receiving a URI-list with more information than 161 what has just been described MAY discard all the extra information. 163 Figure 1 shows an example of a flat list that follows the resource 164 list document. 166 167 169 170 171 172 173 174 176 Figure 1: URI-List 178 5. Resource List Server Behavior 180 Resource list servers that are able to receive and process SUBSCRIBE 181 requests with a recipient-list body SHOULD include a 'recipient-list- 182 subscribe' option-tag in a Supported header field when responding to 183 OPTIONS requests. 185 On reception of a SUBSCRIBE request with a URI-list, a resource list 186 server, which chooses to accept the "rlmi+xml" format, MUST comply 187 with RFC 4662 [4] for creating the subscription and reporting the 188 changes in the resources within the created dialog. 190 5.1. Subsequent SUBSCRIBE Requests 192 At this point, there are no semantics associated with resource-list 193 bodies in subsequent SUBSCRIBE requests (although future extensions 194 may define them). Therefore, a resource list server receiving a 195 subsequent SUBSCRIBE request with a resource-list body, following 196 standard SIP procedures, rejects it with a 415 (Unsupported Media 197 Type) response. 199 6. Providing a URI to Manipulate a Resource List 201 A UAC can manipulate a resource list at a resource list server. The 202 resource list server MAY provide a URI to manipulate the resource 203 list associated with a subscription using the Call-Info header field 204 in the NOTIFY request that establishes the subscription. The 205 "purpose" parameter of the Call-Info header field MUST have a value 206 of 'list-management', which we register with the IANA in Section 9. 207 The following is an example of such a header field. 209 Call-Info: 210 ;purpose=list-management 212 The life-time of a resource list to be manipulated by the URI 213 provided by the server is bundled to the life-time of the 214 subscription. That is, the resource list SHOULD be destroyed when 215 the subscription expires or is otherwise terminated. 217 Section 7.1 of RFC 3265 [3] does not list the Call-Info header field 218 in the table of header fields NOTIFY requests can carry. This 219 document updates that table so that the Call-Info header field can be 220 optionally included in NOTIFY requests. 222 7. Example 224 The following is an example of a SUBSCRIBE request, which carries a 225 URI-list in its body, sent by a UAC to a resource list server. 227 SUBSCRIBE sip:rls@example.com SIP/2.0 228 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 229 Max-Forwards: 70 230 To: RLS 231 From: ;tag=ie4hbb8t 232 Call-ID: cdB34qLToC@terminal.example.com 233 CSeq: 1 SUBSCRIBE 234 Contact: 235 Event: presence 236 Expires: 7200 237 Require: recipient-list-subscribe 238 Supported: eventlist 239 Accept: application/cpim-pidf+xml 240 Accept: application/rlmi+xml 241 Accept: multipart/related 242 Accept: multipart/signed 243 Accept: multipart/encrypted 244 Content-Type: application/resource-lists+xml 245 Content-Disposition: recipient-list 246 Content-Length: 337 248 249 251 252 253 254 255 256 258 Figure 2: SUBSCRIBE request 260 8. Security Considerations 262 The Security Considerations Section of RFC 4662 [4] discusses 263 security issues related to resource list servers. Resource list 264 servers accepting request-contained URI-lists MUST also follow the 265 security guidelines given in RFC 4662 [4]. 267 The Framework and Security Considerations for SIP URI-List Services 268 (which is specified in RFC xxxx [5]) discusses issues related to SIP 269 URI-list services. Given that a resource list server sending 270 SUBSCRIBE requests to a set of users acts as a URI-list service, 271 implementations of resource list servers that handle request- 272 contained URI-lists MUST follow the security-related rules in RFC 273 xxxx [5]. These rules include mandatory authentication and 274 authorization of clients, and opt-in lists. 276 9. IANA Considerations 278 The following sections request the IANA to register the 'list- 279 management' value for the purpose parameter of the Call-Info header 280 field and the 'recipient-list-subscribe' SIP option-tag. 282 9.1. List-management Purpose Parameter Value 284 This document defines the 'list-management' value for the purpose 285 parameter of the Call-Info header field. A reference to this RFC (in 286 double brackets) needs to be added to the existing purpose Call-Info 287 parameter entry in the SIP Parameters registry. 289 9.2. Recipient-list-subscribe Option-Tag 291 This document defines the SIP option tag "recipient-list-subscribe". 293 The following row shall be added to the "Option Tags" section of the 294 SIP Parameter Registry: 296 +--------------------------+------------------------------+-----------+ 297 | Name | Description | Reference | 298 +--------------------------+------------------------------+-----------+ 299 | recipient-list-subscribe | This option tag is used to | [RFCXXXX] | 300 | | ensure that a server can | | 301 | | process the 'recipient-list' | | 302 | | body used in a SUBSCRIBE | | 303 | | request. | | 304 +---------------------------------------------------------+-----------+ 306 Editor Note: [RFCXXXX] should be replaced with the designation of 307 this document. 309 10. Acknowledges 311 Cullen Jennings and Jonathan Rosenberg provided useful comments on 312 this document. 314 11. Normative References 316 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 317 Levels", BCP 14, RFC 2119, March 1997. 319 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 320 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 321 Session Initiation Protocol", RFC 3261, June 2002. 323 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 324 Notification", RFC 3265, June 2002. 326 [4] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation 327 Protocol (SIP) Event Notification Extension for Resource Lists", 328 RFC 4662, August 2006. 330 [5] Camarillo, G. and A. Roach, "Framework and Security 331 Considerations for Session Initiation Protocol (SIP) Uniform 332 Resource Identifier (URI)-List Services", 333 draft-ietf-sipping-uri-services-06 (work in progress), 334 September 2006. 336 [6] Rosenberg, J., "Extensible Markup Language (XML) Formats for 337 Representing Resource Lists", 338 draft-ietf-simple-xcap-list-usage-05 (work in progress), 339 February 2005. 341 Authors' Addresses 343 Gonzalo Camarillo 344 Ericsson 345 Hirsalantie 11 346 Jorvas 02420 347 Finland 349 Email: Gonzalo.Camarillo@ericsson.com 351 Adam Roach 352 Estacado Systems 354 Email: adam@estacado.net 356 Orit Levin 357 Microsoft Corporation 358 One Microsoft Way 359 Redmond, WA 98052 361 Email: oritl@microsoft.com 363 Full Copyright Statement 365 Copyright (C) The IETF Trust (2007). 367 This document is subject to the rights, licenses and restrictions 368 contained in BCP 78, and except as set forth therein, the authors 369 retain all their rights. 371 This document and the information contained herein are provided on an 372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 374 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 375 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 376 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 379 Intellectual Property 381 The IETF takes no position regarding the validity or scope of any 382 Intellectual Property Rights or other rights that might be claimed to 383 pertain to the implementation or use of the technology described in 384 this document or the extent to which any license under such rights 385 might or might not be available; nor does it represent that it has 386 made any independent effort to identify any such rights. Information 387 on the procedures with respect to rights in RFC documents can be 388 found in BCP 78 and BCP 79. 390 Copies of IPR disclosures made to the IETF Secretariat and any 391 assurances of licenses to be made available, or the result of an 392 attempt made to obtain a general license or permission for the use of 393 such proprietary rights by implementers or users of this 394 specification can be obtained from the IETF on-line IPR repository at 395 http://www.ietf.org/ipr. 397 The IETF invites any interested party to bring to its attention any 398 copyrights, patents or patent applications, or other proprietary 399 rights that may cover technology that may be required to implement 400 this standard. Please address the information to the IETF at 401 ietf-ipr@ietf.org. 403 Acknowledgment 405 Funding for the RFC Editor function is provided by the IETF 406 Administrative Support Activity (IASA).