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

On Sep 2, 2004, at 11:50 AM, Julian Reschke wrote:
> 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.

It's a single value.



>
>>> 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?

Right.


>
>> 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).

You lost me here.  I'm not sure what you're referring 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
>
-brian
briank@xythos.com

Received on Thursday, 2 September 2004 20:12:32 UTC