Subject: Re: quota-03 spec review, was: I-D ACTION:draft-ietf-webdav-quota-03.txt

From: Lisa Dusseault <[email-masked]>
Date: Thu, 2 Sep 2004 11:48:26 -0700

>>
>> 02-C01 Condition Name
>>
>> Use name of precondition, not failure description: 
>> <quota-not-exceeded/> instead of <storage-quota-reached/>
>
> Unless anyone objects, I'll make that change.
>

I do object (but not to the point of delaying quota).  My reasoning is 
that using the negative, to express the condition that must be met, is 
hard to understand for the debugger/implementor/tester or support 
person.  You see something like this:

<D:error>
   <D:quota-not-exceeded/>
</D:error>

and think "Huh?  My error is that quota is not exceeded? what's up with 
that? "  I can even imagine bugs logged against implementors who 
correctly follow the spec.

Furthermore, although this approach is consistent with the style in 
DeltaV, it's not consistent with the overall HTTP error style, which is 
to explain the error.  E.g. "404 Not Found" rather than "404 Document 
Must Exist".

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Sep 2004 20:50:03 +0200

Thanks for the feedback, Brian. Comments follow inline.

Brian Korver wrote:

>> 01-C02 (third property)
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0425.html>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0436.html>
>>
>> The issue here seems to be that an additional property is required to  
>> make the quota authorable. I honestly haven't understood yet why it's  
>> needed. The problem seems to be that as the reported quota may be a  
>> "best pick" by the server (there may be multiple quotas in place, but  
>> only the most strict will be reported at any point of time). If this  
>> is the case this could potentially be fixed by exposing all quotas to  
>> the client.
>>
>> At the end of the day, unless we can agree about how this is supposed  
>> to work I strongly suggest to leave it out of the base spec and use a  
>> vendor-specific property for setting it.
> 
> 
> A while back I asked those who objected to the specifics
> of the authorable quota functionality to propose
> alternative methods of obtaining that functionality,
> which no one responded to until your proposal here.

(it's the same proposal I made last autumn)

> That's a reasonable idea if no vendors plan to support
> authorable quotas in an interoperable manner, which
> may be true.  So let me ask this of the list: if you
> do (or are possibly planning to) support quotas in your
> server implementation, will you never be making those
> quotas authorable and hence have no need for this
> as an optional feature of the quota spec?  I know
> Xythos would like to do this in an non-proprietary
> (interoperable) manner.

It's good that you ask; and I'm interested to find out what people 
think. If we don't need this right now we can vastly simplify the spec. 
On the other hand, if people want it, someone needs to figure out how 
this is going to work in a predictable manner.

>> 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)
> 
> 
> When this was discussed in the past (for instance in SC)
> the general consensus was that clients want a single number
> to display.  If you want to revisit that issue and by proposing
> another property be added, perhaps a good place to start would
> be to provide the text to the list for discussion.

If people are interested to send information about physical storage 
limits, I'll be happy to make a proposal. The main point being that 
quotas and physical storage limits are *not* the same thing; and 
throwing them together potentially causes confusion, in particular if 
you want to make the quota part authorable (see older messages). 
Therefore I'd favor a separate document describing that property.

> I think a necessary part of that text should be to discuss
> how a client should decide which number to display when both
> properties are returned.  However, how many implementations

Display both, or the smaller one?

> will return both?  AFAIK, the two implementations of the quota
> property (ours and Apple's) will only return one of the
> properties (or possibly both set to exactly the same thing)
> since there's no real semantic difference between the two.

There is, for instance when mapping HTTP status codes (which should be 
distinguishable) to OS error codes (for instance, Unix has different 
errnos to map to).

> ...
>> 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.
> 
> 
> Right, no one explained how to use "quota space" to simplify the
> spec (especially given we just copy-and-pasted the property
> description text from the NFS spec) or provided the requested
> replacement text.

Well, nobody likes to do heavy editorial work unless there's a chance 
it'll get used. If we agree that it makes sense to use that terminology, 
and to base the remainder of the spec on these definitions, then I'll 
gladly make a proposal.

 > ...

Best regards, Julian

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Sep 2004 20:57:12 +0200

> correctly follow the spec.

On the other hand, implementors may be accustomed with the terminology 
used by RFC3253, RFC3648 and RFC3744, and become confused by a new spec 
being inconsistent with it.

Also, people seeing DAV:error (and not already familiar with RFC3253) 
will hopefully find the specification, which will point them to RFC3253, 
section 1.6, which explains it all.

If server implementors want to make it super-readable, they can still 
add additional programmer-readable prose inside an XML comment in the 
response body.

> to explain the error.  E.g. "404 Not Found" rather than "404 Document 

That's true, but I don't think it matters today. This is what RFC3253 
defines, and unless there's a *really* good reason to be inconsistent 
with that, we should stick with it.

Best regards, Julian

---

From: Brian Korver <[email-masked]>
Date: Thu, 2 Sep 2004 13:11:56 -0700

On Sep 2, 2004, at 11:50 AM, Julian Reschke wrote:
>>> The issue here seems to be that an additional property is required 
>>> to  make the quota authorable. I honestly haven't understood yet why 
>>> it's  needed. The problem seems to be that as the reported quota may 
>>> be a  "best pick" by the server (there may be multiple quotas in 
>>> place, but  only the most strict will be reported at any point of 
>>> time). If this  is the case this could potentially be fixed by 
>>> exposing all quotas to  the client.
>>>
>>> At the end of the day, unless we can agree about how this is 
>>> supposed  to work I strongly suggest to leave it out of the base 
>>> spec and use a  vendor-specific property for setting it.
> think. If we don't need this right now we can vastly simplify the 
> spec. On the other hand, if people want it, someone needs to figure 
> out how this is going to work in a predictable manner.

It's a single value.

> Display both, or the smaller one?

Right.

> distinguishable) to OS error codes (for instance, Unix has different 

You lost me here.  I'm not sure what you're referring to.

>>> Unfortunately, neither was the discussion was finished nor do I see 
>>> a  change in the spec.
> it'll get used. If we agree that it makes sense to use that 
> terminology, and to base the remainder of the spec on these 
> definitions, then I'll gladly make a proposal.
>
> > ...
>
> Best regards, Julian
>
>
> -- 
-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Sep 2004 22:21:02 +0200

>> out how this is going to work in a predictable manner.

That's not an answer. If you have a "display" property and an authorable 
property, and the former may return information depending on what's most 
"relevant" at a given point of time, clients will have a hard time to 
predictably change that property.

> You lost me here.  I'm not sure what you're referring to.

For instance, MacOSX maps HTTP status codes to Unix error codes (it's a 
filesystem mapper). Unix distinguishes between "no space left on device" 
and "quota exceeded". The protocol should allow the client to 
distinguish both cases.

Best regards, Julian

---

From: Brian Korver <[email-masked]>
Date: Thu, 2 Sep 2004 14:38:11 -0700

On Sep 2, 2004, at 1:21 PM, Julian Reschke wrote:
> That's not an answer. If you have a "display" property and an 
> authorable property, and the former may return information depending 
> on what's most "relevant" at a given point of time, clients will have 
> a hard time to predictably change that property.

There seems to be a misunderstanding (due to underspecification?).
The value of DAV:quota-assigned-bytes is intended to be deterministic.
I guess that needs to be spelled out explicitly in the spec.

>
>>> There is, for instance when mapping HTTP status codes (which should 
>>> be distinguishable) to OS error codes (for instance, Unix has 
>>> different errnos to map to).
> For instance, MacOSX maps HTTP status codes to Unix error codes (it's 
> a filesystem mapper). Unix distinguishes between "no space left on 
> device" and "quota exceeded". The protocol should allow the client to 
> distinguish both cases.

Since the only two implementations of the quota property
that I know of don't make this distinction, I think it's
difficult to argue for adding this requirement.

-brian
[email-masked]

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 2 Sep 2004 14:52:04 -0700

> device" and "quota exceeded". The protocol should allow the client to 

I disagree.  The chances that a single system has both apply in a 
meaningful way, and that the client needs to do both, and that the 
client has a way to display both, are pretty small.  The same mechanism 
can handle either case but not both at once.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Sep 2004 09:20:08 +0200

> I guess that needs to be spelled out explicitly in the spec.

So what's the relation between DAV:quota-assigned-bytes and 
DAV:quota-used-bytes?

> difficult to argue for adding this requirement.

How are they supposed to make that distinction when they currently can't?

Anyway: if you want to write down what two specific implementations do, 
then produce a non-WG track document, and try to publish through the 
IETF (or elsewhere). If this is supposed to be a WG activity, you'll 
also have to listen to those that do not currently implement it, but 
might want to do so in the future.

If there's a split between things we have consensus on and extensions, 
and the former part is useful on it's own, put *that* in the standard 
tracks document and put the rest into an extension.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Sep 2004 09:23:11 +0200

> can handle either case but not both at once.

Correct. So are you saying that

(i) a system can't have both quotas and disk limits or
(ii) that we should have two different mechanisms?

Best regards, Julian

---

From: Brian Korver <[email-masked]>
Date: Fri, 3 Sep 2004 10:07:48 -0700

> So what's the relation between DAV:quota-assigned-bytes and 

Quite possibly none.

> Anyway: if you want to write down what two specific implementations 
> do, then produce a non-WG track document, and try to publish through 
> the IETF (or elsewhere). If this is supposed to be a WG activity, 
> you'll also have to listen to those that do not currently implement 
> it, but might want to do so in the future.
>
-brian
[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Fri, 3 Sep 2004 10:08:55 -0700

> (ii) that we should have two different mechanisms?

Neither.

-brian
[email-masked]