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

From: Julian Reschke <[email-masked]>
Date: Sat, 28 Aug 2004 19:45:36 +0200

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>

---

From: Brian Korver <[email-masked]>
Date: Tue, 31 Aug 2004 16:01:52 -0700

> I'm happy to help restructuring the document if this is just a  

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.

> 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  

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.

> semantics (it treats disk limits as a separate property, and so should  

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.

> 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  

Right. I'll change the text to:

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

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

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.

> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/ 

Will do.

-brian
[email-masked]