draft-ietf-webdav-quota-06.txt   draft-ietf-webdav-quota-07.txt 
WWW Distributed Authoring and B. Korver WWW Distributed Authoring and B. Korver
Versioning (webdav) Xythos Versioning (webdav) Network Resonance
Internet-Draft L. Dusseault Internet-Draft L. Dusseault
Expires: August 11, 2005 OSAF Expires: October 29, 2005 OSAF
February 7, 2005 April 27, 2005
Quota and Size Properties for DAV Collections Quota and Size Properties for DAV Collections
draft-ietf-webdav-quota-06 draft-ietf-webdav-quota-07
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
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-
Internet-Drafts. 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 August 11, 2005. This Internet-Draft will expire on October 29, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
WebDAV servers are frequently deployed with quota (size) limitations. WebDAV servers are frequently deployed with quota (size) limitations.
This document discusses the properties and minor behaviors needed for This document discusses the properties and minor behaviors needed for
clients to interoperate with quota (size) implementations on WebDAV clients to interoperate with quota (size) implementations on WebDAV
repositories. 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. Example PROPFIND request and response . . . . . . . . . . . 5 5. Example PROPFIND request and response . . . . . . . . . . . 6
6. Error reporting . . . . . . . . . . . . . . . . . . . . . . 6 6. Error reporting . . . . . . . . . . . . . . . . . . . . . . 7
7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . 9
9. Internationalization Considerations . . . . . . . . . . . . 8 9. Internationalization Considerations . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1 Normative References . . . . . . . . . . . . . . . . . . 8 12.1 Normative References . . . . . . . . . . . . . . . . . . 9
12.2 Informative References . . . . . . . . . . . . . . . . . 9 12.2 Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11
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].
The definition of live property is provided in [RFC2518]. The
definition of protected and computed properties is provided in
[RFC3253], Section 1.4.
1.2 Requirement for quotas 1.2 Requirement for quotas
WebDAV servers based on [RFC2518] have been implemented and deployed WebDAV servers based on [RFC2518] have been implemented and deployed
with quota restrictions on collections and users, so it makes sense with quota restrictions on collections and users, so it makes sense
to standardize this functionality to improve user experience and to standardize this functionality to improve user experience and
client interoperability. This specification requires WebDAV because client interoperability.
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 reasons why WebDAV servers frequently have quotas enforced are
the same reasons why any storage system comes with quotas. the same reasons why any storage system comes with quotas.
o Sometimes the storage service charges according to quota o Sometimes the storage service charges according to quota
o Sometimes the storage service is provided free, but the storage o Sometimes the storage service is provided free, but the storage
service provider has limited storage space (e.g. service provider has limited storage space (e.g. university-
university-provided student accounts) provided student accounts)
o Even in cases where the storage can be upgraded, the storage o Even in cases where the storage can be upgraded, the storage
managers may choose to limit quota in order to encourage users to 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 limit the files they store on the system and to clean up obsolete
files. (e.g. IT departments within corporations) files. (e.g. IT departments within corporations)
In order to work best with repositories that support quotas, client In order to work best with repositories that support quotas, client
software should be able to determine and display the software should be able to determine and display the DAV:quota-
DAV:quota-available-bytes (defined below) on collections. Further, available-bytes (defined below) on collections. Further, client
client software should have some way of fairly reliably determining software should have some way of fairly reliably determining how much
how much storage space is already counted towards that quota. storage space is already counted towards that quota.
Support for the properties defined in this document enhances the Support for the properties defined in this document enhances the
client experience, because the client has a chance of managing its client experience, because the client has a chance of managing its
files to avoid running out of allocated storage space. Clients may files to avoid running out of allocated storage space. Clients may
not be able to calculate the value as accurately on their own, not be able to calculate the value as accurately on their own,
depending on how total space used is calculated by the server. depending on how total space used is calculated by the server.
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 two live properties. This specification can be met on a is to define two live properties. This specification can be met on a
server by implementing both DAV:quota-available-bytes and server by implementing both DAV:quota-available-bytes and DAV:quota-
DAV:quota-used-bytes on collections only. used-bytes on collections only.
A <DAV:allprop> PROPFIND request SHOULD NOT return any of the A <DAV:allprop> PROPFIND request SHOULD NOT return any of the
properties defined by this document. 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 DAV:quota-available-bytes and DAV:quota-used-bytes definitions The DAV:quota-available-bytes and DAV:quota-used-bytes definitions
below borrow heavily from the quota definitions in the NFS [RFC3530] below borrow heavily from the quota definitions in the NFS [RFC3530]
specification. specification.
skipping to change at page 4, line 47 skipping to change at page 4, line 47
resource that has the DAV:quota-used-bytes property. resource that has the DAV:quota-used-bytes property.
Clients SHOULD expect that as the DAV:quota-available-bytes on a Clients SHOULD expect that as the DAV:quota-available-bytes on a
resource approaches 0, further allocations to that resource may be resource approaches 0, further allocations to that resource may be
refused. A value of 0 indicates that users will probably not be able refused. A value of 0 indicates that users will probably not be able
to perform operations that write additional information (e.g. a PUT to perform operations that write additional information (e.g. a PUT
inside a collection), but may be able to replace through overwrite an inside a collection), but may be able to replace through overwrite an
existing resource of equal size. existing resource of equal size.
Note that there may be a number of distinct but overlapping limits, Note that there may be a number of distinct but overlapping limits,
which may even include physical media limits. When reporting which may even include physical media limits. When reporting DAV:
DAV:quota-available-bytes, the server is at liberty to choose any of 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 those limits but SHOULD do so in a repeatable way. The rule may be
configured per repository, or may be "choose the smallest number". configured per repository, or may be "choose the smallest number".
If a resource has no quota enforced or unlimited storage ("infinite If a resource has no quota enforced or unlimited storage ("infinite
limits"), the server MAY choose not to return this property (404 Not limits"), the server MAY choose not to return this property (404 Not
Found response in Multi-Status), although this specification Found response in Multi-Status), although this specification
RECOMMENDS that servers return some appropriate value (e.g. the RECOMMENDS that servers return some appropriate value (e.g. the
amount of free disc space). A client cannot entirely assume that amount of free disc space). A client cannot entirely assume that
there is no quota enforced on a resource that does not have this 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. property, but might as well act as if there is no quota.
skipping to change at page 5, line 51 skipping to change at page 5, line 51
resources for which a DAV:quota-used-bytes is maintained (e.g. "all 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", 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 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 SHOULD do so in a repeatable way. The rule may be configured per
repository. repository.
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.
This value of this property is computed (see Section 1.4.3 of
[RFC3253] for the definition of computed property). 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.
5. Example PROPFIND request and response 5. 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 6, line 46 skipping to change at page 7, line 10
<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>
6. 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) fails because it would exceed their PROPFIND, MKCOL, MOVE or COPY) fails because it would exceed their
allotted quota. In order to differentiate the response from other quota or physical storage limits. In order to differentiate the
storage problems, the server SHOULD include an XML error body as response from other storage problems, the server SHOULD include an
defined by DeltaV [RFC3253] with the <DAV:quota-not-exceeded/> XML error body as defined by DeltaV [RFC3253] with the appropriate
precondition tag. precondition tag.
Preconditions:
(DAV:quota-not-exceeded): the allocated quota MUST NOT be exceeded by
the request.
(DAV:sufficient-disk-space): there is sufficient physical space to
execute the request.
Example error response: Example error response:
HTTP/1.1 507 Insufficient Storage HTTP/1.1 507 Insufficient Storage
Content-Length: xxx Content-Length: xxx
Content-Type: text/xml Content-Type: text/xml
<?xml version="1.0"> <?xml version="1.0">
<error xmlns="DAV:"> <error xmlns="DAV:">
<quota-not-exceeded/> <quota-not-exceeded/>
</error> </error>
Implementation note: some client may be be able to take advantage of
the different precondition codes when mapping to operating system
status codes, such as E_NOSPC and E_DQUOT in NFS (see [RFC3530],
Section 12).
7. 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 8, line 5 skipping to change at page 8, line 28
with 100% accuracy whether a given file will be allowed given the with 100% accuracy whether a given file will be allowed given the
storage quota. storage quota.
o Deleting or overwriting a resource may not free up the same amount o Deleting or overwriting a resource may not free up the same amount
of storage as indicated by the DAV:getcontentlength property of storage as indicated by the DAV:getcontentlength property
defined in [RFC2518] for the resource. If deleting a resource defined in [RFC2518] for the resource. If deleting a resource
does not free up any space, the file may have been moved to a does not free up any space, the file may have been moved to a
"trash" folder or "recycle bin", or retained as in versioning "trash" folder or "recycle bin", or retained as in versioning
systems ([RFC3253]). systems ([RFC3253]).
o The total size of a collection, DAV:quota-used-bytes, may not be a o Since there are many factors that affect the storage used by a set
sum of the DAV:getcontentlength properties for resources stored in of resources, including automatic compression, the size of
the collection. associated metadata, and server-inserted content (such as that
created by PHP code) in the on-the-wire representation of
resources, clients are advised to not depend on the value of DAV:
quota-used-bytes being the sum of the DAV:getcontentlength
properties for resources contained by a collection.
o Additionally, because there may be a number of distinct but
overlapping sets of resources for which a DAV:quota-used-bytes is
maintained (Section 4), there may be no correlation between the
size of the resources in a collection and DAV:quota-used-bytes.
For example a server that implements user-based quotas, DAV:quota-
used-bytes usually will be the same for a collection and it's
members.
o On some systems where quota is counted by collection and not by o On some systems where quota is counted by collection and not by
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
the parent collection that contains it. For example, the quota on the 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
skipping to change at page 8, line 49 skipping to change at page 9, line 35
Whitehead, among others, have provided valuable comments on this Whitehead, among others, have provided valuable comments on this
document. document.
12. References 12. References
12.1 Normative References 12.1 Normative References
[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,
2002. March 2002.
12.2 Informative References 12.2 Informative References
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M. and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
Authors' Addresses Authors' Addresses
Brian Korver Brian Korver
Xythos Software Network Resonance, Inc.
One Bush Street 2483 E. Bayshore Road
Suite 600 Suite 212
San Francisco, CA 94104 Palo Alto, CA 94303
US US
Phone: +1 415 248-3800 Phone: +1 415 812-7705
Email: briank@xythos.com Email: briank@networkresonance.com
Lisa Dusseault Lisa Dusseault
Open Source Applications Foundation Open Source Applications Foundation
543 Howard Street 543 Howard Street
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
 End of changes. 

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