RFC 4331

Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections

📅 published February 2006, from ietf

Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections 💾🎀

  • RFC number: 4331
  • Authors: B. Korver (Network Resonance) and L. Dusseault (OSAF) 🫶
  • Working group: Network Working Group
  • Category: Standards Track ✨ (this is a real standards-track protocol spec, so it's a big deal 🔥)
  • Date: February 2006 📅
  • Obsoletes and updates: the title block doesn't list anything it obsoletes or updates 🧚

Status of This Memo 🦋

Okay so this is an Internet standards track protocol for the Internet community, and the authors are literally asking for discussion and suggestions for improvements 💅. If you want the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2006) 💜.

Abstract 🌸

Okay, so WebDAV servers (Web Distributed Authoring and Versioning) get deployed with quota limits all the time 😭. This doc covers the properties and the little behaviors clients need so they can actually play nicely with those quota setups on WebDAV repositories 🫶.

Table of Contents 📖

   1. Introduction ....................................................2
      1.1. Notational Conventions .....................................2
      1.2. Requirement for Quotas .....................................2
   2. Solution Overview ...............................................3
   3. DAV:quota-available-bytes .......................................3
   4. DAV:quota-used-bytes ............................................4
   5. Example PROPFIND Request and Response ...........................5
   6. Error Reporting .................................................6
   7. Notes ...........................................................6
   8. Security Considerations .........................................8
   9. Internationalization Considerations .............................8
   10. Acknowledgements ...............................................8
   11. References .....................................................8
      11.1. Normative References ......................................8
      11.2. Informative References ....................................8

1. Introduction ✨

1.1. Notational Conventions 🧠

Okay so 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] 💖.

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 💅

WebDAV servers based on [RFC2518] have already been implemented and deployed with quota restrictions on collections and users. So it makes total sense to standardize this functionality, because it improves the user experience and client interoperability 🔥.

The reasons WebDAV servers frequently have quotas enforced are literally the same reasons any storage system has 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 (for example, university-provided student accounts) 🎓.
  • Even in cases where the storage can be upgraded, the storage managers may choose to limit quota. The point is to encourage users to limit the files they store and to clean up obsolete files (for example, IT departments within corporations) 🧹.

To work best with repositories that support quotas, client software should be able to determine and display the DAV:quota-available-bytes (defined below) on collections ✨. Also, client software should have some way of fairly reliably determining how much storage space is already counted towards that quota 👀.

Supporting the properties defined in this document makes the client experience way better, because the client gets a chance to manage its files and avoid running out of allocated storage space 🦋. Clients may not be able to calculate the value as accurately on their own, depending on how the server calculates total space used 🙈.

2. Solution Overview 🧚

The way we meet the requirements and scenarios 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 👑.

A <DAV:allprop> PROPFIND request SHOULD NOT return any of the properties defined by this document. 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 of DAV:quota-available-bytes and DAV:quota-used-bytes below borrow heavily from the quota definitions in the Network File System (NFS) [RFC3530] specification 🌸.

3. DAV:quota-available-bytes 🎀

  • Name: quota-available-bytes
  • Namespace: DAV:
  • Purpose: Indicates the maximum amount of additional storage available to be allocated to a resource.
  • DTD:
<!ELEMENT quota-available-bytes (#PCDATA) >

Okay so the DAV:quota-available-bytes property value is the number of octets representing the amount of additional disk space beyond the current allocation that can be allocated to this resource before further allocations get refused 😭. It's understood that this space may be eaten up by allocations to other resources too 💀.

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

Clients SHOULD expect that as the DAV:quota-available-bytes on a resource gets close to 0, further allocations to that resource may be refused 👀. A value of 0 means users will probably not be able to do operations that write additional information (for example, a PUT inside a collection). They may still be able to replace an existing resource of equal size through overwrite 🫶.

There may be a bunch of distinct but overlapping limits, and they might even include physical media limits 🌈. When reporting DAV:quota-available-bytes, the server is free to choose any of those limits, but it SHOULD do so in a repeatable way 🔁. The rule may be configured per repository, or it may be "choose the smallest number" ✨.

If a resource has no quota enforced or has unlimited storage ("infinite limits"), the server MAY choose not to return this property (a 404 Not Found response in Multi-Status). That said, this specification RECOMMENDS that servers return some appropriate value, like the amount of free disk space 🍓. A client can't totally assume there's no quota enforced on a resource that doesn't have this property, but it might as well act like there's no quota 🧁.

The value of this property is protected (see Section 1.4.2 of [RFC3253] for the definition of protected properties). 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 🔒💖.

4. DAV:quota-used-bytes 🍓

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

The DAV:quota-used-bytes value is the number of octets representing the amount of space used by this resource and possibly a bunch of other similar resources 🧠. The "similar" resources have to meet at least one criterion: allocating space to any resource in the set counts 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 ✨.

There may be a number of distinct but overlapping sets of resources that get a DAV:quota-used-bytes maintained for them (for example, "all files with a given owner", "all files with a given group owner", and so on) 🌸. The server is free to choose any of those sets, but it 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 🫶.

The 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 🔒✨.

7. Notes ✨

okay so server implementations store and account for their data in SO many different ways 😭 here are some of the challenges:

  • some server implementations find it prohibitive to count storage used for metadata 🙈 others might 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 quota 🎀

since server storage accounting can vary this much, clients should expect the following, bestie:

  • 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 🫠 so the client cannot predict with 100% accuracy whether a given file will be allowed given the storage quota. no cap, it's unpredictable 💀
  • 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" folder or "recycle bin", or retained as in versioning systems ([RFC3253]). the plot twist is giving 🦋
  • there are so many factors that affect the storage used by a set of resources, including automatic compression, the size of associated metadata, and server-inserted content (such as that created by PHP code) in the on-the-wire representation of resources. so clients are advised not to depend on the value of DAV:quota-used-bytes being the sum of the DAV:getcontentlength properties for resources contained by a collection. don't build your whole life on that math, periodt 🧮💖
  • 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, for a server that implements user-based quotas, DAV:quota-used-bytes usually will be the same for a collection and its members. iconic consistency 👑
  • 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 the 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 lets the space used by /~milele/public/ be as large as the quota on /~milele/ allows (depending on the other contents of /~milele/), even if the quota on /~milele/ is changed. so 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 🧚

8. Security Considerations 🔐

⚠️ okay this one is serious, so read it carefully

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 🚨 main character detective energy.

9. Internationalization Considerations 🌍

quota is counted in Arabic numerals expressed in strings 🔢 there are no internationalization considerations, so we're all good 💅

10. Acknowledgements 🫶

Stefan Eissing, Geoff Clemm, Jim Luther, Julian Reschke, and Jim Whitehead, among others, have provided valuable comments on this document. the real MVPs 👑💖

11. References 📚

11.1. Normative References

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

11.2. Informative References

[RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
              Beame, C., Eisler, M., and D. Noveck, "Network File System
              (NFS) version 4 Protocol", RFC 3530, April 2003.

Authors' Addresses 🎀

Brian Korver
Network Resonance, Inc.
2483 E. Bayshore Road
Suite 212
Palo Alto, CA  94303
US

Phone: +1 650 812-7705
EMail: briank@networkresonance.com


Lisa Dusseault
Open Source Applications Foundation
543 Howard Street
5th Floor
San Francisco, CA  94105
US

Phone: +1 415 946-3040
EMail: lisa@osafoundation.org

the legal stuff, kept exactly as written 📜

Copyright (C) The Internet Society (2006).

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.

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.

Intellectual Property 💡

The IETF takes no position regarding the validity or scope of any
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; 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 that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

that's the whole thing, bestie 🦋✨ you made it through the entire RFC 4331 💅🎀

📦 where this page comes from