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

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

From: Cullen Jennings <fluffy@cisco.com>
Date: Sun, 10 Jul 2005 08:05:55 -0400
To: Julian Reschke <julian.reschke@gmx.de>
CC: WebDav <w3c-dist-auth@w3.org>, Lisa Dusseault <lisa@osafoundation.org>
Message-ID: <BEF68763.4243C%fluffy@cisco.com>

On 7/3/05 7:14 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> Cullen Jennings wrote:

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

Ok, I'm sure I get it now - thanks.
>> 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).

Ok, I feel very comfortable that we have consensus on how the protocol
should work here. It sounds like the protocol has what you want in that
there are separate pre-conditions for the errors and we have not closed the
door on a future draft setting up additional properties to discover physical
media limits. 

Thanks, Cullen 
Received on Sunday, 10 July 2005 12:06:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:34 UTC