Comments on draft-ietf-webdav-quota-05.txt, Was: Fwd: I-D ACTION:draft-ietf-webdav-quota-05.txt


below is my updated issues list. In general, this draft is a real 
improvement, and besides mainly editorial questions, the main issue the 
working group should consider is whether the Quota spec should handle 
disk limits (right now it does implicitly). I personally would prefer if 
it either wouldn't do it at all, or do it explicitly (through at least a 
different set of precondition names).

Best regards, Julian

- snip -

Issues with draft-ietf-webdav-quota-05.txt


01-C03 quota vs disk space

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

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)

Update -05: this is actually in contradiction to Section 3 which says: " 
Implementing both DAV:quota-available-bytes and DAV:quota-used-bytes on 
all resources is RECOMMENDED." (note OPTIONAL != RECOMMENDED). In 
general, I think it would be wiser to have these requirements in a 
single place (so the spec can't contradict itself), whatever they are.

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.

05-C01, Section 4, last para


"Support for this property enhances the client experience, because 
together with DAV:quota-available-bytes, the client has a chance of 
managing its files to avoid running out of allocated storage space. 
Clients may not be able to calculate the value as accurately on their 
own, depending on how total space used is calculated by the server."

I think this is fluff; if you want say something like that, move it into 
the Introduction (where the motivation for the whole spec is explained).

05-C02, Section 4


I think this property is "computed" (as defined in RFC3253), and the 
spec should say so.

05-E01, section 1.2


I'd move those parts that "import" terminology from RFC2518/3253 into a 
separate subsection ("Terminology"), and also refer to the def of 
"computed" property (I think we need that later).

05-E02, section 1.2


"In order to work best with repositories that support quotas, client 
software should be able to determine and display the 
DAV:quota-available-bytes on collections."

That is a forward reference. Either add "(defined below in ...)", or 
rewrite as:

"In order to work best with repositories that support quotas, client 
software should be able to determine and display the new live properties 
defined below."

05-E02, section 5


The artwork in the request is too wide for RFC publication and should be 
re-indented (the response isn't too wide but should be re-indented for 
consistency nevertheless).

05-E03, section 7


In the list, please make punctuation consistent.

Received on Sunday, 23 January 2005 12:16:08 UTC