W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

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

From: Brian Korver <briank@xythos.com>
Date: Mon, 7 Feb 2005 15:36:50 -0800
Message-Id: <23C5C89A-7961-11D9-84E6-000A95AACED2@xythos.com>
Cc: WebDAV WG <w3c-dist-auth@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

Julian,

Comments in-line...

On Jan 23, 2005, at 4:14 AM, Julian Reschke wrote:
> Hi,
>
> 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
>
> Content
>
> 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).
>
>
> 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)

fixed in -05


>
>
> 04-C07, section 3, DAV:quota-available-bytes
>
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota 
> -05.html#rfc.section.3>
>
>   "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.

Good catch.  Fixed in -06.


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

Fixed in -05


>
>
> 05-C01, Section 4, last para
>
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota 
> -05.html#rfc.section.4.p.5>
>
> "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).

Sure, fixed in -06


>
>
> 05-C02, Section 4
>
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota 
> -05.html#rfc.section.4>
>
> I think this property is "computed" (as defined in RFC3253), and the  
> spec should say so.
>
>
>
>
> 05-E01, section 1.2
>
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota 
> -05.html#rfc.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
>
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota 
> -05.html#rfc.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."

fixed in -06


>
>
> 05-E02, section 5
>
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota 
> -05.html#rfc.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).
>

Fixed in -06.  If it's still not to your liking, let me know how
and I'll change it.

>
> 05-E03, section 7
>
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota 
> -05.html#rfc.section.7>
>
> In the list, please make punctuation consistent.

Fixed in -06.


>
>
>
>
>
>
-brian
briank@xythos.com
Received on Monday, 7 February 2005 23:37:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:07 GMT