W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

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

From: Brian Korver <briank@xythos.com>
Date: Thu, 2 Sep 2004 14:38:11 -0700
Message-Id: <637984DA-FD28-11D8-A93D-000A95AACED2@xythos.com>
Cc: w3c-dist-auth@w3.org
To: Julian Reschke <julian.reschke@gmx.de>

On Sep 2, 2004, at 1:21 PM, Julian Reschke wrote:
> Brian Korver wrote:
>
>>> 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.
>> It's a single value.
>
> 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).
>> 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.

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.


>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
-brian
briank@xythos.com
Received on Thursday, 2 September 2004 21:38:45 GMT

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