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

Re: Review of draft-ietf-webdav-quota-02.txt

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 14 Nov 2003 11:27:03 +0100
Message-Id: <1693B4A4-168D-11D8-A8E2-00039384827E@greenbytes.de>
Cc: w3c-dist-auth@w3.org
To: Brian Korver <briank@xythos.com>


I put my mind into blank slate mode and read the draft 2 for the first 

I think it is a big improvment from where we started from. One item I 
confusing though and that is the example for DAV:quota-assigned-bytes
(and the mental model behind the example).

The draft seems to say that /A and /A/B have separate 
properties, however they are in the same "set of collections" when the 
of DAV:quota-available-bytes/DAV:quota-used-bytes is computed.

(See definition of "set" in the explanation to DAV:quota-used-bytes - 
seems to
be a copy from the NFS spec.)

In NFS-Quota, the model seems to be simple: each quota applies to a set
of collections/files and each member of this set would report the same
quota properties.

In WebDAV-quota (draft-2): there is a separate quota for each collection
(e.g. the assigned-bytes), but available-/used-bytes are the same for
resources in the same set.

Two Problems come to my mind now:
1) If a collection of the "set" has the DAV:quota-assigned-bytes not
   explicitly set, what value would it report? Say for /A/C, /A/B/D and
   /E (all in the same set)?

2) If a client wants to increase DAV:quota-available-bytes in a certain
   collection, it has to increase the DAV:quota-assigned-bytes. But in
   your example: increasing assigned-bytes on /A/B will not have any
   effect on the DAV:quota-available-bytes. What is a generic client 
   to do then?

Best Regards, Stefan

Am 13.11.2003 um 22:06 schrieb Brian Korver:

> On Thursday, November 13, 2003, at 01:14  PM, Julian Reschke wrote:
>> Brian,
>> when I re-raised these issues, I *did* read the current draft. So I 
>> think it's up to you to go back to the mailing list discussion and 
>> explain why the concerns raised by Stefan and myself aren't valid.
>> Julian
> Julian,
> I'm planning to do so in today's meeting, but to restate for the 
> mailing list,
> Stefan pointed out that if we used quota-limit, then quota-limit would 
> not be
> a fixed value (which is the reason we defined things in terms of 
> quota-limit
> to begin with).  Thus, instead of quota-limit, the new draft uses NFS's
> quota-available.  This has the semantics that it isn't fixed.  Problem 
> solved.
> Note, quota-available is consistent with the rest of the the quota 
> definitions
> we pulled from NFS, so it's conceptually attractive too.
> I still don't know what you find confusing, so I can't comment on that 
> yet.
> -brian
> briank@xythos.com
Received on Friday, 14 November 2003 05:28:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC