idnits 2.17.1 draft-ietf-webdav-quota-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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 410. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters 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 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 (January 19, 2005) is 7034 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 2518 (Obsoleted by RFC 4918) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WWW Distributed Authoring and B. Korver 3 Versioning (webdav) Xythos 4 Internet-Draft L. Dusseault 5 Expires: July 23, 2005 OSAF 6 January 19, 2005 8 Quota and Size Properties for DAV Collections 9 draft-ietf-webdav-quota-05 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 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 23 Internet-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 July 23, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 WebDAV servers are frequently deployed with quota (size) limitations. 45 This document discusses the properties and minor behaviors needed for 46 clients to interoperate with quota (size) implementations on WebDAV 47 repositories. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 53 1.2 Requirement for quotas . . . . . . . . . . . . . . . . . . 3 54 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . 3 55 3. DAV:quota-available-bytes . . . . . . . . . . . . . . . . . 4 56 4. DAV:quota-used-bytes . . . . . . . . . . . . . . . . . . . . 5 57 5. Example PROPFIND request and response . . . . . . . . . . . 6 58 6. Error reporting . . . . . . . . . . . . . . . . . . . . . . 6 59 7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 8. Security Considerations . . . . . . . . . . . . . . . . . . 8 61 9. Internationalization Considerations . . . . . . . . . . . . 8 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 63 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 12.1 Normative References . . . . . . . . . . . . . . . . . . 8 66 12.2 Informative References . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 68 Intellectual Property and Copyright Statements . . . . . . . 10 70 1. Introduction 72 1.1 Notational Conventions 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 1.2 Requirement for quotas 80 WebDAV servers based on [RFC2518] have been implemented and deployed 81 with quota restrictions on collections and users, so it makes sense 82 to standardize this functionality to improve user experience and 83 client interoperability. This specification requires WebDAV because 84 it requires PROPFIND support and relies on the WebDAV definition of 85 collections and properties, including the definitions for live and 86 protected properties (see section 1.4.2 of [RFC3253] for the 87 definition of protected properties). 89 The reasons why WebDAV servers frequently have quotas enforced are 90 the same reasons why any storage system comes with quotas. 92 o Sometimes the storage service charges according to quota 94 o Sometimes the storage service is provided free, but the storage 95 service provider has limited storage space (e.g. 96 university-provided student accounts) 98 o Even in cases where the storage can be upgraded, the storage 99 managers may choose to limit quota in order to encourage users to 100 limit the files they store on the system and to clean up obsolete 101 files. (e.g. IT departments within corporations) 103 In order to work best with repositories that support quotas, client 104 software should be able to determine and display the 105 DAV:quota-available-bytes on collections. Further, client software 106 should have some way of fairly reliably determining how much storage 107 space is already counted towards that quota. 109 2. Solution Overview 111 The approach to meeting the requirements and scenarios outlined above 112 is to define two live properties. This specification can be met on a 113 server by implementing both DAV:quota-available-bytes and 114 DAV:quota-used-bytes on collections only. Implementing both 115 DAV:quota-available-bytes and DAV:quota-used-bytes on all resources 116 is RECOMMENDED. 118 A PROPFIND request SHOULD NOT return any of the 119 properties defined by this document. However, these property names 120 MUST be returned in a request for a resource that 121 supports the properties, except in the case of infinite limits which 122 are explained below. 124 The DAV:quota-available-bytes and DAV:quota-used-bytes definitions 125 below borrow heavily from the quota definitions in the NFS [RFC3530] 126 specification. 128 3. DAV:quota-available-bytes 130 Name: quota-available-bytes 132 Namespace: DAV: 134 Purpose: Indicates the maximum amount of additional storage available 135 to be allocated to a resource. 137 DTD: 139 The DAV:quota-available-bytes property value is the value in octets 140 representing the amount of additional disk space beyond the current 141 allocation that can be allocated to this resource before further 142 allocations will be refused. It is understood that this space may be 143 consumed by allocations to other resources. 145 Support for this property is REQUIRED on collections, and OPTIONAL on 146 other resources. A server SHOULD implement this property for each 147 resource that has the DAV:quota-used-bytes property. 149 Clients SHOULD expect that as the DAV:quota-available-bytes on a 150 resource approaches 0, further allocations to that resource may be 151 refused. A value of 0 indicates that users will probably not be able 152 to perform operations that write additional information (e.g. a PUT 153 inside a collection), but may be able to replace through overwrite an 154 existing resource of equal size. 156 Note that there may be a number of distinct but overlapping limits, 157 which may even include physical media limits. When reporting 158 DAV:quota-available-bytes, the server is at liberty to choose any of 159 those limits but SHOULD do so in a repeatable way. The rule may be 160 configured per repository, or may be "choose the smallest number". 162 If a resource has no quota enforced or unlimited storage ("infinite 163 limits"), the server MAY choose not to return this property (404 Not 164 Found response in Multi-Status), although this specification 165 RECOMMENDS that servers return some appropriate value (e.g. the 166 amount of free disc space). A client cannot entirely assume that 167 there is no quota enforced on a resource that does not have this 168 property, but might as well act as if there is no quota. 170 The value of this property is protected (see section 1.4.2 of 171 [RFC3253] for the definition of protected properties). A 403 172 Forbidden response is RECOMMENDED for attempts to write a protected 173 property, and the server SHOULD include an XML error body as defined 174 by DeltaV [RFC3253] with the 175 precondition tag. 177 4. DAV:quota-used-bytes 179 Name: quota-used-bytes 181 Namespace: DAV: 183 Purpose: Contains the amount of storage counted against the quota on 184 a resource. 186 DTD: 188 The DAV:quota-used-bytes value is the value in octets representing 189 the amount of space used by this resource and possibly a number of 190 other similar files or directories, where the set of "similar" meets 191 at least the criterion that allocating space to any resource in the 192 set will count against the DAV:quota-available-bytes. It MUST 193 include the total count including usage derived from sub-resources if 194 appropriate. It SHOULD include metadata storage size if metadata 195 storage is counted against the DAV:quota-available-bytes. 197 Note that there may be a number of distinct but overlapping sets of 198 files or directories for which a DAV:quota-used-bytes is maintained 199 (e.g. "all files with a given owner", "all files with a given group 200 owner", etc.). The server is at liberty to choose any of those sets 201 but SHOULD do so in a repeatable way. The rule may be configured per 202 repository. 204 Support for this property is REQUIRED on collections, and OPTIONAL on 205 other resources. A server SHOULD implement this property for each 206 resource that has the DAV:quota-available-bytes property. 208 Support for this property enhances the client experience, because 209 together with DAV:quota-available-bytes, the client has a chance of 210 managing its files to avoid running out of allocated storage space. 211 Clients may not be able to calculate the value as accurately on their 212 own, depending on how total space used is calculated by the server. 214 5. Example PROPFIND request and response 216 Request: 218 PROPFIND /~milele/public/ HTTP/1.1 219 Depth: 0 220 Host: www.example.com 221 Content-Type: text/xml 222 Content-Length: xxx 224 225 226 227 229 Response: 231 HTTP/1.1 207 Multi-Status 232 Date: Tue, 16 Oct 2001 22:13:39 GMT 233 Content-Length: xxx 234 Content-Type: text/xml; charset=UTF-8 236 237 238 239 http://www.example.com/~milele/public/ 240 241 242 596650 243 403350 244 245 HTTP/1.1 200 OK 246 247 248 250 6. Error reporting 252 WebDAV [RFC2518] defines the status code 507 (Insufficient Storage). 253 This status code SHOULD be used when a client request (e.g. a PUT, 254 PROPFIND, MKCOL, MOVE or COPY) fails because it would exceed their 255 allotted quota. In order to differentiate the response from other 256 storage problems, the server SHOULD include an XML error body as 257 defined by DeltaV [RFC3253] with the 258 precondition tag. 260 Example error response: 262 HTTP/1.1 507 Insufficient Storage 263 Content-Length: xxx 264 Content-Type: text/xml 266 267 268 269 271 7. Notes 273 Server implementations store and account for their data in many 274 different ways. Some of the challenges: 276 o Some server implementations find it prohibitive to count storage 277 used for metadata, others may choose to do so for better 278 accounting. 280 o Older versions of resources may be stored as well. 282 o Variants of one resource may exist with different content lengths 284 o Content may be dynamically generated. 286 o Resource bodies can be compressed 288 o Some resources may be stored for "free", not counting against 289 quota. 291 Since server storage accounting can vary so much, clients should 292 expect the following: 294 o The size of a file on the client's file system, or in a PUT 295 message, may not correspond to the amount of storage required by 296 the server to store the resource. Thus, the client cannot predict 297 with 100% accuracy whether a given file will be allowed given the 298 storage quota. 300 o Deleting or overwriting a resource may not free up the same amount 301 of storage as indicated by the DAV:getcontentlength property 302 defined in [RFC2518] for the resource. If deleting a resource 303 does not free up any space, the file may have been moved to a 304 "trash" folder or "recycle bin", or retained as in versioning 305 systems ([RFC3253]). 307 o The total size of a collection, DAV:quota-used-bytes, may not be a 308 sum of the DAV:getcontentlength properties for resources stored in 309 the collection. 311 o On some systems where quota is counted by collection and not by 312 user, a quota on a sub-collection may be larger than the quota on 313 the parent collection that contains it. For example, the quota on 314 /~milele/ may be 100 MB, but the quota on /~milele/public/ may be 315 unlimited. This allows the space used by /~milele/public/ to be 316 as large as the quota on /~milele/ allows (depending on the other 317 contents of /~milele/) even if the quota on /~milele/ is changed. 318 Thus, even when the quota on a parent collection is changed, it is 319 not necessarily required to change the quota on every child or 320 descendant collection. 322 8. Security Considerations 324 A hacker may prefer to store files in collections with a large quota. 325 This isn't strictly a security concern because it doesn't make it any 326 easier to store files. On the other hand, the DAV:quota-used-bytes 327 property may make it easier to detect tampering or misuse. 329 9. Internationalization Considerations 331 Quota is counted in Arabic numerals expressed in strings. There are 332 no internationalization considerations. 334 10. IANA Considerations 336 There are no IANA considerations. 338 11. Acknowledgements 340 Stefan Eissing, Geoff Clemm, Jim Luther, Julian Reschke, Jim 341 Whitehead, among others, have provided valuable comments on this 342 document. 344 12. References 346 12.1 Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 352 Jensen, "HTTP Extensions for Distributed Authoring -- 353 WebDAV", RFC 2518, February 1999. 355 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. 356 Whitehead, "Versioning Extensions to WebDAV (Web 357 Distributed Authoring and Versioning)", RFC 3253, March 358 2002. 360 12.2 Informative References 362 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 363 Beame, C., Eisler, M. and D. Noveck, "Network File System 364 (NFS) version 4 Protocol", RFC 3530, April 2003. 366 Authors' Addresses 368 Brian Korver 369 Xythos Software 370 One Bush Street 371 Suite 600 372 San Francisco, CA 94104 373 US 375 Phone: +1 415 248-3800 376 Email: briank@xythos.com 378 Lisa Dusseault 379 Open Source Applications Foundation 380 543 Howard Street 381 5th Floor 382 San Francisco, CA 94105 383 US 385 Phone: +1 415 946-3040 386 Email: lisa@osafoundation.org 388 Intellectual Property Statement 390 The IETF takes no position regarding the validity or scope of any 391 Intellectual Property Rights or other rights that might be claimed to 392 pertain to the implementation or use of the technology described in 393 this document or the extent to which any license under such rights 394 might or might not be available; nor does it represent that it has 395 made any independent effort to identify any such rights. Information 396 on the procedures with respect to rights in RFC documents can be 397 found in BCP 78 and BCP 79. 399 Copies of IPR disclosures made to the IETF Secretariat and any 400 assurances of licenses to be made available, or the result of an 401 attempt made to obtain a general license or permission for the use of 402 such proprietary rights by implementers or users of this 403 specification can be obtained from the IETF on-line IPR repository at 404 http://www.ietf.org/ipr. 406 The IETF invites any interested party to bring to its attention any 407 copyrights, patents or patent applications, or other proprietary 408 rights that may cover technology that may be required to implement 409 this standard. Please address the information to the IETF at 410 ietf-ipr@ietf.org. 412 Disclaimer of Validity 414 This document and the information contained herein are provided on an 415 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 416 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 417 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 418 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 419 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 420 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 422 Copyright Statement 424 Copyright (C) The Internet Society (2005). This document is subject 425 to the rights, licenses and restrictions contained in BCP 78, and 426 except as set forth therein, the authors retain all their rights. 428 Acknowledgment 430 Funding for the RFC Editor function is currently provided by the 431 Internet Society.