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

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.


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.


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)



02-C01 Condition Name

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


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.


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.




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>

Received on Saturday, 28 August 2004 17:46:14 UTC