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

RE: BIND method response codes

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 11 Oct 2002 16:18:59 -0400
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED49F@SUS-MA1IT01>
To: w3c-dist-auth@w3.org
   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff
   > A problem with 200/201, is that 201 means "a new resource
   > was created", but a BIND never creates a new resource, but
   > just creates a new binding to an existing resource.

   That's correct with the WebDAV/BIND definition of a resource, but
   not with the generic (RFC2396) one -- the binding itself has a
   unique identifier (and thus has identity), therefore *can* be
   considered a resource.

The binding does not have a unique identifier and does not have
identity.  In particular, if you delete a binding from a collection,
and then create a new binding in that collection with the same segment
and same bound resource, the new binding is indistinguishable from the
old binding.  Theoretically of course, a binding is a resource because
you can imagine having a URL that identifies it.  But we have not
defined any such URL mapping (the mappings that a binding introduces
are to the bound resources, not to the bindings themselves).

   > You could of course still use 200/201, but I'd be concerned that
   > it would be misleading.  If a client has asked that BIND
   > overwrite any existing binding for that segment, why would it
   > care whether or not there was already a binding there?

   Well, why would it care in the case of PUT or MOVE? I'm just
   looking for consistency with other methods.

Since BIND has different semantics from PUT or MOVE, I don't
find a consistency argument sufficient reason to make this
distinction.  As for why it would care in the case of PUT or
MOVE, I'd be interested in hearing an answer to that as well. 

Received on Friday, 11 October 2002 16:19:35 UTC

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