Subject: RE: Review of quota-06

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 17 Mar 2005 16:28:15 -0800

Julian,

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

In my reading of the -06 specification, I'm not able to see any mention of
this.

The only concern I see is that the definition of quota-available-bytes is
defined in terms of "disk space" available and not "storage space"
available. Then again, even storage media that aren't disks are typically
referred to as drives these days (e.g., "thumb drive" for RAM-based storage
sticks), so maybe it's not an issue.

> 04-C07, section 3, DAV:quota-available-bytes
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota-05.h
> tml#rfc.section.3>
> 
>    "Support for this property is REQUIRED on collections, and 
> OPTIONAL on
>     other resources.  A server SHOULD implement this property for each
>     resource that has the DAV:quota-used-bytes property."
> 
> What's the motivation for the distinction? (same in section 4)

Seems to me the motivation is to ensure that collections know how much space
is available in their namspace, thereby providing clients an aggregated
understanding of available storage space associated with a particular
namespace.

It's not clear to me whether you object to this, or are seeking additional
clarification text.

> 
> 
> 04-C11, section 7
> 
>       "The total size of a collection, DAV:quota-used-bytes, is not
>        necessarily a sum of the DAV:getcontentlength properties for
>        resources stored in the collection."
> 
> Actually, it won't be in most cases I'm aware of. Please 
> either rephrase it (so this doesn't sound like an edge case) 
> or drop the point.
> 
> Update -06: It's now saying
> 
> "The total size of a collection, DAV:quota-used-bytes, may 
> not be a sum of the DAV:getcontentlength properties for 
> resources stored in the collection."
> 
> ...which isn't that different...

Let me suggest:

"Since there are many factors that affect the storage used by a set of
resources, including automatic compression, the size of associated metadata,
and server-inserted content (such as that created by PHP code) in the
on-the-wire representation of resources, clients are advised to not depend
on the value of DAV:quota-used-bytes being the sum of the
DAV:getcontentlength properties for resources contained by a collection."

> 05-C02, Section 4
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota-05.h
> tml#rfc.section.4>
> 
> I think this property is "computed" (as defined in RFC3253), 
> and the spec should say so.

I agree. The DAV:quota-used-bytes is a "computed" property according to
RFC3253, and I agree it would be useful to explicitly state this.

I recommend adding the following sentence to the end of section 4, as a new
paragraph:

"This value of this property is computed (see Section 1.4.3 of [RFC3253] for
the definition of computed property). A 403 Forbidden response is
RECOMMENDED for attempts to write a protected property, and the server
SHOULD include an XML error body as defined by DeltaV [RFC3253] with the
<DAV:cannot-modify-protected-property/> precondition tag."

> 05-E01, section 1.2
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota-05.h
> tml#rfc.section.1.2>
> 
> I'd move those parts that "import" terminology from 
> RFC2518/3253 into a 
> separate subsection ("Terminology"), and also refer to the def of 
> "computed" property (I think we need that later).

I mostly agree. I think the reference to RFC3253 for computed and protected
properties should go in Section 1.1, not in the "requirements" section.

So, I recommend deleting the following sentence from Section 1.2:

"This specification requires WebDAV because it requires PROPFIND support and
relies on the WebDAV definition of collections and properties, including the
definitions for live and protected properties (see section 1.4.2 of
[RFC3253] for the definition of protected properties)."

I recommend adding the following sentence to Section 1.1, as a new
paragraph.

"The definition of live property is provided in [RFC2518]. The definition of
protected and computed properties is provided in [RFC3253], Section 1.4."

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Mar 2005 07:12:09 +0100

> In my reading of the -06 specification, I'm not able to see any mention of

I just checked, and the last mention of it seems to be in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota-06.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. When reporting 
DAV:quota-available-bytes, the server is at liberty to choose any of 
those limits but SHOULD do so in a repeatable way. The rule may be 
configured per repository, or may be "choose the smallest number".

If a resource has no quota enforced or unlimited storage ("infinite 
limits"), the server MAY choose not to return this property (404 Not 
Found response in Multi-Status), although this specification RECOMMENDS 
that servers return some appropriate value (e.g. the amount of free disc 
space). A client cannot entirely assume that there is no quota enforced 
on a resource that does not have this property, but might as well act as 
if there is no quota.''

> sticks), so maybe it's not an issue.

I think it would be a useful feature if a client could detect whether a 
write failed because of disk full rather than quota exceeded (Unix and 
NFS4 status codes allow the same distinction, see RFC3530, 
"NFS4ERR_DQUOT" and "NFS4ERR_NOSPC").

> It's not clear to me whether you object to this, or are seeking additional

I'd like to understand why it's only optional on non-collections.

> DAV:getcontentlength properties for resources contained by a collection."

:-) That's only *one* issue. The main problem here is that in many qutoa 
systems (such as the Unix one), the DAV:quota-used-bytes property on a 
collection will work completely differently and will have nothing to do 
whatsoever with the *members* of that collection. Check for instance:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-quota-06.html#rfc.section.4.p.3>:

``Note that there may be a number of distinct but overlapping sets of 
resources for which a DAV:quota-used-bytes is maintained (e.g. "all 
files with a given owner", "all files with a given group owner", etc.). 
The server is at liberty to choose any of those sets but SHOULD do so in 
a repeatable way. The rule may be configured per repository.''

So for a server that implements user-based quota (which IMHO is the most 
common way to implement it), DAV:quota-used-bytes usually will be the 
*same* for a collection and it's members.

 > ...

Best regards and thank for the review,

Julian

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

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 18 Mar 2005 17:13:59 -0800

Julian Reschke writes:
> I think it would be a useful feature if a client could detect 
> whether a write failed because of disk full rather than quota 
> exceeded (Unix and

So, if I understand you correctly, you're advocating the addition of a
single additional error code to cover the storage media full case?

> I'd like to understand why it's only optional on non-collections.

Seems to me this is obvious. There are four cases:

1) No support collections, no support others: You don't implement the
specification

2) Support collections, no support others: Frequent case, collections have
quota information

3) Support collections, support others: Possibly frequent case, all
resources give quota and used

4) No support collections, support others: This case isn't allowed in the
specification, but seems unlikely to me, since collection support is so
useful

So, is it that you think case #4 is useful, and want it to be allowed? Or
are you seeking clarification text to be added to the draft?

> So for a server that implements user-based quota (which IMHO 
> is the most common way to implement it), DAV:quota-used-bytes 
> usually will be the

Ah, good point.

Let me try again with some suggested text (the second paragraph is new, and
based on your previous text):

DAV:getcontentlength properties for resources contained by a collection. 

Additionally, because there may be a number of distinct but overlapping sets
of resources for which a DAV:quota-used-bytes is maintained (see Section 4),
there may be no correlation between the size of the resources in a
collection and DAV:quota-used-bytes. For example a server that implements
user-based quotas, DAV:quota-used-bytes usually will be the same for a
collection and it's members."

If you have quibbles with this text, please suggest modifications to it in
spec. language (it's easier than reading your mind :-)

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Sat, 19 Mar 2005 10:41:15 +0100

> single additional error code to cover the storage media full case?

My personal preference was to leave disk limits out of quota, and to 
define separate properties and precondition codes for them. However, if 
people feel this is overkill spec-wise, the ability to distinguish both 
cases when an operation fails would be welcome (and a cheap addition).

> 1) No support collections, no support others: You don't implement the

Yes.

> 2) Support collections, no support others: Frequent case, collections have

Why wouldn't the non-collection resources have quota information?

> resources give quota and used

Yes.

> specification, but seems unlikely to me, since collection support is so

Yes.
> are you seeking clarification text to be added to the draft?

I'd simply like the spec to be as simple as possible. Adding a special 
distinction for case 2 doesn't seem to be that useful.

> spec. language (it's easier than reading your mind :-)

No, the text is just fine. An alternative is not to say anything at all, 
but if we do say something, it at least needs to be correct :-)

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 19 Mar 2005 08:34:27 -0800

On Mar 19, 2005, at 1:41 AM, Julian Reschke wrote:
> define separate properties and precondition codes for them. However, 
> if people feel this is overkill spec-wise, the ability to distinguish 
> both cases when an operation fails would be welcome (and a cheap 
> addition).

Is there anybody who would implement a separate property for disk limit 
(in addition to, or instead of a property for quota)?  I haven't seen a 
direct request for this, it's only been brought up in the context of 
whether or not the quota property should exclude this concept.

I'd be happy with a separate error for the separate case.  That doesn't 
seem like overkill.

Lisa