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