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

Julian,

Thanks again for the very thorough read of the draft.  I'll get
an -05 out very soon that incorporates the fixes.

Comments in-line....

-brian
briank@xythos.com



On Nov 1, 2004, at 11:47 AM, Julian Reschke wrote:
> 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.

You've suggested a re-write in the past and I haven't seen
any consensus that a re-write is necessary, especially at
this late stage.  This is a short spec, so let's just clean
up the typos and move it along.

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

This was discussed on the list in the past, with no clear consensus  
except
that you and I agree to disagree on this.  Someone suggested that the
problem was with using the term "quota" at all, but there wasn't any
consensus that we should change that either.

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

There was no clear consensus when I asked for a show of hands on the  
list
on whether this change was desired/required.

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

The following (mostly) editorial changes will all be cleaned up in -05:

>
>
> 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 Wednesday, 22 December 2004 19:42:06 UTC