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

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 25 Mar 2003 15:50:55 -0500

Any error can be "resolved" by changing the request to something
else that doesn't fail, so that can't be the criterion used to
distinguish a 4xx from a 5xx.  All that sections 10.4 and 10.5 say
are: 

"The 4xx class of status code is intended for cases in which the
 client seems to have erred."

"Response status codes beginning with the digit "5" indicate cases in
 which the server is aware that it has erred or is incapable of
 performing the request."

So requests that are malformed are clearly 4xx errors, but
most other error cases are ambiguous, because looking at the
error one way, the client erred in asking the server to do something
it couldn't do (e.g. create a larger file than is permitted), but
looking at them another way, the server erred by not (or by being
incapable of) performing the specified request (e.g. create the large
file).

Cheers,
Geoff

-----Original Message-----
From: Jim Luther [mailto:[email-masked]]
Sent: Tuesday, March 25, 2003 12:20 PM
To: WebDAV
Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt

I'd refer back to rfc2616's language in sections 10.4 "Client Error 
4xx" and 10.5 "Server Error 5xx". 4xx is for errors the server thinks 
can be resolved by changes in the client's request, and 5xx is for 
errors the server thinks are caused by something server-side.

- Jim

On Tuesday, March 25, 2003, at 08:35  AM, Clemm, Geoff wrote:

>
> That wasn't the question I meant to ask.
>
> Clearly there are clients that handle a specific code
> (such as 507) differently from another specific code (such as 413).
> But in those cases it doesn't matter whether the standard
> defined that specific code to be in the 4xx or 5xx range.
>
> What I was asking was whether there was a client that
> generically handled 4xx codes (i.e. a 4xx code that it had no
> special handling for) in a significantly different way than
> it handles a 5xx code (i.e. a 5xx code that it had no special
> handling for).  I.e., when we are deciding whether to put a
> specific code in the 4xx or 5xx range, does it matter which
> one we pick?
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Jim Luther [mailto:[email-masked]]
> Sent: Tuesday, March 25, 2003 10:46 AM
> To: WebDAV
> Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt
>
>
>
> On Monday, March 24, 2003, at 07:53  PM, Clemm, Geoff wrote:
>
>> Just for interests sake, is there any client that acts significantly
>> differently if it were to receive a 4xx response instead of a 5xx
>> response?  If not, this question is merely an aesthetic quibble (:-).
>
> Yes there is a client that handles those responses quite differently.
>
> The Mac OS X WebDAV file system client translates 507 to ENOSPC (No
> space left on device) which is interpreted by most Macintosh
> applications to mean the device is full; the WebDAV file system
> translates 413 as a generic 4xx response to EINVAL (Invalid argument)
> which is interpreted by most Macintosh applications to mean "something
> wasn't right - who knows what?"
>
> The Mac OS X WebDAV file system client is one of the few clients
> actually using quotas today and has been for over 1-1/2 years now.
>
> Jim Luther
> Apple Computer, Inc.
>

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 25 Mar 2003 22:00:31 +0100

The reason I raised this is because I feel that a "disk full" indeed is an
error condition on the server (thus 5xx), but a failed request due to
exceeded quota limits happens *on purpose* -- the server theoretically
*could* perform the request, but it doesn't want to.

But as Geoff already stated, this is really not an important issue -- even
more so if we have well-defined condition names that we can send in error
response bodies.

I'd prefer to focus the discussion on the other issues I mentioned (such as
what is the quota model the spec describes, and do we really need to
describe a specific model at all; or: are physical disk limits a special
case of quotas? -- RFC3010 distinguishes both).

Julian

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Tuesday, March 25, 2003 9:51 PM
> To: WebDAV
> Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt
>
>
>

---

From: Brian Korver <[email-masked]>
Date: Wed, 26 Mar 2003 16:05:17 -0800

> case of quotas? -- RFC3010 distinguishes both).

Julian,

I was thinking that physical disk limits are just another class of 
"quotas".
That probably isn't clear enough from the spec, and should probably be
stated.

The alternative is to report two numbers, quota-limit and something like
"space-limit", but I think we basically agreed that reporting back one 
number
would be better than multiple numbers (given that the server should know
which of the numbers is the "best" one to represent the space 
constraints
on that server).

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 27 Mar 2003 20:49:22 +0100

> [mailto:[email-masked]]On Behalf Of Brian Korver
> Sent: Thursday, March 27, 2003 1:05 AM
> To: Julian Reschke
> Cc: WebDAV
"quotas".
> That probably isn't clear enough from the spec, and should probably be

Yes and no. It depends on who is asking. Note that RFC3010 (which I think we
all like :-) distinguishes between both.

Earlier today, Stefan E. showed that lumping disk limits and quota into the
same property can lead to very surprising effects. Do we really want that?

number
> which of the numbers is the "best" one to represent the space  constraints
> on that server).

The issue here is that disk limits *behave* differently than quotas. For
instance, a "quota error" usually can be resolved by the user, by deleting
some of his own files, while a "disk full" condition may possibly not (other
user may take up the disk space, so there's no way for the affected user to
recover/continue). Also, recovery from both conditions may be different --
the person you need to contact to get a higher quota might be somebody else
than the person that's able to free up physical disk space (or add new
disks).

Here's another proposal how we *could* inherit RFC3010 properties without
much effort in WebDAV -- just use their welldefined names from RFC3010, and
put them into the IETF namespace reserved for individual RFCs, for instance:

<D:prop xmlns:D="DAV:" xmlns:NFS="urn:ietf:rfc:3010">
  <NFS:space_freel>12345678</NFS:space_free>
  <NFS:space_total>1234567890</NFS:space_total>
  <NFS:quota_used>123456</NFS:quota_used>
  <NFS:quota_avail_hard>1234567</NFS:quota_avail_hard>
</D:prop>

(we'd just have to state how RFC3010 terminology maps to WebDAV resources)

Julian