idnits 2.17.1 draft-camarillo-sipping-list-state-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.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 373. ** 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 == Line 331 has weird spacing: '... Change in XM...' == 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 (February 25, 2006) is 6634 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 (-05) exists of draft-ietf-sipping-consent-framework-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-consent-framework (ref. '4') == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-02 -- Possible downref: Normative reference to a draft: ref. '7' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING G. Camarillo 3 Internet-Draft Ericsson 4 Expires: August 29, 2006 February 25, 2006 6 The Session Initiation Protocol (SIP) List State Event Package 7 draft-camarillo-sipping-list-state-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 29, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document defines the SIP List State event package. This event 41 package is used by Resource List Servers to inform user agents about 42 the consent-related status of the entries in one or several resource 43 lists. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 50 4. List State Event Package Definition . . . . . . . . . . . . . 3 51 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 4 52 4.1.1. Event Package Parameters . . . . . . . . . . . . . . . 4 53 4.1.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 4 54 4.1.3. Subscription Duration . . . . . . . . . . . . . . . . 4 55 4.1.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 4 56 4.1.5. Notifier Processing of SUBSCRIBE Requests . . . . . . 5 57 4.1.6. Notifier Generation of NOTIFY Requests . . . . . . . . 5 58 4.1.7. Subscriber Processing of NOTIFY Requests . . . . . . . 5 59 4.1.8. Handling of Forked Requests . . . . . . . . . . . . . 5 60 4.1.9. Rate of Notifications . . . . . . . . . . . . . . . . 5 61 4.1.10. State Agents . . . . . . . . . . . . . . . . . . . . . 5 62 4.1.11. Example . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Usage of the 'list-state' Event Package with the XCAP Diff 64 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. List State RLS Service . . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 Intellectual Property and Copyright Statements . . . . . . . . . . 10 75 1. Introduction 77 The framework for consent-based communications in SIP [4] identifies 78 the need for users manipulating the translation logic at a relay 79 (e.g., adding a new recipient) to be informed about the consent- 80 related status of the recipients of a given translation. That is, 81 the user manipulating the translation logic needs to know which 82 recipients have given the relay permission to send them SIP requests. 84 This document defines a SIP event package whereby user agents can 85 subscribe to the state of a resource list that defines a translation. 86 This state includes the consent related-status of the resources of 87 the resource list. 89 2. Terminology 91 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 92 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 93 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 94 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 95 compliant implementations. 97 3. Overview of Operation 99 A user agent subscribes to a resource list server using the 'list- 100 state' event package. NOTIFY requests within this event package can 101 carry an XML document in the "application/resource-lists+xml" format 102 [5] or in the "application/xcap-diff+xml" format [6]. 104 A document in the "application/resource-lists+xml" format provides 105 the user agent with the whole resource list, including consent- 106 related state information. 108 A document in the "application/xcap-diff+xml" format informs the user 109 agent that the document that described the resource list has changed. 110 The user agent then downloads the document in the "application/ 111 resource-lists+xml" format from the permission server using XCAP. 113 4. List State Event Package Definition 115 This section provides the details for defining a SIP [2] event 116 notification package, as specified by RFC 3265 [3]. 118 4.1. Event Package Name 120 The name of this event package is "list-state". This package name is 121 carried in the Event and Allow-Events header, as defined in RFC 3265 122 [3]. 124 4.1.1. Event Package Parameters 126 This package does not define any event package parameters. 128 4.1.2. SUBSCRIBE Bodies 130 A SUBSCRIBE for 'list-state' events MAY contain a body. This body 131 would serve the purpose of filtering the subscription. The 132 definition of such a body is outside the scope of this specification. 134 A SUBSCRIBE for the 'list-state' package MAY be sent without a body. 135 This implies that the default session policy filtering policy has 136 been requested. The default policy is that notifications are 137 generated every time there is any change in the state of a resource 138 in the list. 140 4.1.3. Subscription Duration 142 The default expiration time for a subscription is one hour (3600 143 seconds). 145 4.1.4. NOTIFY Bodies 147 In this event package, the body of the notifications contains a 148 resource list document. This document describes a resource list and 149 the consent-related state of its resources. All subscribers and 150 notifiers MUST support the "application/resource-lists+xml" data 151 format [5] and its extension to carry consent-related state 152 information [7]. The subscribe request MAY contain an Accept header 153 field. If no such header field is present, it has a default value of 154 "application/resource-lists+xml". If the header field is present, it 155 MUST include "application/resource-lists+xml", and MAY include any 156 other types capable of representing translation state. 158 OPEN ISSUE: do we need to discuss how to use content indirection 159 here? 161 Additionally, all subscribers and notifiers SHOULD support the 162 "application/xcap-diff+xml" format [6]. Section 5 discusses the 163 usage of the 'list-state' event package with this format. 165 4.1.5. Notifier Processing of SUBSCRIBE Requests 167 The state of a resource list defining a translation can reveal 168 sensitive information. Therefore, all subscriptions SHOULD be 169 authenticated and then authorized before approval. Authorization 170 policy is at the discretion of the administrator. 172 4.1.6. Notifier Generation of NOTIFY Requests 174 A notifier for the List State event package SHOULD include the 175 element [7] when the framework for consent-based 176 communications in SIP is used. When present, the 177 element MUST be positioned as an instance of the element within 178 the element. 180 Notifications SHOULD be generated for the List State package whenever 181 there is a change in the resource-list state. 183 4.1.7. Subscriber Processing of NOTIFY Requests 185 NOTIFY requests contain the full resource-list state. The subscriber 186 does not need to perform any type of information aggregation. 188 4.1.8. Handling of Forked Requests 190 The state of a given resource list is normally handled by a server 191 and stored in a repository. Therefore, there is usually a single 192 place where the resource-list state is resident. This implies that a 193 subscription for this information is readily handled by a single 194 element with access to this repository. There is, therefore, no 195 compelling need for a subscription to session policy information to 196 fork. As a result, a subscriber MUST NOT create multiple dialogs as 197 a result of a single subscription request. The required processing 198 to guarantee that only a single dialog is established is described in 199 Section 4.4.9 of RFC 3265 [3]. 201 4.1.9. Rate of Notifications 203 For reasons of congestion control, it is important that the rate of 204 notifications not become excessive. As a result, it is RECOMMENDED 205 that the server doesn't generate notifications for a single 206 subscriber at a rate faster than once every 5 seconds. 208 4.1.10. State Agents 210 State agents have no role in the handling of this package. 212 4.1.11. Example 214 The following is an example of an "application/xcap-diff+xml" 215 document that carries consent-related state information using 216 elements: 218 219 222 223 224 Bill Doe 225 pending 226 227 228 Joe Smith 229 pending 230 231 232 Nancy Gross 233 granted 234 235 236 238 5. Usage of the 'list-state' Event Package with the XCAP Diff Format 240 As discussed in Section 4.1.4, if a client subscribing to the 'list- 241 state' event package an Accept header field including the MIME type 242 "application/xcap-diff+xml", the permission server has the option of 243 returning documents in this format (instead of in the 'application/ 244 list-state+xml' format). 246 Upon initial subscription, the permission server does not know which 247 instance of the resource list document for the user (where each 248 instance is identified by an etag) the client currently posessses, if 249 any. Indeed, upon startup, the client will not have any documents. 251 The initial NOTIFY request in this case MUST include a 252 element for the resource list. The "previous-etag" attribute MUST be 253 absent, and the "new-etag" attribute MUST be present and contain the 254 entity tag for the current version of the document. An XCAP diff 255 document structured this way is called a "reference" XCAP diff 256 document. It establishes the baseline etag and document URI for the 257 document covered by the subscription. 259 Upon receipt of this document, the client can determine whether its 260 local instance document, if any, matches the etag in the XCAP diff 261 document. If they do not match, the client SHOULD perform a 262 conditional GET for each document. The document URI is constructed 263 by appending the XCAP root in the "xcap-root" attribute of the element to the escape coded "doc-selector" from the 265 element. The request is made conditional by including an If-Match 266 header field, with the value of the etag from the element. 267 So long as the documents haven't changed between the NOTIFY and the 268 GET, the client will obtain the reference version that the server 269 will use for subsequent notifications. 271 If the conditional GET should fail, the client SHOULD generate a 272 SUBSCRIBE refresh request to trigger a new NOTIFY. The server will 273 always generate a "reference" XML diff document on receipt of a 274 SUBSCRIBE refresh. This establishes a new baseline etag, and the 275 client can then attempt to do another fetch. 277 Once the client has obtained the version of the document identified 278 in the reference XML diff, it can process NOTIFY requests on that 279 subscription. To process the NOTIFY requests, it makes sure that its 280 current version matches the version in the "previous-etag" attribute 281 of the element. If not, the client can then fetch the 282 updated document from the server. If they do match, the client has 283 the most current version. 285 6. List State RLS Service 287 TBD: Define the 'List State' RLS service [5]. Example: 289 290 presence 291 list state 292 294 7. IANA Considerations 296 TBD. 298 8. Security Considerations 300 TBD. 302 9. Acknowledgements 304 TBD. 306 10. References 308 10.1. Normative References 310 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 311 Levels", BCP 14, RFC 2119, March 1997. 313 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 314 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 315 Session Initiation Protocol", RFC 3261, June 2002. 317 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 318 Notification", RFC 3265, June 2002. 320 [4] Rosenberg, J., "A Framework for Consent-Based Communications in 321 the Session Initiation Protocol (SIP)", 322 draft-ietf-sipping-consent-framework-03 (work in progress), 323 October 2005. 325 [5] Rosenberg, J., "Extensible Markup Language (XML) Formats for 326 Representing Resource Lists", 327 draft-ietf-simple-xcap-list-usage-05 (work in progress), 328 February 2005. 330 [6] Rosenberg, J., "An Extensible Markup Language (XML) Document 331 Format for Indicating A Change in XML Configuration Access 332 Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-02 (work 333 in progress), October 2005. 335 [7] Camarillo, G., "Session Initiation Protocol (SIP) Registration 336 Event Package Extension for Consent-Based Communications", 337 draft-camarillo-sipping-consent-reg-event-00 (work in progress), 338 February 2006. 340 10.2. Informative References 341 Author's Address 343 Gonzalo Camarillo 344 Ericsson 345 Hirsalantie 11 346 Jorvas 02420 347 Finland 349 Email: Gonzalo.Camarillo@ericsson.com 351 Intellectual Property Statement 353 The IETF takes no position regarding the validity or scope of any 354 Intellectual Property Rights or other rights that might be claimed to 355 pertain to the implementation or use of the technology described in 356 this document or the extent to which any license under such rights 357 might or might not be available; nor does it represent that it has 358 made any independent effort to identify any such rights. Information 359 on the procedures with respect to rights in RFC documents can be 360 found in BCP 78 and BCP 79. 362 Copies of IPR disclosures made to the IETF Secretariat and any 363 assurances of licenses to be made available, or the result of an 364 attempt made to obtain a general license or permission for the use of 365 such proprietary rights by implementers or users of this 366 specification can be obtained from the IETF on-line IPR repository at 367 http://www.ietf.org/ipr. 369 The IETF invites any interested party to bring to its attention any 370 copyrights, patents or patent applications, or other proprietary 371 rights that may cover technology that may be required to implement 372 this standard. Please address the information to the IETF at 373 ietf-ipr@ietf.org. 375 Disclaimer of Validity 377 This document and the information contained herein are provided on an 378 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 379 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 380 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 381 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 382 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 383 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 385 Copyright Statement 387 Copyright (C) The Internet Society (2006). This document is subject 388 to the rights, licenses and restrictions contained in BCP 78, and 389 except as set forth therein, the authors retain all their rights. 391 Acknowledgment 393 Funding for the RFC Editor function is currently provided by the 394 Internet Society.