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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 08 Nov 2003 10:22:26 +0100
Message-ID: <3FACB5D2.4020000@gmx.de>
To: Brian Korver <briank@xythos.com>
Cc: w3c-dist-auth@w3.org

Brian Korver wrote:

>> 01-C02 DAV:quota-assigned-bytes
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0425.html>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0436.html>
>>
>> The issue here seems to be that an additional property is required to  
>> make the quota authorable. I honestly haven't understood yet why it's  
>> needed. The problem seems to be that as the reported quota may be a  
>> "best pick" by the server (there may be multiple quotas in place, but  
>> only the most strict will be reported at any point of time). If this  
>> is the case this could potentially be fixed by exposing all quotas to  
>> the client.
> 
> 
> The issue of supporting "many" quotas on a resource was discussed
> and rejected.

True. This is a simplification that works well as long as the quota is 
not authorable. If it becomes authorable (by means of this additional 
property), there's a big issue because the behavior of the server 
becomes completely unpredictable.

>> 01-C03 quota vs disk space
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0439.html>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0460.html>
>>
>> The spec says that servers may expose physical disk limits as quota.
>>
>> a) This is incompatible with NFS from which we're borrowing the  
>> semantics (it treats disk limits as a separate property, and so 
>> should  we)
>> b) Stefan raised interesting usability issue that weren't resolved so  
>> far  (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
>> 0456.html>).
> 
> 
> Perhaps you're still looking at an older version of the draft?
> Addressing this issue was the biggest change between -01 and -02.

Nope. Somewhere on page 3 it says:

"Note that there may be a number of distinct but overlapping limits, 
which may even include physical media limits."

(wouldn't it be nice to have section numbers?)

>> 02-C01 Condition Name
>>
>> Use name of precondition, not failure description:  
>> <quota-not-exceeded/> instead of <storage-quota-reached/>
> 
> 
> Does anyone else want to vote on the necessity of this change?

Please.

>> 02-C02 allprop marshalling
>>
>> Change to MUST NOT (to reflect current ACL/DeltaV/Ordering approach).
> 
> 
> Could you provide the text?

Change:

     None of these properties need be returned in a <DAV:allprop> request
     though the server may include them.  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.

to

"A DAV:allprop PROPFIND request SHOULD NOT return any of the properties 
defined by this document."

(or just refer to RFC3253, section 3.11)


Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 8 November 2003 04:27:53 GMT

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