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

Re: WGLC draft-ietf-webdav-quota-07

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 03 Jul 2005 13:14:13 +0200
Message-ID: <42C7C885.40908@gmx.de>
To: Cullen Jennings <fluffy@cisco.com>
CC: WebDav <w3c-dist-auth@w3.org>, Lisa Dusseault <lisa@osafoundation.org>

Cullen Jennings wrote:
> I'm trying to summarize the two things you would prefer to see changed. Tell
> me am I getting this right?
> 
> 1) The document REQUIRES the attributes that report the used and remaining
> bytes of quota space to exist on collections but makes them optional on
> other resources. Some WG members feel it would be better to required on all
> resources but are OK with how it is written now.

Correct (it's simply a matter of having the spec as simple as possible, 
and not to optimize marshalling for one specific implementation).

> 2) In 2518, if a Dav server that had a disk full situations, the server
> would return a 507. Now with quota there are two reasons a 507 could happen,
> a disk full (as before) or a quota exceeded. The quota exceeded is a very

RFC2518 (<http://greenbytes.de/tech/webdav/rfc2518.html#STATUS_507>) says:

"The 507 (Insufficient Storage) status code means the method could not 
be performed on the resource because the server is unable to store the 
representation needed to successfully complete the request. This 
condition is considered to be temporary. If the request which received 
this status code was the result of a user action, the request MUST NOT 
be repeated until it is requested by a separate user action."

which I think can be understood to include storage limits not imposed by 
the hardware. So I'd call that a clarification, not extension.

> similar but slightly different error. To enable a client to display an error

Yes.

> message to a human user to differentiate these two things, a server that had
> a disk full error would return a 507 with a DeltaV style error body that
> indicated the disk was full. Is your issue that a) this should not be

The two precondition names allow a client to distinguish between both. 
For instance, a *nix file system driver could use that information to 
generate the proper *nix error (which is different for disk size limits 
and quota limits).

> defined in the quota document b) you don't think we should do this at all
> and the DeltaV error for a disk full should be the same as the response for
> quota exceeded? In trying to summarize the issues I realized I did not
> understand what you were concerned with and more specifically exactly what
> you would propose we change to fix the concern.

No, my concern is indeed a different one.

In general, systems consider disk limits and quota different things, and 
there are different APIs to discover/manipulate them, and different 
status codes to distinguish between both ("in general", i.e. I am aware 
that there are systems that treat both the same way).

My preference would have been that the quota properties are indeed only 
used for quotas; and that if people need to get information about disk 
limits as well, we handle them as separate properties.

The quota spec currently doesn't precisely define what it understands as 
"quota". It introduces some requirements in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota-07.html#rfc.section.1.2> 
without ever mentioning disk limits, but then goes on to say 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota-07.html#rfc.section.3.p.5>:

"Note that there may be a number of distinct but overlapping limits, 
which may even include physical media limits."

So if it defines physical disk limits to be a kind of quota, it would be 
better to express that in a proper definition of the term "quota", 
instead of just hinting at it later in the spec. Again, my preference 
would have been to treat them as separate things, with different live 
properties and different precondition names (fortunately, the latter 
we're added).

> Thanks, Cullen

Hope this helps,

Julian
Received on Sunday, 3 July 2005 11:14:31 GMT

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