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

From: Cullen Jennings <[email-masked]>
Date: Sat, 02 Jul 2005 21:31:12 -0700

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.
 
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
similar but slightly different error. To enable a client to display an error
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
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.

Thanks, Cullen

On 6/16/05 11:24 AM, "Julian Reschke" <[email-masked]> wrote:

> Cullen Jennings wrote:
>> 
>> I would like to start working group last call
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-07.txt
>> 
>> This WGCL will end on June 27th so please have your comments emailed to this
>> list before then.
>> 
>> Thank you, Cullen
> 
> Hi,
> 
> we (greenbytes, currently contracting for SAP), do not intend to
> implement the QUOTA spec any time soon, but we do feel that the spec is
> stable and mature, and it is suited as an interoperable base for a set
> of differing quota implementations.
> 
> Some more thoughts:
> 
> - The spec started as a description of a very specific quota
> implementation, which wasn't directly implementable for other quota
> systems such as the Unix one; as far as I can tell, this problem has
> been resolved.
> 
> - The spec still contains a somewehat arbitrary optimization for a
> specific type of implementation (requiring live properties on
> collections but not on it's members). I'd prefer that one to be removed,
> simplifying the spec a bit more, but unless others feel the same way, we
> should probably leave things as they are (WG dicussion back in
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0322.html>)
> 
> - The spec currently suggests that disk limits to be marshalled as
> quotas. I'm not sure this is a good idea (for instance, Unix handles
> those very differently), but again I'm not planning to lie down in the
> road because of it.
> 
> Best regards,
> 
> Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Jul 2005 13:14:13 +0200

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

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

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

> 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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 10 Jul 2005 08:05:55 -0400

> generate the proper *nix error (which is different for disk size limits

Ok, I'm sure I get it now - thanks.
> properties and different precondition names (fortunately, the latter

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