B. Korver
                                                           L. Dusseault
   Internet Draft                                             C. Warner
   Document: draft-ietf-webdav-quota-01.txt                     Netezza
   Expires: September 2003                                   March 2003

               Quota and Size Properties for DAV Collections

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   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

   Example PROPFIND request and response..............................5
   Error reporting....................................................6
   Security Considerations............................................7
   Internationalization Considerations................................7
   IANA Considerations................................................7

   Dusseault              Expires March 2003                         1

                     DAV Collection Size and Quota        January 2003

   Intellectual Property..............................................7
   Author's Addresses.................................................9


   Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Requirement for quotas

   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.

   The reasons why WebDAV servers frequently have quotas enforced are
   the same reasons why any storage system comes with quotas.

    - Sometimes the storage service charges according to quota

    - Sometimes the storage service is provided free, but the storage
   service provider has limited storage space (e.g. www.sharemation.com
   and university-provided student accounts)

    - 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 quota-limit on
   collections.  Further, client software should have some way of
   fairly reliably determining how much storage space is already
   counted towards that quota.

   In addition to displaying the quota-limit and quota-used on
   collections, this specification does not forbid these properties on
   any resource.

   Solution Overview

   The approach to meeting the requirements and scenarios outlined
   above is to define three live properties.  This specification can be

   Korver                  Expires Jul 2003                          2

                    DAV Collection Size and Quota        January 2003

   met on a server by implementing both quota-limit and quota-used on
   collections only.  Implementing both quota-limit and quota-used on
   all resources is recommended.

   None of these properties need be returned in a <DAV:allprop> request
   though the server may include them.  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 definitions below for quota-limit and quota-used borrow heavily
   from the definition of quota in the NFS [RFC3010] specification.


   Name: quota-limit-bytes
   Namespace: DAV:
   Purpose: Indicates the total amount of storage potentially
   DTD: <!ELEMENT quota-limit-bytes (#PCDATA) >

   The DAV:quota-limit-bytes property value is the total amount of
   storage space potentially allocated to this file or directory,
   measured in octets.

   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.

   A value of 0 indicates that storage is limited to 0.  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.

   If a resource has no quota enforced or unlimited storage, 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.  A 403 Forbidden response
   is RECOMMENDED for attempts to write a protected property.


   Name: quota-used-bytes
   Namespace: DAV:
   Purpose: Contains the amount of storage counted against the quota-
   limit of a resource.
   DTD: <!ELEMENT quota-used-bytes (#PCDATA) >

   Korver                  Expires Jul 2003                          3

                    DAV Collection Size and Quota        January 2003

   The DAV:quota-used-bytes value is the value in octets representing
   the amount of space used by this file or directory 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
   file or directory in the set will count against the quota-limit.  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 quota-limit.

   Clients SHOULD expect that once the quota-used on a file or
   directory meets or exceeds the quota-limit, further allocations to
   that file or directory will be refused.  A resource may show more
   quota-used than its quota-limit or quota-assigned appears to allow.

   Note that there may be a number of distinct but overlapping sets of
   files or directories for which a quota-used 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, or may be ôchoose the set with the smallest quotaö.

   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-limit-bytes property.

   Support for this property enhances the client experience, because
   together with DAV:quota-limit-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


   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.

   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

   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-assigned MUST NOT be less

   Korver                  Expires Jul 2003                          4

                    DAV Collection Size and Quota        January 2003

   than the quota-limit.  Servers which receive a request to change
   quota-assigned to a value less than quota-limit MUST reduce quota-
   limit to this value at the same time.

   For many quota systems, quota-assigned is synonymous with quota-
   limit. However, in any system, quota-limit is a hard limit.  For
   example, 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 1,000,000 bytes and then creates a sub-collections B
   which is given quota-assigned of 10,000,000 bytes.  In this case,
   the quota-limit for B is 1,000,000 bytes.

Example PROPFIND request and response


     PROPFIND /~milele/public/ HTTP/1.1
     Depth: 0
     Host: www.sharemation.com
     Content-Type: text/xml
     Content-Length: xxx

     <?xml version="1.0" ?>
     <D:propfind xmlns:D="DAV:">


     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:status>HTTP/1.1 200 OK</D:status>

   Korver                  Expires Jul 2003                          5

                    DAV Collection Size and Quota        January 2003

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 <DAV:storage-quota-reached/>
   precondition tag.

   Example error response:

   HTTP/1.1 507 Insufficient Storage
   Content-Length: 100
   Content-Type: text/xml

   <?xml version=ö1.0ö>
   <error xmlns=öDAV:ö>


   Server implementations store and account for their data in many
   different ways.  Some of the challenges:

    - Some server implementations find it prohibitive to count storage
   used for metadata, others may choose to do so for better accounting.

    - Older versions of resources may be stored as well.

    - Variants of one resource may exist with different content lengths

    - Content may be dynamically generated.

    - Resource bodies can be compressed

    - Some resources may be stored for ôfreeö, not counting against

   Since server storage accounting can vary so much, clients should
   expect the following:

    - 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 with
   100% accuracy whether a given file will be allowed given the storage

    - Deleting or overwriting a resource may not free up the same
   amount of storage as indicated by the DAV:getcontentlength property
   defined in [RFC2518] for the resource.  If deleting a resource does
   not free up any space, the file may have been moved to a ôtrashö

   Korver                  Expires Jul 2003                          6

                    DAV Collection Size and Quota        January 2003

   folder or ôrecycle binö, or retained as in versioning systems

    - The total size of a collection, DAV:quota-used-bytes, is not
   necessarily a sum of the DAV:getcontentlength properties for
   resources stored in the collection.

    - 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
   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.

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.

Internationalization Considerations

   Quota is counted in Arabic numerals expressed in strings. There are
   no internationalization considerations.

IANA Considerations

   There are no IANA considerations.

Intellectual Property

   The following notice is copied from [RFC2026], and describes the
   position of the IETF concerning intellectual property claims made
   against this document.

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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

   Korver                  Expires Jul 2003                          7

                    DAV Collection Size and Quota        January 2003

   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.

   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


   Jim Whitehead and Jim Luther provided valuable comments on this

   Korver                  Expires Jul 2003                          8

                    DAV Collection Size and Quota        January 2003


   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2026] Bradner, S., ôThe Internet Standards Process û Revision
      3ö, BCP 9, RFC2026, October 1996.

   [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and
      Jensen, D., "HTTP Extensions for Distributed Authoring --
      WebDAV", RFC2518, February 1999.

   [RFC3010] Shepler S., B. Callaghan, D. Robinson, R.  Thurlow, C.
      Beame, M. Eisler, D. Noveck,  ôNFS version 4 Protocolö, RFC3010,
      December 2000.

Author's Addresses

   Brian Korver
   Xythos Software, Inc.
   77 Maiden Lane, Suite 200    Phone:  1-415-248-9033
   San Francisco, CA, USA       Email:  briank@xythos.com

   Lisa Dusseault
   Xythos Software, Inc.
   77 Maiden Lane, Suite 200    Phone:  1-415-248-9004
   San Francisco, CA, USA       Email:  lisa@xythos.com

   Clark Warner
   Netezza Corporation
   200 Crossing Blvd.           Phone:  1-508-665-6800 x889
   Framingham, MA 01702         Email:  webdav@thewarners.com

   Korver                  Expires Jul 2003                          9