draft-ietf-webdav-quota-03.txt   draft-ietf-webdav-quota-04.txt 
WWW Distributed Authoring and B. Korver WWW Distributed Authoring and B. Korver
Versioning (webdav) Xythos Versioning (webdav) Xythos
Internet-Draft L. Dusseault Internet-Draft L. Dusseault
Expires: January 5, 2005 OSAF Expires: April 22, 2005 OSAF
July 7, 2004 October 22, 2004
Quota and Size Properties for DAV Collections Quota and Size Properties for DAV Collections
draft-ietf-webdav-quota-03 draft-ietf-webdav-quota-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
WebDAV servers are frequently deployed with quota (size) limitations. WebDAV servers are frequently deployed with quota (size) limitations.
This Internet-Draft discusses the properties and minor behaviors This Internet-Draft discusses the properties and minor behaviors
needed for clients to interoperate with quota implementations on needed for clients to interoperate with quota implementations on
WebDAV repositories. WebDAV repositories.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3
1.2 Requirement for quotas . . . . . . . . . . . . . . . . . . 3 1.2 Requirement for quotas . . . . . . . . . . . . . . . . . . 3
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. DAV:quota-available-bytes . . . . . . . . . . . . . . . . . . 4 3. DAV:quota-available-bytes . . . . . . . . . . . . . . . . . . 4
4. DAV:quota-used-bytes . . . . . . . . . . . . . . . . . . . . . 5 4. DAV:quota-used-bytes . . . . . . . . . . . . . . . . . . . . . 5
5. DAV:quota-assigned-bytes . . . . . . . . . . . . . . . . . . . 6 5. Example PROPFIND request and response . . . . . . . . . . . . 5
5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Error reporting . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Example PROPFIND request and response . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Error reporting . . . . . . . . . . . . . . . . . . . . . . . 8 9. Internationalization Considerations . . . . . . . . . . . . . 8
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Internationalization Considerations . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 12.2 Informative References . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
13.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 10
13.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
1. Introduction 1. Introduction
1.1 Notational Conventions 1.1 Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2 Requirement for quotas 1.2 Requirement for quotas
skipping to change at page 4, line 7 skipping to change at page 4, line 7
any resource. any resource.
2. Solution Overview 2. Solution Overview
The approach to meeting the requirements and scenarios outlined above The approach to meeting the requirements and scenarios outlined above
is to define three live properties. This specification can be met on is to define three live properties. This specification can be met on
a server by implementing both quota-available and quota-used on a server by implementing both quota-available and quota-used on
collections only. Implementing both quota-available and quota- used collections only. Implementing both quota-available and quota- used
on all resources is RECOMMENDED. on all resources is RECOMMENDED.
None of these properties need be returned in a <DAV:allprop> request A <DAV:allprop> PROPFIND request SHOULD NOT return any of the
though the server may include them. However, these property names properties defined by this document. However, these property names
MUST be returned in a <DAV:propname> request for a resource that MUST be returned in a <DAV:propname> request for a resource that
supports the properties, except in the case of infinite limits which supports the properties, except in the case of infinite limits which
are explained below. are explained below.
The quota-available and quota-used definitions below borrow heavily The quota-available and quota-used definitions below borrow heavily
from the quota definitions in the NFS [RFC3010] specification. from the quota definitions in the NFS [RFC3010] specification.
3. DAV:quota-available-bytes 3. DAV:quota-available-bytes
Name: quota-available-bytes Name: quota-available-bytes
skipping to change at page 6, line 5 skipping to change at page 5, line 50
Support for this property is REQUIRED on collections, and OPTIONAL on Support for this property is REQUIRED on collections, and OPTIONAL on
other resources. A server SHOULD implement this property for each other resources. A server SHOULD implement this property for each
resource that has the DAV:quota-available-bytes property. resource that has the DAV:quota-available-bytes property.
Support for this property enhances the client experience, because Support for this property enhances the client experience, because
together with DAV:quota-available-bytes, the client has a chance of together with DAV:quota-available-bytes, the client has a chance of
managing its files to avoid running out of allocated storage space. managing its files to avoid running out of allocated storage space.
Clients may not be able to calculate the value as accurately on their 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. own, depending on how total space used is calculated by the server.
5. DAV:quota-assigned-bytes 5. Example PROPFIND request and response
Name: quota-assigned-bytes
Namespace: DAV:
Purpose: Indicates the amount of storage assigned.
DTD: <!ELEMENT quota-bytes (#PCDATA) >
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
Request: Request:
PROPFIND /~milele/public/ HTTP/1.1 PROPFIND /~milele/public/ HTTP/1.1
Depth: 0 Depth: 0
Host: www.example.com Host: www.example.com
Content-Type: text/xml Content-Type: text/xml
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:"> <D:propfind xmlns:D="DAV:">
skipping to change at page 8, line 38 skipping to change at page 6, line 38
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:quota-available-bytes>596650</D:quota-available-bytes> <D:quota-available-bytes>596650</D:quota-available-bytes>
<D:quota-used-bytes>403350</quota-used-bytes> <D:quota-used-bytes>403350</quota-used-bytes>
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
7. Error reporting 6. Error reporting
WebDAV [RFC2518] defines the status code 507 (Insufficient Storage). WebDAV [RFC2518] defines the status code 507 (Insufficient Storage).
This status code SHOULD be used when a client request (e.g. a PUT, 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 PROPFIND, MKCOL, MOVE or COPY) is forbidden because it would exceed
their allotted quota. In order to differentiate the response from their allotted quota. In order to differentiate the response from
other storage problems, the server SHOULD include an XML error body other storage problems, the server SHOULD include an XML error body
as defined by DeltaV [RFC3253] with the <DAV:storage-quota-reached/> as defined by DeltaV [RFC3253] with the <DAV:storage-quota-reached/>
precondition tag. precondition tag.
Example error response: Example error response:
HTTP/1.1 507 Insufficient Storage HTTP/1.1 507 Insufficient Storage
Content-Length: 100 Content-Length: 100
Content-Type: text/xml Content-Type: text/xml
<?xml version="1.0"> <?xml version="1.0">
<error xmlns="DAV:"> <error xmlns="DAV:">
<storage-quota-reached/> <storage-quota-reached/>
</error> </error>
8. Notes 7. Notes
Server implementations store and account for their data in many Server implementations store and account for their data in many
different ways. Some of the challenges: different ways. Some of the challenges:
o Some server implementations find it prohibitive to count storage o Some server implementations find it prohibitive to count storage
used for metadata, others may choose to do so for better used for metadata, others may choose to do so for better
accounting. accounting.
o Older versions of resources may be stored as well. o Older versions of resources may be stored as well.
skipping to change at page 10, line 21 skipping to change at page 8, line 20
user, a quota on a sub-collection may be larger than the quota on 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 its parent collection that contains it. For example, the quota on
/~milele/ may be 100 MB, but the quota on /~milele/public/ may be /~milele/ may be 100 MB, but the quota on /~milele/public/ may be
unlimited. This allows the space used by /~milele/public/ to be unlimited. This allows the space used by /~milele/public/ to be
as large as the quota on /~milele/ allows (depending on the other as large as the quota on /~milele/ allows (depending on the other
contents of /~milele/) even if the quota on /~milele/ is changed. contents of /~milele/) even if the quota on /~milele/ is changed.
Thus, even when the quota on a parent collection is changed, it is Thus, even when the quota on a parent collection is changed, it is
not necessarily required to change the quota on every child or not necessarily required to change the quota on every child or
descendant collection. descendant collection.
9. Security Considerations 8. Security Considerations
A hacker may prefer to store files in collections with a large quota. 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 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 easier to store files. On the other hand, the DAV:quota-used-bytes
property may make it easier to detect tampering or misuse. property may make it easier to detect tampering or misuse.
If a server chooses to make the DAV:quota-assigned-bytes writable by If a server chooses to make the DAV:quota-assigned-bytes writable by
clients with sufficient authorization, then it is opening up a clients with sufficient authorization, then it is opening up a
certain amount of near-administration functionality to clients. certain amount of near-administration functionality to clients.
However, it is not required for the DAV:quota-assigned-bytes property 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 to be writeable by any clients, so a server can easily avoid this
consideration. consideration.
10. Internationalization Considerations 9. Internationalization Considerations
Quota is counted in Arabic numerals expressed in strings. There are Quota is counted in Arabic numerals expressed in strings. There are
no internationalization considerations. no internationalization considerations.
11. IANA Considerations 10. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
12. Acknowledgements 11. Acknowledgements
Stefan Eissing, Jim Luther, Julian Reschke, and Jim Whitehead and Stefan Eissing, Jim Luther, Julian Reschke, and Jim Whitehead and
provided valuable comments on this document. 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 [RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", RFC 2026, October 1996. 3", RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
Jensen, "HTTP Extensions for Distributed Authoring -- Jensen, "HTTP Extensions for Distributed Authoring --
WebDAV", RFC 2518, February 1999. WebDAV", RFC 2518, February 1999.
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J.
Whitehead, "Versioning Extensions to WebDAV (Web Whitehead, "Versioning Extensions to WebDAV (Web
Distributed Authoring and Versioning)", RFC 3253, March Distributed Authoring and Versioning)", RFC 3253, March
2002. 2002.
13.2 Informative References 12.2 Informative References
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M. and D. Noveck, "NFS version 4 Beame, C., Eisler, M. and D. Noveck, "NFS version 4
Protocol", RFC 3010, December 2000. Protocol", RFC 3530, December 2000.
Authors' Addresses Authors' Addresses
Brian Korver Brian Korver
Xythos Software Xythos Software
One Bush Street One Bush Street
Suite 600 Suite 600
San Francisco, CA 94104 San Francisco, CA 94104
US US
skipping to change at page 12, line 8 skipping to change at page 10, line 8
5th Floor 5th Floor
San Francisco, CA 94105 San Francisco, CA 94105
US US
Phone: +1 415 946-3040 Phone: +1 415 946-3040
EMail: lisa@osafoundation.org EMail: lisa@osafoundation.org
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any 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 pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
<x-flowed>
</x-flowed>
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/