W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

Re: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 02 Sep 2004 20:50:03 +0200
Message-ID: <41376B5B.7020003@gmx.de>
To: Brian Korver <briank@xythos.com>
CC: w3c-dist-auth@w3.org

Thanks for the feedback, Brian. Comments follow inline.


Brian Korver wrote:

>> 01-C02 (third property)
>> <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.
>>
>> At the end of the day, unless we can agree about how this is supposed  
>> to work I strongly suggest to leave it out of the base spec and use a  
>> vendor-specific property for setting it.
> 
> 
> A while back I asked those who objected to the specifics
> of the authorable quota functionality to propose
> alternative methods of obtaining that functionality,
> which no one responded to until your proposal here.

(it's the same proposal I made last autumn)

> That's a reasonable idea if no vendors plan to support
> authorable quotas in an interoperable manner, which
> may be true.  So let me ask this of the list: if you
> do (or are possibly planning to) support quotas in your
> server implementation, will you never be making those
> quotas authorable and hence have no need for this
> as an optional feature of the quota spec?  I know
> Xythos would like to do this in an non-proprietary
> (interoperable) manner.

It's good that you ask; and I'm interested to find out what people 
think. If we don't need this right now we can vastly simplify the spec. 
On the other hand, if people want it, someone needs to figure out how 
this is going to work in a predictable manner.

>> 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>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/ 0184.html>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/ 0193.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)
> 
> 
> When this was discussed in the past (for instance in SC)
> the general consensus was that clients want a single number
> to display.  If you want to revisit that issue and by proposing
> another property be added, perhaps a good place to start would
> be to provide the text to the list for discussion.

If people are interested to send information about physical storage 
limits, I'll be happy to make a proposal. The main point being that 
quotas and physical storage limits are *not* the same thing; and 
throwing them together potentially causes confusion, in particular if 
you want to make the quota part authorable (see older messages). 
Therefore I'd favor a separate document describing that property.

> I think a necessary part of that text should be to discuss
> how a client should decide which number to display when both
> properties are returned.  However, how many implementations

Display both, or the smaller one?

> will return both?  AFAIK, the two implementations of the quota
> property (ours and Apple's) will only return one of the
> properties (or possibly both set to exactly the same thing)
> since there's no real semantic difference between the two.

There is, for instance when mapping HTTP status codes (which should be 
distinguishable) to OS error codes (for instance, Unix has different 
errnos to map to).

> ...
>> 03-C01 spec organization/semantics
>>
>> Back when draft 02 was published, we had a mailing list discussion  
>> about using the term "quota space" to simplify the rest of the spec.
>>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/ 0294.html>
>>
>> Unfortunately, neither was the discussion was finished nor do I see a  
>> change in the spec.
> 
> 
> Right, no one explained how to use "quota space" to simplify the
> spec (especially given we just copy-and-pasted the property
> description text from the NFS spec) or provided the requested
> replacement text.

Well, nobody likes to do heavy editorial work unless there's a chance 
it'll get used. If we agree that it makes sense to use that terminology, 
and to base the remainder of the spec on these definitions, then I'll 
gladly make a proposal.

 > ...

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 2 September 2004 18:50:42 GMT

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