idnits 2.17.1 draft-camarillo-sipping-grant-permission-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 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 492. ** 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 455 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 6629 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 2141 (ref. '2') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '3') ** Obsolete normative reference: RFC 3265 (ref. '5') (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. '8') == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-02 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 7 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) Grant Permission Event Package 7 draft-camarillo-sipping-grant-permission-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 Grant Permission event package. This 41 event package is used by permission servers to inform user agents 42 about translations for which a particular user agent needs to give 43 consent. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 50 4. Grant Permission Event Package Definition . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 6 61 4.1.10. State Agents . . . . . . . . . . . . . . . . . . . . . 6 62 5. Grant Permission Document Format . . . . . . . . . . . . . . . 6 63 5.1. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. XCAP Usage for Manipulating Grant Permission Documents . . . . 8 66 6.1. Application Usage ID . . . . . . . . . . . . . . . . . . . 8 67 6.2. Structure of Manipulated Grant Permission Information . . 8 68 6.3. Additional Constraints . . . . . . . . . . . . . . . . . . 8 69 6.4. Resource Interdependencies . . . . . . . . . . . . . . . . 8 70 6.5. Naming Conventions . . . . . . . . . . . . . . . . . . . . 8 71 6.6. Authorization Policies . . . . . . . . . . . . . . . . . . 8 72 6.7. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Usage of the 'grant-permission' Event Package with the 74 XCAP Diff Format . . . . . . . . . . . . . . . . . . . . . . . 9 75 8. Permission Server Behavior . . . . . . . . . . . . . . . . . . 10 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 12.2. Informative References . . . . . . . . . . . . . . . . . . 11 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 Intellectual Property and Copyright Statements . . . . . . . . . . 13 85 1. Introduction 87 The framework for consent-based communications in SIP [8] identifies 88 the need for users to be informed about translations for which they 89 need to give consent. Users are informed about these translations by 90 receiving CONSENT requests from the relays performing the 91 translations. However, users are not on-line all the time and, so, 92 sometimes are not able to receive CONSENT requests. 94 Therefore, there is a need for a means to handle incoming CONSENT 95 requests even when users are off-line. Permission servers are 96 defined as network elements that act as SIP user agents and handle 97 CONSENT requests for a user. 99 Permission servers inform users about new incoming CONSENT requests 100 using the 'grant-permission' event package, which is defined in this 101 document. 103 2. Terminology 105 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 106 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 107 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 108 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 109 compliant implementations. 111 3. Overview of Operation 113 A user agents subscribes to its permission server using the 'grant- 114 permission' event package. NOTIFY requests within this event package 115 can carry an XML document in the "application/grant-permission+xml" 116 format, which is defined in Section 5, or in the "application/ 117 xcap-diff+xml" format [9]. 119 A document in the "application/grant-permission+xml" format informs 120 the user agent about permission requests received so far. For each 121 permission request that has been received by the permission server, 122 the document provides the user agent with the permission document 123 carried in the CONSENT request and with the URI in the CONSENT 124 request's Permission-Upload header field. 126 A document in the "application/xcap-diff+xml" format informs the user 127 agent that the document where the permission server stores pending 128 permission requests for the user has changed. The user agent then 129 downloads the document in the "application/grant-permission+xml" 130 format from the permission server using XCAP. 132 Once the user agent handles a permission request (e.g., it gives or 133 denies permission for the translation described in the permission 134 request), the user agent needs to delete the permission request from 135 the permission server. The user agent uses XCAP to delete permission 136 requests from a permission server. 138 OPEN ISSUE: this forces UAs to support XCAP (at least to delete 139 already-handled permission requests). If this was a problem, 140 permission servers could implement some type of garbage collection 141 mechanism. For example, they could delete automatically those 142 permission requests the users already knows about (i.e., they have 143 been sent in a NOTIFY request to the user agent). 145 4. Grant Permission Event Package Definition 147 This section provides the details for defining a SIP [4] event 148 notification package, as specified by RFC 3265 [5]. 150 4.1. Event Package Name 152 The name of this event package is "grant-permission". This package 153 name is carried in the Event and Allow-Events header, as defined in 154 RFC 3265 [5]. 156 4.1.1. Event Package Parameters 158 This package does not define any event package parameters. 160 4.1.2. SUBSCRIBE Bodies 162 A SUBSCRIBE for 'grant-permission' events MAY contain a body. This 163 body would serve the purpose of filtering the subscription. The 164 definition of such a body is outside the scope of this specification. 166 A SUBSCRIBE for the 'grant-permission' package MAY be sent without a 167 body. This implies that the default session policy filtering policy 168 has been requested. The default policy is that notifications are 169 generated every time there is any change in the translation state for 170 the user. 172 4.1.3. Subscription Duration 174 The default expiration time for a subscription to a conference is one 175 hour (3600 seconds). 177 4.1.4. NOTIFY Bodies 179 In this event package, the body of the notifications contains a grant 180 permission document. This document describes the translation state 181 of a user. All subscribers and notifiers MUST support the 182 "application/grant-permission+xml" data format described in 183 Section 5. The subscribe request MAY contain an Accept header field. 184 If no such header field is present, it has a default value of 185 "application/grant-permission+xml". If the header field is present, 186 it MUST include "application/grant-permission+xml", and MAY include 187 any other types capable of representing translation state. 189 OPEN ISSUE: do we need to discuss how to use content indirection 190 here? 192 Additionally, all subscribers and notifiers SHOULD support the 193 "application/xcap-diff+xml" format [9]. Section 7 discusses the 194 usage of the 'grant-permission' event package with this format. 196 4.1.5. Notifier Processing of SUBSCRIBE Requests 198 The translation state can reveal sensitive information. Therefore, 199 all subscriptions SHOULD be authenticated and then authorized before 200 approval. Authorization policy is at the discretion of the 201 administrator. 203 4.1.6. Notifier Generation of NOTIFY Requests 205 Notifications SHOULD be generated for the Grant Permission package 206 whenever there is a change in the translation state for the user. 208 4.1.7. Subscriber Processing of NOTIFY Requests 210 NOTIFY requests contain the full translation state. The subscriber 211 does not need to perform any type of information aggregation. 213 4.1.8. Handling of Forked Requests 215 The translation state of a user is normally handled by a permission 216 server and stored in a repository. Therefore, there is usually a 217 single place where the translation state of a user is resident. This 218 implies that a subscription for this information is readily handled 219 by a single element with access to this repository. There is, 220 therefore, no compelling need for a subscription to session policy 221 information to fork. As a result, a subscriber MUST NOT create 222 multiple dialogs as a result of a single subscription request. The 223 required processing to guarantee that only a single dialog is 224 established is described in Section 4.4.9 of RFC 3265 [5]. 226 4.1.9. Rate of Notifications 228 For reasons of congestion control, it is important that the rate of 229 notifications not become excessive. As a result, it is RECOMMENDED 230 that the server doesn't generate notifications for a single 231 subscriber at a rate faster than once every 5 seconds. 233 4.1.10. State Agents 235 State agents have no role in the handling of this package. 237 5. Grant Permission Document Format 239 Grant Permission information is an XML document that MUST be well- 240 formed and valid. It MUST be based on Extensible Markup Language 241 (XML) 1.0 and MUST be encoded using UTF-8 [6]. 243 This specification makes use of XML namespaces for identifying Grant 244 Permission documents. The namespace URI for elements defined by this 245 specification is a URN [2], using the namespace identifier 'ietf' 246 defined by [3] and extended by [7]. This URN is: 248 urn:ietf:params:xml:ns:grant-permission 250 Grant Permission documents are identified with the MIME type 251 "application/grant-permission+xml" and are instances of the XML 252 schema defined in Section 5.1. 254 A Grant Permission document begins with the root element tag . It consists of zero or more elements. Each 256 element contains a element and an element. 257 The element contains a permission document describing the 258 permission being requested. The element contains the URI 259 where the permission document granting or denying permission needs to 260 be uploaded. 262 5.1. XML Schema 264 Implementations according to this specification MUST comply to the 265 following XML Schema, which defines the constraints of the Grant 266 Permission document: 268 269 277 TBD. 279 281 5.2. Example 283 The following is an example of a Grant Permission document: 285 286 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 pending 309 310 311 312 sip:upload@example.com 313 315 317 6. XCAP Usage for Manipulating Grant Permission Documents 319 6.1. Application Usage ID 321 XCAP requires application usages to define a unique application usage 322 ID (AUID) in either the IETF tree or a vendor tree. This 323 specification defines the 'grant-permission-manipulation' AUID within 324 the IETF tree, via the IANA registration in the Section TBD. 326 6.2. Structure of Manipulated Grant Permission Information 328 The XML Schema for grant permission documents is defined in 329 Section 5.1. The namespace URI for the schema is: 331 urn:ietf:params:xml:ns:grant-permission 333 6.3. Additional Constraints 335 There are no constraints on the document beyond those described by 336 the XML schema and its description. 338 6.4. Resource Interdependencies 340 There are no resource interdependencies that need to be defined for 341 this application usage. 343 6.5. Naming Conventions 345 There are no naming conventions that need to be defined for this 346 application usage. 348 6.6. Authorization Policies 350 This application usage does not modify the default XCAP authorization 351 policy, which allows only a user (owner) to read, write or modify 352 their own documents. A server can allow privileged users to modify 353 documents that they do not own, but the establishment and indication 354 of such policies is outside the scope of this document. 356 6.7. Example 358 TBD. 360 7. Usage of the 'grant-permission' Event Package with the XCAP Diff 361 Format 363 As discussed in Section 4.1.4, if a client subscribing to the 'grant- 364 permission' event package an Accept header field including the MIME 365 type "application/xcap-diff+xml", the permission server has the 366 option of returning documents in this format (instead of in the 367 'application/grant-permission+xml' format). 369 Upon initial subscription, the permission server does not know which 370 instance of the grant permission document for the user (where each 371 instance is identified by an etag) the client currently posesses, if 372 any. Indeed, upon startup, the client will not have any documents. 374 The initial NOTIFY request in this case MUST include a 375 element the grant permission document for the user. The "previous- 376 etag" attribute MUST be absent, and the "new-etag" attribute MUST be 377 present and contain the entity tag for the current version of the 378 document. An XCAP diff document structured this way is called a 379 "reference" XCAP diff document. It establishes the baseline etag and 380 document URI for the document covered by the subscription. 382 Upon receipt of this document, the client can determine whether its 383 local instance document, if any, matches the etag in the XCAP diff 384 document. If they do not match, the client SHOULD perform a 385 conditional GET for each document. The document URI is constructed 386 by appending the XCAP root in the "xcap-root" attribute of the element to the escape coded "doc-selector" from the 388 element. The request is made conditional by including an If-Match 389 header field, with the value of the etag from the element. 390 So long as the documents haven't changed between the NOTIFY and the 391 GET, the client will obtain the reference version that the server 392 will use for subsequent notifications. 394 If the conditional GET should fail, the client SHOULD generate a 395 SUBSCRIBE refresh request to trigger a new NOTIFY. The server will 396 always generate a "reference" XML diff document on receipt of a 397 SUBSCRIBE refresh. This establishes a new baseline etag, and the 398 client can then attempt to do another fetch. 400 Once the client has obtained the version of the document identified 401 in the reference XML diff, it can process NOTIFY requests on that 402 subscription. To process the NOTIFY requests, it makes sure that its 403 current version matches the version in the "previous-etag" attribute 404 of the element. If not, the client can then fetch the 405 updated document from the server. If they do match, the client has 406 the most current version. 408 8. Permission Server Behavior 410 TBD. 412 9. IANA Considerations 414 TBD. 416 10. Security Considerations 418 TBD. 420 11. Acknowledgements 422 TBD. 424 12. References 426 12.1. Normative References 428 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 429 Levels", BCP 14, RFC 2119, March 1997. 431 [2] Moats, R., "URN Syntax", RFC 2141, May 1997. 433 [3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 434 August 1999. 436 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 437 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 438 Session Initiation Protocol", RFC 3261, June 2002. 440 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 441 Notification", RFC 3265, June 2002. 443 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 444 STD 63, RFC 3629, November 2003. 446 [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 447 January 2004. 449 [8] Rosenberg, J., "A Framework for Consent-Based Communications in 450 the Session Initiation Protocol (SIP)", 451 draft-ietf-sipping-consent-framework-03 (work in progress), 452 October 2005. 454 [9] Rosenberg, J., "An Extensible Markup Language (XML) Document 455 Format for Indicating A Change in XML Configuration Access 456 Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-02 (work 457 in progress), October 2005. 459 12.2. Informative References 460 Author's Address 462 Gonzalo Camarillo 463 Ericsson 464 Hirsalantie 11 465 Jorvas 02420 466 Finland 468 Email: Gonzalo.Camarillo@ericsson.com 470 Intellectual Property Statement 472 The IETF takes no position regarding the validity or scope of any 473 Intellectual Property Rights or other rights that might be claimed to 474 pertain to the implementation or use of the technology described in 475 this document or the extent to which any license under such rights 476 might or might not be available; nor does it represent that it has 477 made any independent effort to identify any such rights. Information 478 on the procedures with respect to rights in RFC documents can be 479 found in BCP 78 and BCP 79. 481 Copies of IPR disclosures made to the IETF Secretariat and any 482 assurances of licenses to be made available, or the result of an 483 attempt made to obtain a general license or permission for the use of 484 such proprietary rights by implementers or users of this 485 specification can be obtained from the IETF on-line IPR repository at 486 http://www.ietf.org/ipr. 488 The IETF invites any interested party to bring to its attention any 489 copyrights, patents or patent applications, or other proprietary 490 rights that may cover technology that may be required to implement 491 this standard. Please address the information to the IETF at 492 ietf-ipr@ietf.org. 494 Disclaimer of Validity 496 This document and the information contained herein are provided on an 497 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 498 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 499 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 500 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 501 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 502 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 504 Copyright Statement 506 Copyright (C) The Internet Society (2006). This document is subject 507 to the rights, licenses and restrictions contained in BCP 78, and 508 except as set forth therein, the authors retain all their rights. 510 Acknowledgment 512 Funding for the RFC Editor function is currently provided by the 513 Internet Society.