Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 23 Oct 2002 09:55:56 -0700

Stefan asked (a while ago, sorry to be so late): 

> I can see how this draft is applied to servers like Sharemation
> which have a separate collection hierarchy for each user. 

Sharemation does have a separate collection hierarchy for each user, but
many other Xythos WebFile Server installations have users share
collections with common names like "sales", "marketing", "hr".  The same
quota system applies to both models, as I hope I'll be able to explain.

> I have more trouble applying it to servers where it is common 
> that more than one user has write access to collections. Imagine
> that Sharemation has a collection containing all your user
> collections. How would the quota properties appear on that
> collection?

Quota is applied to a collection, *not* a user, specifically because of
the model where a user doesn't just put documents in their own home
directory.  That's explicit in the draft, and it's an important feature
to allow directories to be shared by many users and still have quota
applied.  So if a quota of 1000MB is applied to the "/sales/"
collection, the server is free to report that quota, and count space
consumed by resources in the "/sales/" collection in whatever way its
policy decides.

> Where I see a real problem is a server supporting bindings.

It's specifically left up to the server to figure out how to support
bindings -- it would be impossible for the draft to enforce how to count
space used, when it's a matter of policy and the interaction of many
potential features.  The server may:
 - count the space used by a binding as 0 bytes, 
 - count the bytes used to store the binding only and not the length of
the resource it points to
 - divide the size of the target resource among all its bindings, 
 - count the full size of the target resource against every binding.
That's why the draft requires the server to show how space is used -- it
is not possible for the standard to decide these policy matters.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 23 Oct 2002 19:05:45 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Wednesday, October 23, 2002 6:56 PM
> To: 'Stefan Eissing'; Webdav WG
> Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt
>
> ...
>

This kind of quota system is incompatible with the quota system in a Unix
filesystem (where AFAIK it's per user) -- a standard proposal must be able
to handle these kinds of systems as well.

> ...

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 23 Oct 2002 10:21:06 -0700

It seems like this draft is fine with a user-based rather than a
collection-based
system--the server will report the same usage & quota for any collection,
but
will return different results depending on who is authenticated, no?

----- Original Message -----
From: "Julian Reschke" <[email-masked]>
To: "Lisa Dusseault" <[email-masked]>; "'Stefan Eissing'"
<[email-masked]>; "Webdav WG" <[email-masked]>
Sent: Wednesday, October 23, 2002 10:05 AM
Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 23 Oct 2002 11:06:51 -0700

> to handle these kinds of systems as well.

I haven't heard of anybody implementing a WebDAV server with quota that
needed to solve this problem.  Is there an actual implementation need
for this?

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 23 Oct 2002 11:10:05 -0700

We keep track of quota per-user, not per-collection.

----- Original Message -----
From: "Lisa Dusseault" <[email-masked]>
To: "'Julian Reschke'" <[email-masked]>; "'Stefan Eissing'"
<[email-masked]>; "'Webdav WG'" <[email-masked]>
Sent: Wednesday, October 23, 2002 11:06 AM
Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 23 Oct 2002 20:32:47 +0200

> Sent: Wednesday, October 23, 2002 8:07 PM
> To: 'Julian Reschke'; 'Stefan Eissing'; 'Webdav WG'

*If* we implement quotas, they will almost certainly be user-based (at least
that's the most common quota model I'm aware of).

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 23 Oct 2002 20:41:48 +0200

> [mailto:[email-masked]]On Behalf Of Eric Sedlar
> Sent: Wednesday, October 23, 2002 7:21 PM
> To: Julian Reschke; Lisa Dusseault; 'Stefan Eissing'; Webdav WG
collection-based
but
> will return different results depending on who is authenticated, no?

No. IMHO, the draft describes a very specific quota model, which it
shouldn't if it's to be implemented generally. For instance

"   Quota is not additive.  A collection only has the quota assigned to
   it, not (in addition) the quota assigned to sub collections or any
   other collections.  Sub-collections can have different quota values
   than parent collections.  These ôsub-quotaös may act as additional
   constraints, or they may be under-constrained and have no effect.
   This can allow the delegation of quota administration from root
   administrators to collection owners. "

will not work with a quota system that is per user and filesystem/server.

To make this proposal work in the general case, it needs to be more generic.
For instance, the only questions I can easily answer with a Unix-FS-based
quota system are:

- the storage limit (for the authenticated user)
- the current storage (for the user)

and possibly

- the amount of storage taken by a particular set of resources (and that may
be expensive to compute).

Julian

---

From: Brian Korver <[email-masked]>
Date: Wed, 23 Oct 2002 11:56:06 -0700

> to handle these kinds of systems as well.

In BSD anyhow, quotas are applied to users and/or groups.  That said,
"collection quotas" (if we can even call them that) are generally 
enforced
by mounting appropriately-sized partitions.  Just FYI.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 23 Oct 2002 21:00:16 +0200

Brian,

> From: Brian Korver [mailto:[email-masked]]
> Sent: Wednesday, October 23, 2002 8:56 PM
> To: Julian Reschke
> Cc: Webdav WG
> "collection quotas" (if we can even call them that) are generally enforced

Interesting. So if we take groups into account, we'll need a more flexible
reporting mechanism, right?

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 23 Oct 2002 12:07:02 -0700

> We keep track of quota per-user, not per-collection.

And do you think the existing draft satisfies your implementation needs?

lisa

---

From: Brian Korver <[email-masked]>
Date: Wed, 23 Oct 2002 14:14:54 -0700

> reporting mechanism, right?

Possibly, although support for groups (or other such quota mechanisms)
sounds like an advanced feature, something that might motivate a new
"advanced quotas" draft.  Quotas on BSD are an optional feature -- I
wonder how many boxes even have group quotas configured at all.

-brian
[email-masked]

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 23 Oct 2002 14:23:24 -0700

All I want is for interoperable clients to have two properties:

* how much junk can I store in this collection
* how much junk have I already stored in this collection (and thus could be
used if I delete stuff, potentially)

I'm happy with the properties--I just think we need to change the text to
indicate that the quota only applies to the currently authenticated HTTP
user--an interoperable client cannot assume that the quota will be the same
if authenticated as somebody else.  I don't think we need an ability to find
out how much quota other people have.

--Eric

----- Original Message -----
From: "Lisa Dusseault" <[email-masked]>
To: "'Eric Sedlar'" <[email-masked]>; "'Julian Reschke'"
<[email-masked]>; "'Stefan Eissing'" <[email-masked]>;
"'Webdav WG'" <[email-masked]>
Sent: Wednesday, October 23, 2002 12:07 PM
Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 23 Oct 2002 23:31:50 +0200

> Sent: Wednesday, October 23, 2002 11:23 PM
> To: Lisa Dusseault; 'Webdav WG'

Yes.

> used if I delete stuff, potentially)

That's hard to answer in the presence of bindings. It's certainly not a
property of a collection.

> out how much quota other people have.

I think that if the proposal is supposed to be generic enough it shouldn't
even try to define how quotas work, how nested collections work and so on.
Just define one or two live properties (or possible one report) that gives a
client the required information.

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 23 Oct 2002 15:01:08 -0700

> property of a collection.

That's why I used the word "potentially".  It's just a way of giving the
user some
indication of how much space could be usable in this collection in the best
case
(where any other space-occupying resources have been deleted).

Certainly, if I have one collection mapping to D: and another mapping to E:
on
a Windows machine, I would have different "used" quotas for different
collections.
I don't see why it's not a collection property.

> client the required information.

I agree that there isn't really a need to define how nested collections
work.
If I have another partition mounted beneath a parent collection, the
collection
will have no idea how much space is available in that particular child
collection.
All we need is the two live properties, and language that indicates that the
only
thing quotas control is how much new content you can create (either in a
resource, or by creating new subcollections).

--Eric

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 24 Oct 2002 00:09:16 +0200

> Sent: Thursday, October 24, 2002 12:01 AM
> To: Julian Reschke; Lisa Dusseault; 'Webdav WG'
> > > * how much junk have I already stored in this collection (and
> thus could
> > be
user some
> indication of how much space could be usable in this collection  in the
best case
> Certainly, if I have one collection mapping to D: and another mapping to
E: on
collections.
> I don't see why it's not a collection property.

To compute it, you have to access collection and *all* descendants in the
namespace. So computing it may require the same amount of effort as doing a
PROPFIND with depth infinity. That's why I'd be very hesitant to consider it
being the property of a collection (yes, even taking the current allprop
semantics into account).

The things that *are* easy to answer for any resource (no matter whether
collection or plain resource) are:

- max. storage available to the user in quota-partition of the namespace in
which the collection is allocated
- current storage allocated to the user in this partition
- storage taken by *one* specific resource

Julian

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 23 Oct 2002 15:25:16 -0700

> - current storage allocated to the user in this partition

Let's redefine the current draft to use these definitions--I'm happy with
them, and I think they address Lisa's requirements as well.

--Eric

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 24 Oct 2002 10:35:56 +0200

With the current discussion the quota draft will be able to accomodate
the Sharemation model as well as a UNIX quota like system. Without
adding any complexity. As Eric pointed out, we basically need new
definitions of the properties to clarify the semantics.

In detail:

Am Mittwoch, 23.10.02, um 18:55 Uhr (Europe/Berlin) schrieb Lisa 
> quota system applies to both models, as I hope I'll be able to explain.

With that model, you are - in my view - closer to a partition model
than what is called quotas in UNIX. If I understand you correctly, 
sharemation
allocates "storage devices" to collection hierarchies and the quota 
properities
report the "space left on device". That is a valid and useful server 
model.

> consumed by resources in the "/sales/" collection in whatever way its

That's ok. But there are other servers with real user quotas which
need a more flexible definition of the WebDAV quota properties.
>  - count the space used by a binding as 0 bytes,

Then every collection will use 0 bytes. Remember that a collection
only holds bindings and nothing else.
> the resource it points to
Then every collection will use just a few bytes (as compared to the
amount taken up by the content of all resources).

>  - divide the size of the target resource among all its bindings,

Assume collections /a/b, /a/c, and two bindings to a 1 megabyte
resource in /a/b/x and /a/c/x. Then /a/b has bytes-used of 500 KB
(same for /a/c), but the client only sees a single 1MB resource
in /a/b. Certainly this bytes-used value is not very helpful for the
client in order to know the space taken up by the collection.

>  - count the full size of the target resource against every binding.

Assume again the example from above. Now collection /a will
report 2 MB as bytes-used.

> is not possible for the standard to decide these policy matters.

The solution is not to more strictly define bytes-used, but to relax the
definition.

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 24 Oct 2002 12:14:56 +0200

Am Donnerstag, 24.10.02, um 00:25 Uhr (Europe/Berlin) schrieb Eric 
Sedlar:

>
>> - max. storage available to the user in quota-partition of the 
>> namespace
> in

Agreed. Let's give it a try:

quota space
   A quota space is a storage area on a WebDAV server where the amount
   of storage for resources is restricted. The restriction might be due 
to
   physical disk size or limited by configuration options of the server.
   The storage restriction might be enforced the same for all users, 
letting
   them share the available space, or configured and enforced differently
   for each user.
   A WebDAV collection belongs to at most one quota space. Subcollections
   might belong to the same or different quota spaces.
(Comment: I'm not sure if we need identifier for quota spaces, so that
  clients could compare if two collections are in the same quota.)

A collection belonging to a quota space has the following two live
properties:

DAV:quota-free
   The DAV:quota-free property reports the amount of storage in octets
   available to the current user in the quota space the reporting 
collection
   belongs to.

   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.

    A value of 0 indicates that storage is limited to 0.  Users will
    probably not be able to add resources to the collection.

    If a collection has no quota enforced, it should not return this
    property at all.  A client cannot entirely assume that there is no
    quota enforced on a collection that does not have this property, but
    might as well act as if there is no quota.

    This property is OPTIONAL on collections and SHOULD NOT exist on
    non-collection resources.  When a new collection is created, it is
    up to the server to initialize the value appropriately if it chooses
    to.

And

DAV:quota-used
   The DAV:quota-used property reports the amount of storage in octets
   used by the current user in the quota space the reporting collection
   belongs to.

  These values are an approximation and should be treated as such.
   It is not required that DAV:quota-free and DAV:quota-used always add 
up
   to the same value.

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 24 Oct 2002 13:56:01 +0200

> [mailto:[email-masked]]On Behalf Of Stefan Eissing
> Sent: Thursday, October 24, 2002 12:15 PM
> To: [email-masked]
>    of storage for resources is restricted. The restriction might be due to
letting
>    might belong to the same or different quota spaces.

If a subcollection can belong to a separate quota space (aka Unix device),
can't this also be the case for internal members?

I think that the distinction between collections and non-collections is
essentially meaningless -- the properties defined here apply to the quota
space, not to a particular resource. Therefore they should be defined on all
resources that are quota-controlled.

>   clients could compare if two collections are in the same quota.)

May be useful.

collection
>    belongs to.

...the reporting resource...

with
>     is recommended for attempts to write a protected property.

Remove last two sentences.

>     might as well act as if there is no quota.

Replace "should not return" by something like "MUST NOT be defined on the
resource".

>     up to the server to initialize the value appropriately if it chooses

Completely remove this paragraph.

>    used by the current user in the quota space the reporting collection

... the reporting resource...

up

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 24 Oct 2002 19:31:29 +0200

Here's a proposal for the property names that reduces property clutter (by
collapsing evrything into a single property) and possibly allows expressing
multiple quota constraints:

<quota-set>

  <quota>

    <limit>...</limit>
    <used>...</used>

    <!-- optional: identifies the principal this quota applies to -->
    <principal><href>....</href></principal>

    <!-- optional: identifyer for quota-space -->
    <qutoa-space><href>....</href></quota-space>

  </quota>

  <!-- more quotas, for instance for the current user group -->
  ..

</quota-set>

The syntax is similar to lockdiscovery, so any self-respecting DAV client
should be able to handle this.

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 24 Oct 2002 11:21:41 -0700

Why do you think this is preferable for the client?  Why not keep
single-property, single-value?  This complicates things even for the
server.

lisa

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: Thursday, October 24, 2002 10:31 AM

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 24 Oct 2002 20:35:17 +0200

> Sent: Thursday, October 24, 2002 8:22 PM
> To: 'Julian Reschke'; [email-masked]

It allows marshalling of multiple quota constraints (and we know that there
may be more than one).

> single-property, single-value?  This complicates things even for the

Why? For a server that enforces only a single constraint, it's just a few
more XML tags to add. Where's the problem?

Confused,

Julian

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 25 Oct 2002 10:30:43 +0200

I think it's not a good idea to report information about
"all" quota spaces in a resource:

- the resource might not know all quotas on the server
- you need additional information which quota applies to the
   current resource

Since the reported set is likely to be incomplete (and or expensive
to compute), I think only one quote should be reported.

However, I do think that there is benefit in having one quota-xxx
property which has a XML structured value. That makes it easy to
extend in the future.

//Stefan

Am Donnerstag, 24.10.02, um 20:35 Uhr (Europe/Berlin) schrieb Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 25 Oct 2002 10:41:06 +0200

> Sent: Friday, October 25, 2002 10:31 AM
> To: Julian Reschke
> Cc: Lisa Dusseault; [email-masked]

So do I.

> - you need additional information which quota applies to the

The intent off my proposal to report exactly the quotas that *do* apply to
the resource.

> to compute), I think only one quote should be reported.

If it only contains the applicable quotas, it shouldn't be harder to compute
than a single quota.

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 25 Oct 2002 10:46:55 +0200

According to HTTP, 5xx class codes are for server errors:

"Response status codes beginning with the digit "5" indicate cases in which
the server is aware that it has erred or is incapable of performing the
request. Except when responding to a HEAD request, the server SHOULD include
an entity containing an explanation of the error situation, and whether it
is a temporary or permanent condition. User agents SHOULD display any
included entity to the user. These response codes are applicable to any
request method. "

I'd say that this is ok for a condition like "disk full", but not
necessarily for something like "quota exceeded". This is not a server error,
it's just an administrative constraint that was enforced.

Proposal: define a precondition DAV:quota-not-exceeded, and let the server
return 403 or 409.

Julian

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 25 Oct 2002 10:47:41 +0200

I think it is a new model that multiple quotas apply to the current user
for a single resource.

If I understood you wrong and you want to report all quotas for all
users, well, I think that can be:
- a very long list
- not desirable for security/privacy reasons.

//Stefan

Am Freitag, 25.10.02, um 10:41 Uhr (Europe/Berlin) schrieb Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 25 Oct 2002 10:56:33 +0200

> Sent: Friday, October 25, 2002 10:48 AM
> To: Julian Reschke

It's the BSD model, as far as I understood. In particular, there can be
separate quotas on the same device: per user and per group. If we can only
signal one of these quota, the server would have to choose between

- hiding one (making the one that was reported inaccurate) or
- computing a summary that describes both quotas (how do you do that?)

> - not desirable for security/privacy reasons.

No, that was not the intent of the proposal.