idnits 2.17.1 draft-ietf-webdav-quota-07.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 450. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 440. ** 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 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 (April 27, 2005) is 6929 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WWW Distributed Authoring and B. Korver 2 Versioning (webdav) Network Resonance 3 Internet-Draft L. Dusseault 4 Expires: October 29, 2005 OSAF 5 April 27, 2005 7 Quota and Size Properties for DAV Collections 8 draft-ietf-webdav-quota-07 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 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 28 http://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 October 29, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 WebDAV servers are frequently deployed with quota (size) limitations. 42 This document discusses the properties and minor behaviors needed for 43 clients to interoperate with quota (size) implementations on WebDAV 44 repositories. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 50 1.2 Requirement for quotas . . . . . . . . . . . . . . . . . . 3 51 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . 3 52 3. DAV:quota-available-bytes . . . . . . . . . . . . . . . . . 4 53 4. DAV:quota-used-bytes . . . . . . . . . . . . . . . . . . . . 5 54 5. Example PROPFIND request and response . . . . . . . . . . . 6 55 6. Error reporting . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 8. Security Considerations . . . . . . . . . . . . . . . . . . 9 58 9. Internationalization Considerations . . . . . . . . . . . . 9 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 60 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 61 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 12.1 Normative References . . . . . . . . . . . . . . . . . . 9 63 12.2 Informative References . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 65 Intellectual Property and Copyright Statements . . . . . . . 11 67 1. Introduction 69 1.1 Notational Conventions 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 The definition of live property is provided in [RFC2518]. The 76 definition of protected and computed properties is provided in 77 [RFC3253], Section 1.4. 79 1.2 Requirement for quotas 81 WebDAV servers based on [RFC2518] have been implemented and deployed 82 with quota restrictions on collections and users, so it makes sense 83 to standardize this functionality to improve user experience and 84 client interoperability. 86 The reasons why WebDAV servers frequently have quotas enforced are 87 the same reasons why any storage system comes with quotas. 89 o Sometimes the storage service charges according to quota 91 o Sometimes the storage service is provided free, but the storage 92 service provider has limited storage space (e.g. university- 93 provided student accounts) 95 o Even in cases where the storage can be upgraded, the storage 96 managers may choose to limit quota in order to encourage users to 97 limit the files they store on the system and to clean up obsolete 98 files. (e.g. IT departments within corporations) 100 In order to work best with repositories that support quotas, client 101 software should be able to determine and display the DAV:quota- 102 available-bytes (defined below) on collections. Further, client 103 software should have some way of fairly reliably determining how much 104 storage space is already counted towards that quota. 106 Support for the properties defined in this document enhances the 107 client experience, because the client has a chance of managing its 108 files to avoid running out of allocated storage space. Clients may 109 not be able to calculate the value as accurately on their own, 110 depending on how total space used is calculated by the server. 112 2. Solution Overview 114 The approach to meeting the requirements and scenarios outlined above 115 is to define two live properties. This specification can be met on a 116 server by implementing both DAV:quota-available-bytes and DAV:quota- 117 used-bytes on collections only. 119 A PROPFIND request SHOULD NOT return any of the 120 properties defined by this document. However, these property names 121 MUST be returned in a request for a resource that 122 supports the properties, except in the case of infinite limits which 123 are explained below. 125 The DAV:quota-available-bytes and DAV:quota-used-bytes definitions 126 below borrow heavily from the quota definitions in the NFS [RFC3530] 127 specification. 129 3. DAV:quota-available-bytes 131 Name: quota-available-bytes 133 Namespace: DAV: 135 Purpose: Indicates the maximum amount of additional storage available 136 to be allocated to a resource. 138 DTD: 140 The DAV:quota-available-bytes property value is the value in octets 141 representing the amount of additional disk space beyond the current 142 allocation that can be allocated to this resource before further 143 allocations will be refused. It is understood that this space may be 144 consumed by allocations to other resources. 146 Support for this property is REQUIRED on collections, and OPTIONAL on 147 other resources. A server SHOULD implement this property for each 148 resource that has the DAV:quota-used-bytes property. 150 Clients SHOULD expect that as the DAV:quota-available-bytes on a 151 resource approaches 0, further allocations to that resource may be 152 refused. A value of 0 indicates that users will probably not be able 153 to perform operations that write additional information (e.g. a PUT 154 inside a collection), but may be able to replace through overwrite an 155 existing resource of equal size. 157 Note that there may be a number of distinct but overlapping limits, 158 which may even include physical media limits. When reporting DAV: 159 quota-available-bytes, the server is at liberty to choose any of 160 those limits but SHOULD do so in a repeatable way. The rule may be 161 configured per repository, or may be "choose the smallest number". 163 If a resource has no quota enforced or unlimited storage ("infinite 164 limits"), the server MAY choose not to return this property (404 Not 165 Found response in Multi-Status), although this specification 166 RECOMMENDS that servers return some appropriate value (e.g. the 167 amount of free disc space). A client cannot entirely assume that 168 there is no quota enforced on a resource that does not have this 169 property, but might as well act as if there is no quota. 171 The value of this property is protected (see section 1.4.2 of 172 [RFC3253] for the definition of protected properties). A 403 173 Forbidden response is RECOMMENDED for attempts to write a protected 174 property, and the server SHOULD include an XML error body as defined 175 by DeltaV [RFC3253] with the 176 precondition tag. 178 4. DAV:quota-used-bytes 180 Name: quota-used-bytes 182 Namespace: DAV: 184 Purpose: Contains the amount of storage counted against the quota on 185 a resource. 187 DTD: 189 The DAV:quota-used-bytes value is the value in octets representing 190 the amount of space used by this resource and possibly a number of 191 other similar resources, where the set of "similar" meets at least 192 the criterion that allocating space to any resource in the set will 193 count against the DAV:quota-available-bytes. It MUST include the 194 total count including usage derived from sub-resources if 195 appropriate. It SHOULD include metadata storage size if metadata 196 storage is counted against the DAV:quota-available-bytes. 198 Note that there may be a number of distinct but overlapping sets of 199 resources for which a DAV:quota-used-bytes is maintained (e.g. "all 200 files with a given owner", "all files with a given group owner", 201 etc.). The server is at liberty to choose any of those sets but 202 SHOULD do so in a repeatable way. The rule may be configured per 203 repository. 205 Support for this property is REQUIRED on collections, and OPTIONAL on 206 other resources. A server SHOULD implement this property for each 207 resource that has the DAV:quota-available-bytes property. 209 This value of this property is computed (see Section 1.4.3 of 210 [RFC3253] for the definition of computed property). A 403 Forbidden 211 response is RECOMMENDED for attempts to write a protected property, 212 and the server SHOULD include an XML error body as defined by DeltaV 213 [RFC3253] with the 214 precondition tag. 216 5. Example PROPFIND request and response 218 Request: 220 PROPFIND /~milele/public/ HTTP/1.1 221 Depth: 0 222 Host: www.example.com 223 Content-Type: text/xml 224 Content-Length: xxx 226 227 228 229 230 231 232 234 Response: 236 HTTP/1.1 207 Multi-Status 237 Date: Tue, 16 Oct 2001 22:13:39 GMT 238 Content-Length: xxx 239 Content-Type: text/xml; charset=UTF-8 241 242 243 244 http://www.example.com/~milele/public/ 245 246 247 596650 248 403350 249 250 HTTP/1.1 200 OK 251 252 253 255 6. Error reporting 257 WebDAV [RFC2518] defines the status code 507 (Insufficient Storage). 258 This status code SHOULD be used when a client request (e.g. a PUT, 259 PROPFIND, MKCOL, MOVE or COPY) fails because it would exceed their 260 quota or physical storage limits. In order to differentiate the 261 response from other storage problems, the server SHOULD include an 262 XML error body as defined by DeltaV [RFC3253] with the appropriate 263 precondition tag. 265 Preconditions: 267 (DAV:quota-not-exceeded): the allocated quota MUST NOT be exceeded by 268 the request. 270 (DAV:sufficient-disk-space): there is sufficient physical space to 271 execute the request. 273 Example error response: 275 HTTP/1.1 507 Insufficient Storage 276 Content-Length: xxx 277 Content-Type: text/xml 279 280 281 282 284 Implementation note: some client may be be able to take advantage of 285 the different precondition codes when mapping to operating system 286 status codes, such as E_NOSPC and E_DQUOT in NFS (see [RFC3530], 287 Section 12). 289 7. Notes 291 Server implementations store and account for their data in many 292 different ways. Some of the challenges: 294 o Some server implementations find it prohibitive to count storage 295 used for metadata, others may choose to do so for better 296 accounting. 298 o Older versions of resources may be stored as well. 300 o Variants of one resource may exist with different content lengths. 302 o Content may be dynamically generated. 304 o Resource bodies can be compressed. 306 o Some resources may be stored for "free", not counting against 307 quota. 309 Since server storage accounting can vary so much, clients should 310 expect the following: 312 o The size of a file on the client's file system, or in a PUT 313 message, may not correspond to the amount of storage required by 314 the server to store the resource. Thus, the client cannot predict 315 with 100% accuracy whether a given file will be allowed given the 316 storage quota. 318 o Deleting or overwriting a resource may not free up the same amount 319 of storage as indicated by the DAV:getcontentlength property 320 defined in [RFC2518] for the resource. If deleting a resource 321 does not free up any space, the file may have been moved to a 322 "trash" folder or "recycle bin", or retained as in versioning 323 systems ([RFC3253]). 325 o Since there are many factors that affect the storage used by a set 326 of resources, including automatic compression, the size of 327 associated metadata, and server-inserted content (such as that 328 created by PHP code) in the on-the-wire representation of 329 resources, clients are advised to not depend on the value of DAV: 330 quota-used-bytes being the sum of the DAV:getcontentlength 331 properties for resources contained by a collection. 333 o Additionally, because there may be a number of distinct but 334 overlapping sets of resources for which a DAV:quota-used-bytes is 335 maintained (Section 4), there may be no correlation between the 336 size of the resources in a collection and DAV:quota-used-bytes. 337 For example a server that implements user-based quotas, DAV:quota- 338 used-bytes usually will be the same for a collection and it's 339 members. 341 o On some systems where quota is counted by collection and not by 342 user, a quota on a sub-collection may be larger than the quota on 343 the parent collection that contains it. For example, the quota on 344 /~milele/ may be 100 MB, but the quota on /~milele/public/ may be 345 unlimited. This allows the space used by /~milele/public/ to be 346 as large as the quota on /~milele/ allows (depending on the other 347 contents of /~milele/) even if the quota on /~milele/ is changed. 348 Thus, even when the quota on a parent collection is changed, it is 349 not necessarily required to change the quota on every child or 350 descendant collection. 352 8. Security Considerations 354 A hacker may prefer to store files in collections with a large quota. 355 This isn't strictly a security concern because it doesn't make it any 356 easier to store files. On the other hand, the DAV:quota-used-bytes 357 property may make it easier to detect tampering or misuse. 359 9. Internationalization Considerations 361 Quota is counted in Arabic numerals expressed in strings. There are 362 no internationalization considerations. 364 10. IANA Considerations 366 There are no IANA considerations. 368 11. Acknowledgements 370 Stefan Eissing, Geoff Clemm, Jim Luther, Julian Reschke, Jim 371 Whitehead, among others, have provided valuable comments on this 372 document. 374 12. References 376 12.1 Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 382 Jensen, "HTTP Extensions for Distributed Authoring -- 383 WebDAV", RFC 2518, February 1999. 385 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 386 Whitehead, "Versioning Extensions to WebDAV (Web 387 Distributed Authoring and Versioning)", RFC 3253, 388 March 2002. 390 12.2 Informative References 392 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 393 Beame, C., Eisler, M., and D. Noveck, "Network File System 394 (NFS) version 4 Protocol", RFC 3530, April 2003. 396 Authors' Addresses 398 Brian Korver 399 Network Resonance, Inc. 400 2483 E. Bayshore Road 401 Suite 212 402 Palo Alto, CA 94303 403 US 405 Phone: +1 415 812-7705 406 Email: briank@networkresonance.com 408 Lisa Dusseault 409 Open Source Applications Foundation 410 543 Howard Street 411 5th Floor 412 San Francisco, CA 94105 413 US 415 Phone: +1 415 946-3040 416 Email: lisa@osafoundation.org 418 Intellectual Property Statement 420 The IETF takes no position regarding the validity or scope of any 421 Intellectual Property Rights or other rights that might be claimed to 422 pertain to the implementation or use of the technology described in 423 this document or the extent to which any license under such rights 424 might or might not be available; nor does it represent that it has 425 made any independent effort to identify any such rights. Information 426 on the procedures with respect to rights in RFC documents can be 427 found in BCP 78 and BCP 79. 429 Copies of IPR disclosures made to the IETF Secretariat and any 430 assurances of licenses to be made available, or the result of an 431 attempt made to obtain a general license or permission for the use of 432 such proprietary rights by implementers or users of this 433 specification can be obtained from the IETF on-line IPR repository at 434 http://www.ietf.org/ipr. 436 The IETF invites any interested party to bring to its attention any 437 copyrights, patents or patent applications, or other proprietary 438 rights that may cover technology that may be required to implement 439 this standard. Please address the information to the IETF at 440 ietf-ipr@ietf.org. 442 Disclaimer of Validity 444 This document and the information contained herein are provided on an 445 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 446 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 447 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 448 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 449 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 450 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 452 Copyright Statement 454 Copyright (C) The Internet Society (2005). This document is subject 455 to the rights, licenses and restrictions contained in BCP 78, and 456 except as set forth therein, the authors retain all their rights. 458 Acknowledgment 460 Funding for the RFC Editor function is currently provided by the 461 Internet Society.