idnits 2.17.1 draft-ietf-sipping-uri-list-subscribe-05.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 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 (May 11, 2006) is 6554 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-05 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Expires: November 12, 2006 A. Roach 4 Estacado Systems 5 O. Levin 6 Microsoft Corporation 7 May 11, 2006 9 Subscriptions to Request-Contained Resource Lists in the Session 10 Initiation Protocol (SIP) 11 draft-ietf-sipping-uri-list-subscribe-05.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 November 12, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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. Instead of having a subscriber 47 send a SUBSCRIBE for each resource individually, the subscriber 48 defines the resource list, subscribes to it, and gets notifications 49 about changes in the resources' state using a single SUBSCRIBE 50 dialog. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Providing a Resource List Server with a URI-List . . . . . . . 3 57 4. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Resource List Server Behavior . . . . . . . . . . . . . . . . 4 59 6. Subsequent SUBSCRIBEs . . . . . . . . . . . . . . . . . . . . 4 60 7. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8. Providing a URI to Manipulate a Resource List . . . . . . . . 5 62 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 12. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 13. Normative References . . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 68 Intellectual Property and Copyright Statements . . . . . . . . . . 10 70 1. Introduction 72 RFC xxxx [4] specifies how to establish subscriptions to a 73 homogeneous resource list in SIP [2] and defines the procedures for 74 getting notifications about changes in the state of the associated 75 resources. Yet, list creation is outside the scope of [4]. 77 This document specifies a way to create a list with a set of 78 resources and subscribe to it using a single SIP request. This is 79 achieved by including the list of resources (as defined in [5]) in 80 the body of the SUBSCRIBE request. 82 2. Terminology 84 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 85 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 86 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 87 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 88 compliant implementations. 90 3. Providing a Resource List Server with a URI-List 92 A client that wants to create a resource list and subscribe to it, 93 using the mechanism described in this document, constructs a 94 SUBSCRIBE with at least one body, whose disposition is type 95 "recipient-list" as defined in [5], containing the URI-list. The 96 client MUST build the remaining of the SUBSCRIBE request following 97 the rules in RFC 3265 [3]. 99 The client MUST support the "rlmi+xml" format defined in [4] and 100 signal this by including "rlmi+xml" in the Accept header. The client 101 MAY support additional formats and include them in the Accept header 102 field of the SUBSCRIBE. 104 4. URI-List Format 106 The [5] mandates that each URI-list services specification, such as 107 the subscription service defined here, specifies the default format 108 for the recipient-list bodies used within the particular service. 110 The default format for the recipient-list bodies for the subscription 111 service defined in this document is the resource list format defined 112 in [6]. UAs (User Agents) and resource list servers handling 113 recipient-list bodies MUST support this format and MAY support other 114 formats. 116 The Extensible Markup Language (XML) Configuration Access Protocol 117 (XCAP) resource list document provides features, such as hierarchical 118 lists and the ability to include entries by reference relative to the 119 XCAP root URI, that are not needed by the subscription service 120 defined here, which only needs to transfer a flat list of URIs 121 between a UA and the resource list server. Therefore, when using the 122 default resource list document, UAs SHOULD use flat lists (i.e., no 123 hierarchical lists) and SHOULD NOT use elements. 125 A resource list server receiving a URI-list with more information 126 than what has just been described MAY discard all the extra 127 information. 129 Figure 1 shows an example of a flat list that follows the resource 130 list document. 132 133 135 136 137 138 139 140 142 Figure 1: URI-List 144 5. Resource List Server Behavior 146 On reception of a SUBSCRIBE with a URI-list, a resource list server, 147 which chooses to accept the "rlmi+xml" format, MUST comply with [4] 148 for creating the subscription and reporting the changes in the 149 resources within the created dialog. 151 Note that the status code in the response to the SUBSCRIBE does not 152 provide any information about whether or not the resource list server 153 was able to successfully subscribe to the URIs in the URI-list. The 154 client obtains this information in the notifications sent by the 155 server. 157 6. Subsequent SUBSCRIBEs 159 The previous Sections have specified how to include a URI-list in an 160 initial SUBSCRIBE request to a resource list server in order to 161 subscribe to the state of a set of resources. Once the subscription 162 has been created and a dialog between the client and the resource 163 list server has been established, the client may need to send 164 subsequent SUBSCRIBE requests to, for example, extend the duration of 165 the subscription. 167 At this point, there are no semantics associated with resource-list 168 bodies in subsequent SUBSCRIBE requests (although future extensions 169 may define them). Therefore, clients SHOULD NOT include resource- 170 list bodies in subsequent SUBSCRIBE requests to a resource list 171 server. 173 A resource list server receiving a subsequent SUBSCRIBE request with 174 a resource-list body, following standard SIP procedures, rejects it 175 with a 415 (Unsupported Media Type) response. 177 Note that a difference between an initial SUBSCRIBE request and 178 subsequent ones is that while the initial request is sent to the 179 public URI of the resource list, subsequent ones are sent to the 180 URI provided by the server when the dialog was established. 181 Therefore, from the client's point of view, the resource 182 identified by the former URI supports recipient-list bodies while 183 the resource identified by the latter does not support them. 185 7. Option-tag 187 This document defines the 'recipient-list-subscribe' option-tag for 188 use in the Require and Supported SIP header fields. 190 User agent clients generating a SUBSCRIBE with a recipient-list body, 191 as described in previous sections, MUST include this option-tag in a 192 Require header field. User agents that are able to receive and 193 process SUBSCRIBEs with a recipient-list body, as described in 194 previous sections, SHOULD include this option-tag in a Supported 195 header field when responding to OPTIONS requests. 197 8. Providing a URI to Manipulate a Resource List 199 A client may need to manipulate a resource list at a resource list 200 server. The resource list server MAY provide a URI to manipulate the 201 resource list associated with a subscription using the Call-Info 202 header field in the NOTIFY that establishes the subscription. The 203 "purpose" parameter of the Call-Info header field MUST have a value 204 of 'list-management', which we register with the IANA in Section 11. 205 The following is an example of such a header field. 207 Call-Info: 208 ;purpose=list-management 210 The life-time of a resource list to be manipulated by the URI 211 provided by the server is blundled to the life-time of the 212 subscription. That is, the resource list SHOULD be destroyed when 213 the subscription expires or is otherwise terminated. 215 9. Example 217 The following is an example of a SUBSCRIBE request, which carries a 218 URI-list in its body, sent by a UA to a resource list server. 220 SUBSCRIBE sip:rls@example.com SIP/2.0 221 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 222 Max-Forwards: 70 223 To: RLS 224 From: ;tag=ie4hbb8t 225 Call-ID: cdB34qLToC@terminal.example.com 226 CSeq: 1 SUBSCRIBE 227 Contact: 228 Event: presence 229 Expires: 7200 230 Require: recipient-list-subscribe 231 Supported: eventlist 232 Accept: application/cpim-pidf+xml 233 Accept: application/rlmi+xml 234 Accept: multipart/related 235 Accept: multipart/signed 236 Accept: multipart/encrypted 237 Content-Type: application/resource-lists+xml 238 Content-Disposition: recipient-list 239 Content-Length: 337 241 242 244 245 246 247 248 249 251 Figure 2: SUBSCRIBE request 253 10. Security Considerations 255 The Security Considerations Section of [4] discusses security issues 256 related to resource list servers. Resource list servers accepting 257 request-contained URI-lists MUST also follow the security guidelines 258 given in [4]. 260 The Framework and Security Considerations for SIP URI-List Services 261 [5] discusses issues related to SIP URI-list services. Given that a 262 resource list server sending SUBSCRIBEs to a set of users acts as a 263 URI-list service, implementations of resource list servers that 264 handle request-contained URI-lists MUST follow the security-related 265 rules in [5]. These rules include mandatory authentication and 266 authorization of clients, and opt-in lists. 268 11. IANA Considerations 270 The document defines the 'list-management' value for the purpose 271 parameter of the Call-Info header field. A reference to this RFC (in 272 double brackets) needs to be added to the purpose Call-Info parameter 273 entry in the SIP Parameters registry. 275 This document defines the 'recipient-list-subscribe' SIP option-tag 276 in Section 7. It should be registered in the Option Tags subregistry 277 under the SIP parameter registry. The following is the description 278 to be used in the registration. 280 This option-tag is used to ensure that a server can process the 281 'recipient-list' body used in a SUBSCRIBE request. 283 12. Acknowledges 285 Cullen Jennings and Jonathan Rosenberg provided useful comments on 286 this document. 288 13. Normative References 290 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 291 Levels", BCP 14, RFC 2119, March 1997. 293 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 294 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 295 Session Initiation Protocol", RFC 3261, June 2002. 297 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 298 Notification", RFC 3265, June 2002. 300 [4] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation 301 Protocol (SIP) Event Notification Extension for Resource 302 Lists", draft-ietf-simple-event-list-07 (work in progress), 303 January 2005. 305 [5] Camarillo, G. and A. Roach, "Framework and Security 306 Considerations for Session Initiation Protocol (SIP) Uniform 307 Resource Identifier (URI)-List Services", 308 draft-ietf-sipping-uri-services-05 (work in progress), 309 January 2006. 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 (2006). 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.