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

On Aug 28, 2004, at 10:45 AM, Julian Reschke wrote:
> Issues with draft-ietf-webdav-quota-03.txt
>
>
> Content
>
> 01-C01 Organization
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
> 0425.html>
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
> 0438.html>
>
> I think the draft could greatly benefit by a more clean separation of  
> (a) terminology, (b) protocol (property/error code) definition and (c)  
> examples.
>
> Proposal for a outline:
>
> 1 Introduction/Notation/Terminology
> 2 Additional live properties
> 3 Modification to behaviour of existing methods (error marshalling)
> 4...n Other standard RFC section
> A (Appendix) Examples of how servers may implement quota
>
> I'm happy to help restructuring the document if this is just a  
> amount-of-work issue.

The spec is so short that such a restructuring seems to me
to be more pedantic make-work than "great benefit", but since
the spec is so short, this arguably isn't an amount-of-work
issue and should be performed given enough WG interest.


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


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



>
>
>
> 02-C01 Condition Name
>
> Use name of precondition, not failure description:  
> <quota-not-exceeded/> instead of <storage-quota-reached/>

Unless anyone objects, I'll make that change.


>
>
> 02-C02 allprop marshalling
>
> See also  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/ 
> 0175.html>
>
> Change to MUST NOT (to reflect current ACL/DeltaV/Ordering approach).
>
> As of draft 03, this now says:
>
>   "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."
>
> So, please, make it consistent with RFC3253, RFC3648 and RFC3744.  
> Also, it's unclear why a server would ever be allowed to hide it upon  
> PROPFIND/DAV:propname. Please clarify.

Right. I'll change the text to:

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


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


>
>
>
>
> Editorial:
>
> 03-E01 incorrect IPR statement (RFC2026 is outdated)
>
> 03-E02 outdated reference to NFS spec (3010 -> 3530)
>
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/ 
> 0197.html>

Will do.

-brian
briank@xythos.com

Received on Tuesday, 31 August 2004 23:02:24 UTC