idnits 2.17.1 draft-camarillo-sipping-adhoc-simple-00.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.5 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 278. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 294), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (March 27, 2004) is 7340 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) == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-04 == Outdated reference: A later version (-02) exists of draft-camarillo-sipping-uri-list-01 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-01) exists of draft-khartabil-sip-policy-uri-call-info-purpose-00 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-02 Summary: 8 errors (**), 0 flaws (~~), 7 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: September 25, 2004 A. Roach 4 dynamicsoft 5 March 27, 2004 7 Subscriptions to Ad-Hoc Resource Lists in the Session Initiation 8 Protocol (SIP) 9 draft-camarillo-sipping-adhoc-simple-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3667. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 25, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes how to create subscriptions to ad-hoc 42 resource lists in SIP. This is done by having the SUBSCRIBE request 43 that requests the creation of the subscription carry a URI list. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Providing a Resource List Server with a URI List . . . . . . . 3 50 4. URI List Format . . . . . . . . . . . . . . . . . . . . . . . 4 51 5. Resource List Server Behavior . . . . . . . . . . . . . . . . 4 52 6. Resource List Life-Time . . . . . . . . . . . . . . . . . . . 4 53 7. Providing a URI to Manipulate a Resource List . . . . . . . . 4 54 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 56 10. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 Normative References . . . . . . . . . . . . . . . . . . . . . 6 58 Informational References . . . . . . . . . . . . . . . . . . . 6 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 60 Intellectual Property and Copyright Statements . . . . . . . . 8 62 1. Introduction 64 Subscriptions to homogeneous resource lists in SIP [2] are described 65 in [3], which assumes that a resource list (i.e., a list of URIs) is 66 represented by a URI (generally a SIP URI). Once a UA obtains the URI 67 that represents a resource list, it can use the mechanisms described 68 in [3] to subscribe to it. 70 For example, let us assume that the resource list identified by the 71 SIP URI sip:my-friends@example.com contains the following URIs: 73 sip:bill@example.com 74 sip:joe@example.com 75 sip:ted@example.com 76 sip:bob@example.com 78 If a UA subscribes to the presece information of 79 sip:my-friends@example.com, it will obtain the presence information 80 of all the resources in the list. 82 In any case, [3] does not tackle list creation. This document 83 describes a way to create an ad-hoc list with a set of resources, and 84 subscribe to it, using a single SIP request. We use the mechanism to 85 carry URI lists in SIP messages described in [4]. 87 2. Terminology 89 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 90 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 91 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 92 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 93 compliant implementations. 95 3. Providing a Resource List Server with a URI List 97 A client that wants to create an ad-hoc resource list and subscribe 98 to it using the mechanism described in this document MUST add a 99 "list" parameter (defined in [4]) to the URI of the resource list and 100 MUST place the resulting URI in the Request-URI of a SUBSCRIBE. The 101 "list" parameter MUST contain a pointer to a URI list that contains 102 the URIs that belong to the resource list. The following is an 103 example of a Request-URI with a "list" parameter. 105 sip:rls@example.com;list="cid:cn35t8jf02@example.com" 107 The client MUST build the remaining of the SUBSCRIBE request 108 following the rules in [3]. 110 4. URI List Format 112 As described in [4], the default format for URI lists in SIP is the 113 XCAP resource list format [6]. Still, specific services need to 114 describe which information clients should include in their URI lists, 115 as described in [4]. 117 UAs subscribing to an ad-hoc resource list SHOULD use flat lists 118 (i.e., no hierarchical lists), SHOULD NOT use any entry's attributes 119 but "uri", and SHOULD NOT include any elements inside entries but 120 "display-name" elements. 122 Resource list servers receiving a URI list with more information than 123 what we have just described SHOULD discard all the extra information. 125 5. Resource List Server Behavior 127 On reception of a SUBSCRIBE with a URI list as described in Section 128 3, a resource list server MUST follow the rules described in [3] to 129 create the subscription, using the URI list just received as the 130 resource list for the subscription. 132 Once the resource list server has created the subscription, it 133 behaves as a regular resource list server and MUST follow the rules 134 in [3]. 136 Note that the status code in the response to the SUBSCRIBE does not 137 provide any information about whether or not the resource list server 138 was able to succesfully subscribe to the URIs in the URI list. The 139 client obtains this information in the NOTIFIES sent by the server. 141 6. Resource List Life-Time 143 The life-time of a resource list created as described in Section 5 is 144 blundled to the life-time of the subscription. That is, the resource 145 list SHOULD be destroyed when the subscription expires or is 146 otherwise terminated. 148 7. Providing a URI to Manipulate a Resource List 150 A client may need to manipulate a resource list at a resource list 151 server. The resource list server MAY provide a URI to manipulate the 152 resource list associated with a subscription using the Call-Info 153 header field [5] in the NOTIFY that establishes the subscription. The 154 "purpose" parameter of the Call-Info header field MUST have a value 155 of "list-management". The following is an example of such a header 156 field. 158 Call-Info: 159 ;purpose=list-management 161 8. Example 163 The following is an example of a SUBSCRIBE request, which carries a 164 URI list in its body, sent by a UA to a resource list server. 166 SUBSCRIBE sip:rls@example.com;list=cid:cn35t8jf02@example.com SIP/2.0 167 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 168 Max-Forwards: 70 169 To: RLS 170 From: ;tag=ie4hbb8t 171 Call-ID: cdB34qLToC@terminal.example.com 172 CSeq: 1 SUBSCRIBE 173 Contact: 174 Event: presence 175 Expires: 7200 176 Supported: eventlist 177 Accept: application/cpim-pidf+xml 178 Accept: application/rlmi+xml 179 Accept: multipart/related 180 Accept: multipart/signed 181 Accept: multipart/encrypted 182 Content-Type: application/resource-lists+xml 183 Content-Length: 315 184 Content-ID: 186 187 188 189 190 191 192 193 194 196 Figure 1: SUBSCRIBE request 198 9. Security Considerations 200 TBD 202 10. Acknowledges 204 Cullen Jennings provided useful comments on this document. 206 Normative References 208 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 209 Levels", BCP 14, RFC 2119, March 1997. 211 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 212 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 213 Session Initiation Protocol", RFC 3261, June 2002. 215 [3] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 216 Protocol (SIP) Event Notification Extension for Resource 217 Lists", draft-ietf-simple-event-list-04 (work in progress), June 218 2003. 220 [4] Camarillo, G., "Providing a Session Initiation Protocol (SIP) 221 Application Server with a List of URIs", 222 draft-camarillo-sipping-uri-list-01 (work in progress), February 223 2004. 225 [5] Khartabil, H., "Conveying a Session Policy Uniform Resource 226 Identifier (URI) in the Session Initiation Protocol (SIP)", 227 draft-khartabil-sip-policy-uri-call-info-purpose-00 (work in 228 progress), February 2004. 230 Informational References 232 [6] Rosenberg, J., "An Extensible Markup Language (XML) 233 Configuration Access Protocol (XCAP) Usage for Presence Lists", 234 draft-ietf-simple-xcap-list-usage-02 (work in progress), 235 February 2004. 237 Authors' Addresses 239 Gonzalo Camarillo 240 Ericsson 241 Hirsalantie 11 242 Jorvas 02420 243 Finland 245 EMail: Gonzalo.Camarillo@ericsson.com 247 Adam Roach 248 dynamicsoft 249 5100 Tennyson Pkwy 250 Suite 1200 251 Plano, TX 75024 252 US 254 EMail: adam@dynamicsoft.com 256 Intellectual Property Statement 258 The IETF takes no position regarding the validity or scope of any 259 Intellectual Property Rights or other rights that might be claimed to 260 pertain to the implementation or use of the technology described in 261 this document or the extent to which any license under such rights 262 might or might not be available; nor does it represent that it has 263 made any independent effort to identify any such rights. Information 264 on the IETF's procedures with respect to rights in IETF Documents can 265 be found in BCP 78 and BCP 79. 267 Copies of IPR disclosures made to the IETF Secretariat and any 268 assurances of licenses to be made available, or the result of an 269 attempt made to obtain a general license or permission for the use of 270 such proprietary rights by implementers or users of this 271 specification can be obtained from the IETF on-line IPR repository at 272 http://www.ietf.org/ipr. 274 The IETF invites any interested party to bring to its attention any 275 copyrights, patents or patent applications, or other proprietary 276 rights that may cover technology that may be required to implement 277 this standard. Please address the information to the IETF at 278 ietf-ipr@ietf.org. 280 Disclaimer of Validity 282 This document and the information contained herein are provided on an 283 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 284 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 285 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 286 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 287 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 288 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 290 Copyright Statement 292 Copyright (C) The Internet Society (2004). This document is subject 293 to the rights, licenses and restrictions contained in BCP 78, and 294 except as set forth therein, the authors retain all their rights. 296 Acknowledgment 298 Funding for the RFC Editor function is currently provided by the 299 Internet Society.