--- 1/draft-ietf-webdav-quota-05.txt 2006-02-05 02:11:26.000000000 +0100 +++ 2/draft-ietf-webdav-quota-06.txt 2006-02-05 02:11:26.000000000 +0100 @@ -1,19 +1,19 @@ WWW Distributed Authoring and B. Korver Versioning (webdav) Xythos Internet-Draft L. Dusseault -Expires: July 23, 2005 OSAF - January 19, 2005 +Expires: August 11, 2005 OSAF + February 7, 2005 Quota and Size Properties for DAV Collections - draft-ietf-webdav-quota-05 + draft-ietf-webdav-quota-06 Status of this Memo 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. @@ -26,42 +26,42 @@ 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. + This Internet-Draft will expire on August 11, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.2 Requirement for quotas . . . . . . . . . . . . . . . . . . 3 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . 3 3. DAV:quota-available-bytes . . . . . . . . . . . . . . . . . 4 4. DAV:quota-used-bytes . . . . . . . . . . . . . . . . . . . . 5 - 5. Example PROPFIND request and response . . . . . . . . . . . 6 + 5. Example PROPFIND request and response . . . . . . . . . . . 5 6. Error reporting . . . . . . . . . . . . . . . . . . . . . . 6 7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . 8 9. Internationalization Considerations . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1 Normative References . . . . . . . . . . . . . . . . . . 8 12.2 Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 @@ -95,32 +95,36 @@ service provider has limited storage space (e.g. university-provided student accounts) o Even in cases where the storage can be upgraded, the storage managers may choose to limit quota in order to encourage users to limit the files they store on the system and to clean up obsolete files. (e.g. IT departments within corporations) 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. + DAV:quota-available-bytes (defined below) on collections. Further, + client software should have some way of fairly reliably determining + how much storage space is already counted towards that quota. + + Support for the properties defined in this document enhances the + client experience, because 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. 2. Solution Overview 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. + DAV:quota-used-bytes on collections only. A PROPFIND request SHOULD NOT return any of the properties defined by this document. However, these property names MUST be returned in a request for a resource that supports the properties, except in the case of infinite limits which are explained below. The DAV:quota-available-bytes and DAV:quota-used-bytes definitions below borrow heavily from the quota definitions in the NFS [RFC3530] specification. @@ -180,46 +184,39 @@ Namespace: DAV: Purpose: Contains the amount of storage counted against the quota on a resource. DTD: 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 + other similar resources, 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 + resources 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. - 5. Example PROPFIND request and response - Request: PROPFIND /~milele/public/ HTTP/1.1 Depth: 0 Host: www.example.com Content-Type: text/xml Content-Length: xxx @@ -216,21 +213,24 @@ Request: PROPFIND /~milele/public/ HTTP/1.1 Depth: 0 Host: www.example.com Content-Type: text/xml Content-Length: xxx - + + + + 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 @@ -272,25 +272,25 @@ Server implementations store and account for their data in many different ways. Some of the challenges: o Some server implementations find it prohibitive to count storage used for metadata, others may choose to do so for better accounting. o Older versions of resources may be stored as well. - o Variants of one resource may exist with different content lengths + o Variants of one resource may exist with different content lengths. o Content may be dynamically generated. - o Resource bodies can be compressed + o Resource bodies can be compressed. o Some resources may be stored for "free", not counting against quota. Since server storage accounting can vary so much, clients should expect the following: o The size of a file on the client's file system, or in a PUT message, may not correspond to the amount of storage required by the server to store the resource. Thus, the client cannot predict