--- 1/draft-ietf-webdav-quota-03.txt 2006-02-05 02:11:24.000000000 +0100 +++ 2/draft-ietf-webdav-quota-04.txt 2006-02-05 02:11:24.000000000 +0100 @@ -1,76 +1,78 @@ + WWW Distributed Authoring and B. Korver Versioning (webdav) Xythos Internet-Draft L. Dusseault -Expires: January 5, 2005 OSAF - July 7, 2004 +Expires: April 22, 2005 OSAF + October 22, 2004 Quota and Size Properties for DAV Collections - draft-ietf-webdav-quota-03 + draft-ietf-webdav-quota-04 Status of this Memo - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + 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 January 5, 2005. + This Internet-Draft will expire on April 22, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2004). Abstract WebDAV servers are frequently deployed with quota (size) limitations. This Internet-Draft discusses the properties and minor behaviors needed for clients to interoperate with quota 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. DAV:quota-assigned-bytes . . . . . . . . . . . . . . . . . . . 6 - 5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 - 6. Example PROPFIND request and response . . . . . . . . . . . . 7 - 7. Error reporting . . . . . . . . . . . . . . . . . . . . . . . 8 - 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 10. Internationalization Considerations . . . . . . . . . . . . 10 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 - 13.2 Informative References . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 - Intellectual Property and Copyright Statements . . . . . . . . 12 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 + 12.2 Informative References . . . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . 10 1. Introduction 1.1 Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Requirement for quotas @@ -108,22 +110,22 @@ any resource. 2. Solution Overview The approach to meeting the requirements and scenarios outlined above is to define three live properties. This specification can be met on a server by implementing both quota-available and quota-used on collections only. Implementing both quota-available and quota- used on all resources is RECOMMENDED. - None of these properties need be returned in a request - though the server may include them. However, these property names + 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 quota-available and quota-used definitions below borrow heavily from the quota definitions in the NFS [RFC3010] specification. 3. DAV:quota-available-bytes Name: quota-available-bytes @@ -199,84 +201,21 @@ 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. DAV:quota-assigned-bytes - - Name: quota-assigned-bytes - - Namespace: DAV: - - Purpose: Indicates the amount of storage assigned. - - DTD: - - The DAV:quota-assigned-bytes property value is the amount of storage - space potentially either assigned to or requested for this file or - directory, measured in octets. DAV:quota-assigned-bytes is primarily - intended to support implementations that allow quota to be - PROPPATCHed or configured by some other means. - - The value of this property will usually be protected, although a user - with sufficient privileges may be permitted to change the value. The - property is useful even if it is protected. A 403 Forbidden response - is RECOMMENDED for attempts to write a protected property. This - property will usually be read-only for instance because a user's - quota should generally not configurable by other users. - - Support for this property is OPTIONAL. - - Note that a resource may show more quota-used than its quota- - assigned appears to allow, and that quota-available MUST never be - greater than the value of quota-assigned. - -5.1 Example 1 - - As an example of quota-assigned, imagine a quota system where each - collection may have a quota assigned and where a resource contained - in a collection is subject to only the quota constraints of the - nearest collection which has a quota assigned. Assume the - administrator creates a collection A and gives it a quota-assigned of - 300KB and then creates a subcollection B which is given - quota-assigned of 8000KB. In this case, the initial quota-available - for B is 8000KB, not 3000KB, since the constraint on A is ignored in - favor of the constraint on B. - - DAV:quota-assigned-bytes DAV:quota-available-bytes - /A 300KB 300KB - /A/B 8000KB 8000KB - - Note that this is only one example quota system, and that other quota - systems are possible, such as one described in the example below. - -5.2 Example 2 - - As another example of quota-assigned, imagine a quota system where - each collection may have a quota assigned and where a resource - contained in a collection is subject to the quota constraints of all - parent collections. Assume the administrator creates a collection A - and gives it a quota-assigned of 500KB and then creates a - subcollection B which is given quota-assigned of 1000KB. In this - case, the initial quota-available for B is 500KB, not 1000KB, since - the constraint on A applies to B as well. - - DAV:quota-assigned-bytes DAV:quota-available-bytes - /A 500KB 500KB - /A/B 1000KB 500KB - -6. Example PROPFIND request and response +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 @@ -297,42 +236,42 @@ 596650 403350 HTTP/1.1 200 OK -7. Error reporting +6. Error reporting 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) is forbidden 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 precondition tag. Example error response: HTTP/1.1 507 Insufficient Storage Content-Length: 100 Content-Type: text/xml -8. Notes +7. Notes 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. @@ -369,72 +308,72 @@ user, a quota on a sub-collection may be larger than the quota on its parent collection that contains it. For example, the quota on /~milele/ may be 100 MB, but the quota on /~milele/public/ may be unlimited. This allows the space used by /~milele/public/ to be as large as the quota on /~milele/ allows (depending on the other contents of /~milele/) even if the quota on /~milele/ is changed. Thus, even when the quota on a parent collection is changed, it is not necessarily required to change the quota on every child or descendant collection. -9. Security Considerations +8. Security Considerations 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. If a server chooses to make the DAV:quota-assigned-bytes writable by clients with sufficient authorization, then it is opening up a certain amount of near-administration functionality to clients. However, it is not required for the DAV:quota-assigned-bytes property to be writeable by any clients, so a server can easily avoid this consideration. -10. Internationalization Considerations +9. Internationalization Considerations Quota is counted in Arabic numerals expressed in strings. There are no internationalization considerations. -11. IANA Considerations +10. IANA Considerations There are no IANA considerations. -12. Acknowledgements +11. Acknowledgements Stefan Eissing, Jim Luther, Julian Reschke, and Jim Whitehead and provided valuable comments on this document. -13. References +12. References -13.1 Normative References +12.1 Normative References [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WebDAV", RFC 2518, February 1999. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead, "Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)", RFC 3253, March 2002. -13.2 Informative References +12.2 Informative References [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "NFS version 4 - Protocol", RFC 3010, December 2000. + Protocol", RFC 3530, December 2000. Authors' Addresses Brian Korver Xythos Software One Bush Street Suite 600 San Francisco, CA 94104 US @@ -447,61 +386,55 @@ 5th Floor San Francisco, CA 94105 US Phone: +1 415 946-3040 EMail: lisa@osafoundation.org Intellectual Property Statement The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to + 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. + 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 which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - -Full Copyright Statement + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. - Copyright (C) The Internet Society (2004). All Rights Reserved. +Disclaimer of Validity - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. + 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 limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. +Copyright Statement - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. + Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. + + + +