W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

Re: I-D ACTION:draft-ietf-webdav-quota-01.txt

From: Brian Korver <briank@xythos.com>
Date: Fri, 21 Mar 2003 17:10:18 -0800
Cc: "WebDAV" <w3c-dist-auth@w3.org>
To: "Julian Reschke" <julian.reschke@gmx.de>
Message-Id: <0C1E5E0E-5C03-11D7-894D-000393751598@xythos.com>

On Thursday, March 20, 2003, at 12:38  AM, Julian Reschke wrote:
> Right, RFC3010 doesn't define the term, but it uses the concept. I just
> think that it makes sense to give the concept a name:
>
>          The value in bytes which represent the amount of disc 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 reduce the "quota_avail_hard" of
>          every other file or directory in the set.
>
>          Note that there may be a number of distinct but overlapping
>          sets of files or directories for which a quota_used value 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-
>          filesystem or may be "choose the set with the smallest quota".
>
> So basically, a "quota space" is the set of resources that share the 
> same
> quota.

I'm not sure how important I think defining "quota space" is, but
I'd I'll add it since you think it would be helpful.


>
> For the record, i'm absolutely in favor to stick with the definitions 
> from
> RFC3010. Why don't we just steal them verbatim, or just refer to 3010?

They require minor tweaking, so I think it would be easier to
steal them.


>
> IMHO,
>
>          The value in bytes which represents the amount of additional
>          disk space that can be allocated to this file or directory
>          before the user may reasonably be warned.  It is understood
>          that this space may be consumed by allocations to other files
>          or directories though there is a rule as to which other files
>          or directories.
>
> is very clear (we may have to map some terms though). If we stick with 
> this
> language it's also much clearer why the distinction between plain 
> resources
> and collections (and other types) really doesn't make sense at all -- 
> I'd
> prfer the spec not to say anything about that.

I agree that it's clear.  The problem is that we defined things a little
differently from NFS:  DAV:quota-limit-bytes is different from
NFS's quota_avail_hard, in that

    DAV:quota-limit-bytes - DAV:quota-used-bytes = quota_avail_hard

We talked about doing this because we wanted the "amount free" that
is displayed to the user to be what the user expects rather than
a value computed by the client, which might not end up as a round
number.

I think the definition of DAV:quota-limit-bytes (and 
DAV:quota-assigned-bytes)
could be clearer, so any wordsmithing suggestions would be
appreciated.


>
> That didn't come through. Now it reads:
>
>    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.
>
> That sounds as if *usually* the property is read-only.

That makes sense.  For instance, most users shouldn't be able to
change my quota, as I shouldn't be able to change theirs.


>
> BTW: why do we need an additional property for that?

There are several instances where there are 2 numbers for
quota.  For instance, the quota system given in the example.
In the example, the assigned quota for B is 10,000,000 bytes,
while the limit is 1,000,000.  I'll try to make that clearer
in the example.

-brian
briank@xythos.com
Received on Friday, 21 March 2003 20:10:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:03 GMT