RE: I-D ACTION:draft-ietf-webdav-quota-01.txt

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver
> Sent: Saturday, March 22, 2003 2:10 AM
> To: Julian Reschke
> Cc: WebDAV
> Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt
>
> ...
>
> I'm not sure how important I think defining "quota space" is, but
> I'd I'll add it since you think it would be helpful.

I think it's useful if and only if we use it consistently to define the
quota properties (see below).

> ..
>
> > IMHO,
> >
> >          The value in bytes which represents the amount of additional
> >          disk space that can be allocated to this file or directory
> >          before the user may reasonably be warned.  It is understood
> >          that this space may be consumed by allocations to other files
> >          or directories though there is a rule as to which other files
> >          or directories.
> >
> > is very clear (we may have to map some terms though). If we stick with
this
> > language it's also much clearer why the distinction between plain
resources
> > and collections (and other types) really doesn't make sense at all --
I'd
> > prfer the spec not to say anything about that.
>
> I agree that it's clear.  The problem is that we defined things a little
> differently from NFS:  DAV:quota-limit-bytes is different from
> NFS's quota_avail_hard, in that
>
>     DAV:quota-limit-bytes - DAV:quota-used-bytes = quota_avail_hard
>
> We talked about doing this because we wanted the "amount free" that
> is displayed to the user to be what the user expects rather than
> a value computed by the client, which might not end up as a round
> number.

I think now we're confusing marshalling and implementations.

I agree that it would be confusing when the "available" value keeps changing
due to rounding issues. However, that's an effect of the underlying
implementation, not how the numbers are sent to the client. If a server
really decides to *compute* the total (I really can't imagine why it would),
changing the marshalling format will not change anything.

> ...
>
> > That didn't come through. Now it reads:
> >
> >    The value of this property will usually be protected, although a
> >    user with sufficient privileges may be permitted to change the
> >    value.  The property is useful even if it is protected.  A 403
> >    Forbidden response is RECOMMENDED for attempts to write a protected
> >    property.
> >
> > That sounds as if *usually* the property is read-only.
>
> That makes sense.  For instance, most users shouldn't be able to
> change my quota, as I shouldn't be able to change theirs.

Why would a server allow a user to change his own quota??? That really seems
to be an adminstrator-only feature.

> > BTW: why do we need an additional property for that?
>
> There are several instances where there are 2 numbers for
> quota.  For instance, the quota system given in the example.
> In the example, the assigned quota for B is 10,000,000 bytes,
> while the limit is 1,000,000.  I'll try to make that clearer
> in the example.

If this is the case, there's still a major problem with the quota system you
describe.

Before we continue this thread, let's talk about whether the spec should
actually describe server behaviour at all. As far as I remember the
discussion in January, all that client implementors want is the ability to
describe a ratio of used / available, and possibly the ability to discover
the amount of storage a single resource takes. If we only need this, the
spec can be much shorter.

On the other hand, if the spec is going to define what quotas are and how
they behave, it needs to be compatible with more than a single
implementation, and you'll have to define why and how these two different
value may vary. Right now, I  honestly don't understand it.

Julian


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

Received on Monday, 24 March 2003 08:06:26 UTC