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

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

From: Chris Sharp <csharp@apple.com>
Date: Thu, 11 Dec 2003 10:30:29 -0800
Message-Id: <189E09D8-2C08-11D8-9607-003065B4EF3A@apple.com>
Cc: w3c-dist-auth@w3.org, Brian Korver <briank@xythos.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>

Just getting around to understanding this thread. I totally agree, the 
quota-assigned-bytes seems unnecessary and confusing.

On another note, I think there needs to be some clarification the way 
quota-available-bytes and quota-used-bytes work.

Example:

Initial State of Repository with a Quota management system:

                                                                  
DAV:quota-available-bytes   DAV:quota-used-bytes
         /A                                                     95MB     
                                     5MG <--- used for somewhere for 
something
         /A/UploadDirectory                      10MB                    
                       0

A new 5MB resource is created at  /A/UploadDirectory/new5MBFile:
                                                                  
DAV:quota-available-bytes   DAV:quota-used-bytes
         /A                                                     90MB     
                                     10MB
         /A/UploadDirectory                      5MB                     
                        5MB

Pretty clear, however, if there is no quota differentiation on 
/A/UploadDirectory, the current draft of the RFC makes 
quota-used-bytes, which is really inherited from its parent, 
incongruent with quota-available-bytes on the same resource. A diagram 
is in order:

Initial State of Repository with a Quota management system:
(quota system on /A only)
                                                                  
DAV:quota-available-bytes   DAV:quota-used-bytes
         /A                                                     95MB     
                                     5MG

A new 5MB resource is created at  /A/UploadDirectory/new5MBFile:
                                                                  
DAV:quota-available-bytes   DAV:quota-used-bytes
         /A                                                     90MB     
                                     10MB
        /A/UploadDirectory                       90MB                    
                      5MB

The sum of quota-available-bytes and quota-used-bytes is 95 on  
/A/UploadDirectory and not 100! Logically, if you get a request for 
quota-available-bytes on a resource /A/UploadDirectory and the quota is 
actually enforced on the parent, that you would essentially walk up the 
tree until you found an appropriate "mount point" based quota 
requirement. If this is true, the quota-used-bytes should do the same 
thing. Meaning, quota-used-bytes on  /A/UploadDirectory would be the 
same as quota-used-bytes /A if /A/UploadDirectory did not contain a 
more specific quota rule.

This is also an efficiency win for implementors. If an implementation 
has to support quota-used-bytes on an arbitrary URL, it is impractical 
to think that quota-used-bytes could be incrementally adjusted and 
would necessarily need to be calculated on-the-fly, which does not 
scale well for most implementations.

How NFSv4 handles this situation?


Also, under the "Notes" section, "What clients should expect" seems to 
have a sentence which is not grammatically correct.
"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."

Regards,

Chris.
On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote:

>
> Brian,
>
> I put my mind into blank slate mode and read the draft 2 for the first 
> time.
>
> I think it is a big improvment from where we started from. One item I 
> found
> 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 
> DAV:quota-assigned-bytes
> properties, however they are in the same "set of collections" when the 
> value
> 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 
> supposed
>   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 Thursday, 11 December 2003 13:30:32 GMT

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