W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

Re: Comments on bind-08

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 01 Dec 2004 21:11:40 +0100
Message-ID: <41AE257C.20208@gmx.de>
To: ejw@cs.ucsc.edu
CC: "'WebDAV (WebDAV WG)'" <w3c-dist-auth@w3.org>

Jim Whitehead wrote:
>>That depends on why the new binding couldn't be created....?
> Say, for the sake of argument, that there is a disk full condition, such
> that the database holding bindings could delete a binding, but couldn't
> create the new binding. In this internal server error condition, what status
> code/element would be returned?


I think the answer would be: none specific. The status would be just 
506. There are many potential error conditions for which BIND doesn't 
define specific names. As a matter of fact, I'd say it's not possible to 
enumerate them all.

>>Could you be more specific about which case you think would 
>>need to be clarified? Is this about the specific marshalling 
>>of REBIND, or about locking semantics in face of multiple bindings?
> It's about the problems clients have with correctly marshalling needed
> information into the If header.

OK, just to clarify: you'd like to see an example for lock tokens being 
submitted in a non-trivial namespace operation such as MOVE/REBIND 
between locked collections? I'm not strongly opposed to that; I just 
like to understand the motivation (which in this case would be: we don't 
have an example like that in RFC2518, so this may be an action item for 
RFC2518bis as well).

>>It's way "everybody" does it (WebDAV lock tokens, WebDAV 
>>ordering, Atom IDs, XML namespaces). Also, UUIDs may not 
>>always be the best identifier available. For instance, for 
>>lock tokens a server may be using a single UUID + a counter 
>>(as allowed in the opaquelockoken syntax) -- why shouldn't it 
>>do the same for resource IDs?
> OK, I'll let this one go.

Thanks :-)


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 1 December 2004 20:12:20 UTC

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