idnits 2.17.1 draft-ietf-sipping-uri-list-subscribe-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 360. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 21, 2005) is 6762 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) ** Obsolete normative reference: RFC 3265 (ref. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-03 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: April 24, 2006 A. Roach 5 Estacado Systems 6 O. Levin 7 Microsoft Corporation 8 October 21, 2005 10 Subscriptions to Request-Contained Resource Lists in the Session 11 Initiation Protocol (SIP) 12 draft-ietf-sipping-uri-list-subscribe-04.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 April 24, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 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. Instead of having a subscriber 48 send a SUBSCRIBE for each resource individually, the subscriber 49 defines the resource list, subscribes to it, and gets notifications 50 about changes in the resources' state using a single SUBSCRIBE 51 dialog. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Providing a Resource List Server with a URI-List . . . . . . . 3 58 4. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Resource List Server Behavior . . . . . . . . . . . . . . . . 4 60 6. Subsequent SUBSCRIBEs . . . . . . . . . . . . . . . . . . . . 4 61 7. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8. Providing a URI to Manipulate a Resource List . . . . . . . . 5 63 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 12. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 13. Normative References . . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 Intellectual Property and Copyright Statements . . . . . . . . . . 10 71 1. Introduction 73 RFC xxxx [4] specifies how to establish subscriptions to a 74 homogeneous resource list in SIP [2] and defines the procedures for 75 getting notifications about changes in the state of the associated 76 resources. Yet, list creation is outside the scope of [4]. 78 This document specifies a way to create a list with a set of 79 resources and subscribe to it using a single SIP request. This is 80 achieved by including the list of resources (as defined in [5]) in 81 the body of the SUBSCRIBE request. 83 2. Terminology 85 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 86 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 87 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 88 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 89 compliant implementations. 91 3. Providing a Resource List Server with a URI-List 93 A client that wants to create a resource list and subscribe to it, 94 using the mechanism described in this document, constructs a 95 SUBSCRIBE with at least one body, whose disposition is type 96 "recipient-list" as defined in [5], containing the URI-list. The 97 client MUST build the remaining of the SUBSCRIBE request following 98 the rules in RFC 3265 [3]. 100 The client MUST support the "rlmi+xml" format defined in [4] and 101 signal this by including "rlmi+xml" in the Accept header. The client 102 MAY support additional formats and include them in the Accept header 103 field of the SUBSCRIBE. 105 4. URI-List Format 107 The [5] mandates that each URI-list services specification, such as 108 the subscription service defined here, specifies the default format 109 for the recipient-list bodies used within the particular service. 111 The default format for the recipient-list bodies for the subscription 112 service defined in this document is the resource list format defined 113 in [6]. UAs (User Agents) and resource list servers handling 114 recipient-list bodies MUST support this format and MAY support other 115 formats. 117 The Extensible Markup Language (XML) Configuration Access Protocol 118 (XCAP) resource list document provides features, such as hierarchical 119 lists and the ability to include entries by reference relative to the 120 XCAP root URI, that are not needed by the subscription service 121 defined here, which only needs to transfer a flat list of URIs 122 between a UA and the resource list server. Therefore, when using the 123 default resource list document, UAs SHOULD use flat lists (i.e., no 124 hierarchical lists) and SHOULD NOT use elements. 126 A resource list server receiving a URI-list with more information 127 than what has just been described MAY discard all the extra 128 information. 130 Figure 1 shows an example of a flat list that follows the resource 131 list document. 133 134 136 137 138 139 140 141 143 Figure 1: URI-List 145 5. Resource List Server Behavior 147 On reception of a SUBSCRIBE with a URI-list, a resource list server, 148 which chooses to accept the "rlmi+xml" format, MUST comply with [4] 149 for creating the subscription and reporting the changes in the 150 resources within the created dialog. 152 Note that the status code in the response to the SUBSCRIBE does not 153 provide any information about whether or not the resource list server 154 was able to successfully subscribe to the URIs in the URI-list. The 155 client obtains this information in the notifications sent by the 156 server. 158 6. Subsequent SUBSCRIBEs 160 The previous Sections have specified how to include a URI-list in an 161 initial SUBSCRIBE request to a resource list server in order to 162 subscribe to the state of a set of resources. Once the subscription 163 has been created and a dialog between the client and the resource 164 list server has been established, the client may need to send 165 subsequent SUBSCRIBE requests to, for example, extend the duration of 166 the subscription. 168 At this point, there are no semantics associated with resource-list 169 bodies in subsequent SUBSCRIBE requests (although future extensions 170 may define them). Therefore, clients SHOULD NOT include resource- 171 list bodies in subsequent SUBSCRIBE requests to a resource list 172 server. 174 A resource list server receiving a subsequent SUBSCRIBE request with 175 a resource-list body, following standard SIP procedures, rejects it 176 with a 415 (Unsupported Media Type) response. 178 Note that a difference between an initial SUBSCRIBE request and 179 subsequent ones is that while the initial request is sent to the 180 public URI of the resource list, subsequent ones are sent to the 181 URI provided by the server when the dialog was established. 182 Therefore, from the client's point of view, the resource 183 identified by the former URI supports recipient-list bodies while 184 the resource identified by the latter does not support them. 186 7. Option-tag 188 This document defines the 'recipient-list-subscribe' option-tag for 189 use in the Require and Supported SIP header fields. 191 User agent clients generating a SUBSCRIBE with a recipient-list body, 192 as described in previous sections, MUST include this option-tag in a 193 Require header field. User agents that are able to receive and 194 process SUBSCRIBEs with a recipient-list body, as described in 195 previous sections, SHOULD include this option-tag in a Supported 196 header field when responding to OPTIONS requests. 198 8. Providing a URI to Manipulate a Resource List 200 A client may need to manipulate a resource list at a resource list 201 server. The resource list server MAY provide a URI to manipulate the 202 resource list associated with a subscription using the Call-Info 203 header field in the NOTIFY that establishes the subscription. The 204 "purpose" parameter of the Call-Info header field MUST have a value 205 of 'list-management', which we register with the IANA in Section 11. 206 The following is an example of such a header field. 208 Call-Info: 209 ;purpose=list-management 211 The life-time of a resource list to be manipulated by the URI 212 provided by the server is blundled to the life-time of the 213 subscription. That is, the resource list SHOULD be destroyed when 214 the subscription expires or is otherwise terminated. 216 9. Example 218 The following is an example of a SUBSCRIBE request, which carries a 219 URI-list in its body, sent by a UA to a resource list server. 221 SUBSCRIBE sip:rls@example.com SIP/2.0 222 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 223 Max-Forwards: 70 224 To: RLS 225 From: ;tag=ie4hbb8t 226 Call-ID: cdB34qLToC@terminal.example.com 227 CSeq: 1 SUBSCRIBE 228 Contact: 229 Event: presence 230 Expires: 7200 231 Require: recipient-list-subscribe 232 Supported: eventlist 233 Accept: application/cpim-pidf+xml 234 Accept: application/rlmi+xml 235 Accept: multipart/related 236 Accept: multipart/signed 237 Accept: multipart/encrypted 238 Content-Type: application/resource-lists+xml 239 Content-Disposition: recipient-list 240 Content-Length: 337 242 243 245 246 247 248 249 250 252 Figure 2: SUBSCRIBE request 254 10. Security Considerations 256 The Security Considerations Section of [4] discusses security issues 257 related to resource list servers. Resource list servers accepting 258 request-contained URI-lists MUST also follow the security guidelines 259 given in [4]. 261 The Framework and Security Considerations for SIP URI-List Services 262 [5] discusses issues related to SIP URI-list services. Given that a 263 resource list server sending SUBSCRIBEs to a set of users acts as a 264 URI-list service, implementations of resource list servers that 265 handle request-contained URI-lists MUST follow the security-related 266 rules in [5]. These rules include mandatory authentication and 267 authorization of clients, and opt-in lists. 269 11. IANA Considerations 271 The document defines the 'list-management' value for the purpose 272 parameter of the Call-Info header field. A reference to this RFC (in 273 double brackets) needs to be added to the purpose Call-Info parameter 274 entry in the SIP Parameters registry. 276 This document defines the 'recipient-list-subscribe' SIP option-tag 277 in Section 7. It should be registered in the Option Tags subregistry 278 under the SIP parameter registry. The following is the description 279 to be used in the registration. 281 This option-tag is used to ensure that a server can process the 282 'recipient-list' body used in a SUBSCRIBE request. 284 12. Acknowledges 286 Cullen Jennings and Jonathan Rosenberg provided useful comments on 287 this document. 289 13. Normative References 291 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 292 Levels", BCP 14, RFC 2119, March 1997. 294 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 295 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 296 Session Initiation Protocol", RFC 3261, June 2002. 298 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 299 Notification", RFC 3265, June 2002. 301 [4] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation 302 Protocol (SIP) Event Notification Extension for Resource 303 Lists", draft-ietf-simple-event-list-07 (work in progress), 304 January 2005. 306 [5] Camarillo, G. and A. Roach, "Requirements and Framework for 307 Session Initiation Protocol (SIP)Uniform Resource Identifier 308 (URI)-List Services", draft-ietf-sipping-uri-services-03 (work 309 in progress), April 2005. 311 [6] Rosenberg, J., "Extensible Markup Language (XML) Formats for 312 Representing Resource Lists", 313 draft-ietf-simple-xcap-list-usage-05 (work in progress), 314 February 2005. 316 Authors' Addresses 318 Gonzalo Camarillo 319 Ericsson 320 Hirsalantie 11 321 Jorvas 02420 322 Finland 324 Email: Gonzalo.Camarillo@ericsson.com 326 Adam Roach 327 Estacado Systems 329 Email: adam@estacado.net 331 Orit Levin 332 Microsoft Corporation 333 One Microsoft Way 334 Redmond, WA 98052 336 Email: oritl@microsoft.com 338 Intellectual Property Statement 340 The IETF takes no position regarding the validity or scope of any 341 Intellectual Property Rights or other rights that might be claimed to 342 pertain to the implementation or use of the technology described in 343 this document or the extent to which any license under such rights 344 might or might not be available; nor does it represent that it has 345 made any independent effort to identify any such rights. Information 346 on the procedures with respect to rights in RFC documents can be 347 found in BCP 78 and BCP 79. 349 Copies of IPR disclosures made to the IETF Secretariat and any 350 assurances of licenses to be made available, or the result of an 351 attempt made to obtain a general license or permission for the use of 352 such proprietary rights by implementers or users of this 353 specification can be obtained from the IETF on-line IPR repository at 354 http://www.ietf.org/ipr. 356 The IETF invites any interested party to bring to its attention any 357 copyrights, patents or patent applications, or other proprietary 358 rights that may cover technology that may be required to implement 359 this standard. Please address the information to the IETF at 360 ietf-ipr@ietf.org. 362 Disclaimer of Validity 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 367 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 368 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 369 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Copyright Statement 374 Copyright (C) The Internet Society (2005). This document is subject 375 to the rights, licenses and restrictions contained in BCP 78, and 376 except as set forth therein, the authors retain all their rights. 378 Acknowledgment 380 Funding for the RFC Editor function is currently provided by the 381 Internet Society.