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

From: Brian Korver <[email-masked]>
Date: Wed, 22 Dec 2004 11:41:29 -0800

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
[email-masked]

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Dec 2004 21:27:48 +0100

Brian Korver wrote:
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0425.html>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0438.html>
>>
>> (a) terminology, (b) protocol (property/error code) definition and 
>> (c)  examples.
> 
> 

Well, all I can say is that I feel the spec would benefit from that 
rewrite; and I have offered assistance to do that. However, it sounds a 
bit strange to first ignore the suggestion for over a year, only then to 
state that it's too late to make that change.

>> <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>
>>
>> semantics (it treats disk limits as a separate property, and so 
>> should  we)
>>
> This was discussed on the list in the past, with no clear consensus  except

I'd say the working group needs to make an explicit decision whether 
disk limits are in-scope or not. If they are in, we're using the wrong 
terminology here and we should fix that.

> There was no clear consensus when I asked for a show of hands on the  list

I can't recall you asking; but I'm sure you can point to a message in 
the mailing list archive?

Anyway, *I* recall that you agreed to change it 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0107.html>) 
and the only disagreement came from Lisa (in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0109.html>, 
but she said she didn't want to delay the draft because of that).

That being said: you are re-using terminology and syntax from RFC3253 in 
a slighty incompatible way. Thus, I think it's reasonable to ask *you* 
to show that there is consensus for introducing this inconsistency.

 > ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 22 Dec 2004 15:36:00 -0500

I also do not recall a show-of-hands request on this topic,
but if there had been one, I would have said that no compelling
case has been made to diverge from the conventions of RFC3253,
and therefore those conventions should be maintained.

Cheers,
Geoff

list

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 23 Dec 2004 11:31:48 -0800

> and therefore those conventions should be maintained. 

+1

- Jim

---

From: Brian Korver <[email-masked]>
Date: Thu, 23 Dec 2004 17:27:25 -0800

On Dec 22, 2004, at 12:27 PM, Julian Reschke wrote:
>>> I think the draft could greatly benefit by a more clean separation  
>>> of  (a) terminology, (b) protocol (property/error code) definition  
>>> and (c)  examples.
> rewrite; and I have offered assistance to do that. However, it sounds  
> a bit strange to first ignore the suggestion for over a year, only  
> then to state that it's too late to make that change.
>
>>> Proposal for a outline:
>>>

With my author hat on I might agree, but with my  
this-is-already-deployed
hat on I'm voting for leaving the spec as-is.  I haven't exactly noticed
an overwhelming mandate for changing "quota" to something else.

> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/ 
> 0107.html>) and the only disagreement came from Lisa (in  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/ 
> 0109.html>, but she said she didn't want to delay the draft because of  
> that).

Right, those are the emails.

I agree with Lisa that I don't feel it's worth delaying the draft
over either.  Are you saying that you would object to the draft
moving forward if your suggested change isn't made?

>
> That being said: you are re-using terminology and syntax from RFC3253  
> in a slighty incompatible way. Thus, I think it's reasonable to ask  
> *you* to show that there is consensus for introducing this  
> inconsistency.
>
> > ...
>
> Best regards, Julian
>
> -- 
-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Dec 2004 12:57:15 +0100

Brian Korver wrote:
>> disk limits are in-scope or not. If they are in, we're using the 
>> wrong  terminology here and we should fix that.
> 
> 
> With my author hat on I might agree, but with my  this-is-already-deployed

Well, the "this-is-already-deployed" point of view hardly is relevant 
here. This spec has been under discussion for over two years now, and 
progress on it has been extremely slow. If being completely compatible 
to the stuff that is already deployed was important, I would have 
expected that more energy would have been invested to actually get the 
spec out of the door.

That being said; there shouldn't be any problem at all migrating 
existing implementations to new terminology/property names. The server 
implementations can continue to support the old properties until the 
relevant clients have been upgraded.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Dec 2004 13:00:19 +0100

Brian Korver wrote:

>> 0109.html>, but she said she didn't want to delay the draft because 
>> of  that).
> 
> 

I'm convinced that re-using RFC3253 terminology in an inconsistent way 
is a Very Bad Idea, in particular if there doesn't seem to be any 
rationale for it except "personal preference". Thus, I'll continue to 
object, and, as far as I can tell from the previous mails, I seem to be 
part of the WG majority here.

Best regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Fri, 24 Dec 2004 09:06:52 -0800

Julian Reschke wrote:

> is a Very Bad Idea [...]

Reusing /any/ terminology in an inconsistent way is a bad idea -- it 
leads to confusion among implementors, makes the ensuing discussions 
overly cumbersome, etc.

Elias

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 27 Dec 2004 13:50:12 -0800

I generally agree that specification writers should re-use terminology 
consistently -- great sentiment.  However that isn't even what we're 
talking about here.
  - This isn't a case of re-using any terminology -- the issue is a set 
of new error codes with a different naming style.
  - We could go for a consistent style with RFC3253, however I found the 
RFC3253 style confusing and prefer the quota style as-is
  - The style used in the quota draft is consistent with RFC2616 style 
of describing errors in text.   E.g. HTTP generally describes the error 
("NOT FOUND") rather than the precondition ("RESOURCE MUST EXIST").

So it's RFC3253 that made the departure in style.

Lisa

On Dec 24, 2004, at 9:06 AM, Elias Sinderson wrote:

>
> Julian Reschke wrote:
>
>> I'm convinced that re-using RFC3253 terminology in an inconsistent 
>> way is a Very Bad Idea [...]
>

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 27 Dec 2004 13:51:44 -0800

The WG has already had extensive discussions on the names of the 
properties and I see no compelling reason to change them.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Dec 2004 00:50:42 +0100

> of new error codes with a different naming style.

With both a naming and usage style that is inconsistent with the spec 
that introduced the syntax. If you don't want to use it consistently, 
*please* don't use it at all.

> RFC3253 style confusing and prefer the quota style as-is

We know that, but as far as I can tell everybody except you and Brian 
clearly disagrees.

>  - The style used in the quota draft is consistent with RFC2616 style of 
> describing errors in text.   E.g. HTTP generally describes the error 

Lisa, we're not talking about HTTP status codes, but about condition 
names used inside the DAV:error element defined in RFC3253.

> So it's RFC3253 that made the departure in style.

You may argue that, but in that case the right way to approach the issue 
is not to re-use RFC3253's syntax at all.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Dec 2004 00:51:34 +0100

> properties and I see no compelling reason to change them.

I also see no compelling reason to change them as long as they are used 
for quotas, which are *not* disk limits.

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 28 Dec 2004 10:54:29 +0100

Are you proposing to change RFC 3253 to get a consistent terminology?

Am 27.12.2004 um 22:50 schrieb Lisa Dusseault:

>  - We could go for a consistent style with RFC3253, however I found 
> the RFC3253 style confusing and prefer the quota style as-is
> of describing errors in text.   E.g. HTTP generally describes the 
> error ("NOT FOUND") rather than the precondition ("RESOURCE MUST 
> EXIST").
>

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 28 Dec 2004 09:57:56 -0800

No, I certainly don't think that changing 3253 is necessary or even 
desirable.  Nor do I think it's necessary or desirable to block quota 
on this issue, no matter which way the draft has it.

(and to be pedantic, it's not a consistency of terminology, it's a 
consistency of naming style)

Lisa

On Dec 28, 2004, at 1:54 AM, Stefan Eissing wrote:

>> I generally agree that specification writers should re-use 
>> terminology consistently -- great sentiment.  However that isn't even 
>> what we're talking about here.
>>  - This isn't a case of re-using any terminology -- the issue is a 
>> set of new error codes with a different naming style.