W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

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

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 24 Mar 2003 22:53:42 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE2023C9B80@SUS-MA1IT01>
To: WebDAV <w3c-dist-auth@w3.org>

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

But the advantage of an aesthetic quibble is that everyone can join in
without risk of being proven wrong (:-), so my 2 cents say that 4xx is
more consistent with the currently defined 4xx and 5xx messages.  In
particular, 413 (Request Entity Too Large) seems quite close to this
condition, while there is no 5xx condition that is nearly as close.


-----Original Message-----
From: Dyer, Kevin [mailto:kevin.dyer@matrixone.com]

I agree with 1) on 2) are you talking about quotas? If so you are correct
but disk space is still 507, IMHO. 

  >-----Original Message----- 
  >From: Julian Reschke [mailto:julian.reschke@gmx.de] 
  >Sent: Monday, March 24, 2003 8:15 AM 
  >To: WebDAV 
  >Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt 
  >here are two more issues I have: 
  >1) During the discussion, I've seen soft limits (quotas) and 
  >hard limits 
  >(disk space) used in the same context. I'm really not sure 
  >that it is a good 
  >idea to use the same mechanism for both. 
  >2) Related to that: I'm not sure that using 507 for failures 
  >due to quota 
  >restrictions is a good idea. 5xx indicates a server error. 
  >In this case, the 
  >problem is not causes by the server, but by the client 
  >(trying to take up 
  >more space than allowed), so a 4xx with a new precondition 
  >code seems to be 
  >more appropriate. 
  ><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
Received on Monday, 24 March 2003 22:53:56 UTC

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