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 become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 23, 2005.
Copyright © The Internet Society (2005). All Rights Reserved.
WebDAV servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories.
WebDAV servers based on [RFC2518] have been implemented and deployed with quota restrictions on collections and users, so it makes sense to standardize this functionality to improve user experience and client interoperability. This specification requires WebDAV because it requires PROPFIND support and relies on the WebDAV definition of collections and properties, including the definitions for live and protected properties (see section 1.4.2 of [RFC3253] for the definition of protected properties).¶
The reasons why WebDAV servers frequently have quotas enforced are the same reasons why any storage system comes with quotas.
In order to work best with repositories that support quotas, client software should be able to determine and display the DAV:quota-available-bytes on collections. Further, client software should have some way of fairly reliably determining how much storage space is already counted towards that quota.¶
The approach to meeting the requirements and scenarios outlined above is to define two live properties. This specification can be met on a server by implementing both DAV:quota-available-bytes and DAV:quota-used-bytes on collections only. Implementing both DAV:quota-available-bytes and DAV:quota-used-bytes on all resources is RECOMMENDED.¶
A <DAV:allprop> PROPFIND request SHOULD NOT return any of the properties defined by this document. However, these property names MUST be returned in a <DAV:propname> request for a resource that supports the properties, except in the case of infinite limits which are explained below.¶
The DAV:quota-available-bytes property value is the value in octets representing the amount of additional disk space beyond the current allocation that can be allocated to this resource before further allocations will be refused. It is understood that this space may be consumed by allocations to other resources.¶
Support for this property is REQUIRED on collections, and OPTIONAL on other resources. A server SHOULD implement this property for each resource that has the DAV:quota-used-bytes property.¶
Clients SHOULD expect that as the DAV:quota-available-bytes on a resource approaches 0, further allocations to that resource may be refused. A value of 0 indicates that users will probably not be able to perform operations that write additional information (e.g. a PUT inside a collection), but may be able to replace through overwrite an existing resource of equal size.¶
Note that there may be a number of distinct but overlapping limits, which may even include physical media limits. When reporting DAV:quota-available-bytes, the server is at liberty to choose any of those limits but SHOULD do so in a repeatable way. The rule may be configured per repository, or may be "choose the smallest number".¶
If a resource has no quota enforced or unlimited storage ("infinite limits"), the server MAY choose not to return this property (404 Not Found response in Multi-Status), although this specification RECOMMENDS that servers return some appropriate value (e.g. the amount of free disc space). A client cannot entirely assume that there is no quota enforced on a resource that does not have this property, but might as well act as if there is no quota.¶
The value of this property is protected (see section 1.4.2 of [RFC3253] for the definition of protected properties). A 403 Forbidden response is RECOMMENDED for attempts to write a protected property, and the server SHOULD include an XML error body as defined by DeltaV [RFC3253] with the <DAV:cannot-modify-protected-property/> precondition tag.¶
The DAV:quota-used-bytes value is the value in octets representing the amount of space used by this resource and possibly a number of other similar files or directories, where the set of "similar" meets at least the criterion that allocating space to any resource in the set will count against the DAV:quota-available-bytes. It MUST include the total count including usage derived from sub-resources if appropriate. It SHOULD include metadata storage size if metadata storage is counted against the DAV:quota-available-bytes.¶
Note that there may be a number of distinct but overlapping sets of files or directories for which a DAV:quota-used-bytes is maintained (e.g. "all files with a given owner", "all files with a given group owner", etc.). The server is at liberty to choose any of those sets but SHOULD do so in a repeatable way. The rule may be configured per repository.¶
Support for this property is REQUIRED on collections, and OPTIONAL on other resources. A server SHOULD implement this property for each resource that has the DAV:quota-available-bytes property.¶
Support for this property enhances the client experience, because together with DAV:quota-available-bytes, the client has a chance of managing its files to avoid running out of allocated storage space. Clients may not be able to calculate the value as accurately on their own, depending on how total space used is calculated by the server.¶
Request: PROPFIND /~milele/public/ HTTP/1.1 Depth: 0 Host: www.example.com Content-Type: text/xml Content-Length: xxx <?xml version="1.0" ?> <D:propfind xmlns:D="DAV:"> <D:prop><D:quota-available-bytes/><D:quota-used-bytes/></D:prop> </D:propfind> Response: HTTP/1.1 207 Multi-Status Date: Tue, 16 Oct 2001 22:13:39 GMT Content-Length: xxx Content-Type: text/xml; charset=UTF-8 <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.example.com/~milele/public/</D:href> <D:propstat> <D:prop> <D:quota-available-bytes>596650</D:quota-available-bytes> <D:quota-used-bytes>403350</D:quota-used-bytes> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
WebDAV [RFC2518] defines the status code 507 (Insufficient Storage). This status code SHOULD be used when a client request (e.g. a PUT, PROPFIND, MKCOL, MOVE or COPY) fails because it would exceed their allotted quota. In order to differentiate the response from other storage problems, the server SHOULD include an XML error body as defined by DeltaV [RFC3253] with the <DAV:quota-not-exceeded/> precondition tag.¶
Example error response:
HTTP/1.1 507 Insufficient Storage Content-Length: xxx Content-Type: text/xml <?xml version="1.0"> <error xmlns="DAV:"> <quota-not-exceeded/> </error>
Server implementations store and account for their data in many different ways. Some of the challenges:
Since server storage accounting can vary so much, clients should expect the following:
A hacker may prefer to store files in collections with a large quota. This isn't strictly a security concern because it doesn't make it any easier to store files. On the other hand, the DAV:quota-used-bytes property may make it easier to detect tampering or misuse.¶
Quota is counted in Arabic numerals expressed in strings. There are no internationalization considerations.¶
There are no IANA considerations.¶
Stefan Eissing, Geoff Clemm, Jim Luther, Julian Reschke, Jim Whitehead, among others, have provided valuable comments on this document.¶
Copyright © The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.