comments on draft-ietf-webdav-quota-04.txt, was: Fwd: I-D ACTION:draft-ietf-webdav-quota-04.txt

Brian,

thanks for the new draft; getting rid of the authorability part greatly 
simplifies the spec.

Below are my updated comments.

Best regards, Julian




Issues with draft-ietf-webdav-quota-04.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 an 
amount-of-work issue.


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)

Update -04: this still appears in the text, but is less critical now 
that authorability of the quota is gone. I'd still like to see the 
working group make an explicit decision to keep this, because it's IMHO 
clearly outside the scope of this spec (I'd prefer separate properties).


02-C01 Condition Name

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


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.


04-C01, section 1.2, requirements

    "WebDAV servers based on [RFC2518] have been implemented and deployed
    with quota restrictions on collections and users, so it makes sense
    to standardize this functionality to improve user experience and
    client interoperability.  This specification requires WebDAV because
    it requires PROPFIND support and relies on the WebDAV definition of
    collections and properties, including the definitions for live and
    protected properties."

RFC2518 doesn't define "protected" property, so a reference to RFC3253, 
section 1.4.2 seems to be in order.


04-C02, section 1.2, requirements

   "o  Sometimes the storage service is provided free, but the storage
       service provider has limited storage space (e.g.  www.example.com
       and university-provided student accounts)"

This used to refer to www.sharemation.com. As it now says "example.com" 
it seems to have lost it's meaning. Maybe replace by a generic 
description of a site that offers storage to registered users.


04-C03, section 1.2, requirements

   "In addition to displaying the quota-available and quota-used on
    collections, this specification does not forbid these properties on
    any resource."

This sentence is a bit confusing, in particular as section 2 recommends 
supporting the property on all resources. Just remove it.


04-C04, section 2, solution overview

   "The approach to meeting the requirements and scenarios outlined above
    is to define three live properties."

*Two* properties.


04-C05, section 2, solution overview

   "This specification can be met on
    a server by implementing both quota-available and quota-used on
    collections only.  Implementing both quota-available and quota- used
    on all resources is RECOMMENDED."

Fix whitespace ("quota- used") and property names. Also consider using the
"DAV:propertname" syntax used in other specs.


04-C05, section 2, solution overview

   "The quota-available and quota-used definitions below borrow heavily
    from the quota definitions in the NFS [RFC3010] specification."

Fix property names and NFS reference (occurs several additional times).


04-C06, section 3, DAV:quota-available-bytes

   "The DAV:quota-available-bytes property value is the value in octets
    representing the amount of additional disk space beyond the current
    allocation that can be allocated to this file or directory before
    further allocations will be refused.  It is understood that this
    space may be consumed by allocations to other files or directories."

Replace "file or directory" by "resource". Note that neither "file" or 
"directory" exist in WebDAV terminology. (same in section 4)


04-C07, section 3, DAV:quota-available-bytes

   "Support for this property is REQUIRED on collections, and OPTIONAL on
    other resources.  A server SHOULD implement this property for each
    resource that has the DAV:quota-used-bytes property."

What's the motivation for the distinction? (same in section 4)


04-C08, section 3, DAV:quota-available-bytes

   "The value of this property is protected.  A 403 Forbidden response is
    RECOMMENDED for attempts to write a protected property."

RFC3253 defines the precondition "DAV:cannot-modify-protected-property".


04-C09, section 5, Examples

Bad XML in response (at least one missing namespace prefix, you may want 
to run the examples through a parser to check for more).


04-C10, section 6

   "WebDAV [RFC2518] defines the status code 507 (Insufficient Storage).
    This status code SHOULD be used when a client request (e.g.  a PUT,
    PROPFIND, MKCOL, MOVE or COPY) is forbidden because it would exceed
    their allotted quota."

s/is forbidden/fails/ (to avoid confusion with ACLs)


04-C11, section 7

      "The total size of a collection, DAV:quota-used-bytes, is not
       necessarily a sum of the DAV:getcontentlength properties for
       resources stored in the collection."

Actually, it won't be in most cases I'm aware of. Please either rephrase 
it (so this doesn't sound like an edge case) or drop the point.


04-C12, section 8

   "If a server chooses to make the DAV:quota-assigned-bytes writable by
    clients with sufficient authorization, then it is opening up a
    certain amount of near-administration functionality to clients.
    However, it is not required for the DAV:quota-assigned-bytes property
    to be writeable by any clients, so a server can easily avoid this
    consideration."

Right now it's a SHOULD-level requirement to make the property 
protected, so I wouldn't expect the spec to discuss the case where a 
server breaks that requirement.



Editorial:

03-E02 outdated reference to NFS spec (3010 -> 3530)

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

Update -04: the reference has been updated, but only partly (wrong date, and
still using the ID "RFC3010"). Replace by:

    [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
               Beame, C., Eisler, M. and D. Noveck, "Network File System
               (NFS) version 4 Protocol", RFC 3530, April 2003.


04-E01 Abstract

s/This Internet-Draft discusses/This document discusses/


04-E02 References

Reference to RFC2026 doesn't seem to be used anywhere.

Received on Monday, 1 November 2004 19:47:58 UTC