RE: Bindings

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   There was a disagreement about whether BIND should be applied
   (a) to the collection in which the mapping is to be created or (b)
   to a URI of the resource that should get the additional
   binding. Roy prefers (preferred) (a), and I think technically he's
   right. The WG prefers (preferred) (b), because that's consistent
   with COPY/MOVE. As a server implementor, I'd prefer (a) because it
   seems cleaner.

Either way is fine with me.

   There was a violent disagreement whether there needs to be a
   mechanism to retrieve a globally unique identifier for the resource
   (which is not supposed to change once the resource is created). The
   current spec calls this DAV:resourceid, Geoff mentioned DAV:urn
   (drafts and memory out of sync?).

It will be interesting to see whether that violent disagreement still
exists.  In particular, I'd be interested in seeing an implementation
that supports multiple bindings to a single resource, and doesn't
support something like a DAV:resourceid property.

   The issue here seems to be that "identity" of a resource is hard to
   define.

In general, yes, but multiple bindings to a given resource give you
a way of defining identity in a protocol visible way.

   Looking from an implementators POV, a resource in a document
   repository certainly has identity defined by a row number in a
   database or an inode number in the file system (for instance). With
   this piece of information, a server can easily assign persistent
   URIs to these objects that survive renaming. Having this
   information available can help a client keeping it's caches
   consistent (it would know that an operation that affects one
   resource will affect all resources with the same DAV:resourceid as
   well). I'd like to understand whether somebody thinks that this is
   a problem (would that make that an optional feature, or would it
   have to be removed?)?

I do not think it is a problem, and I believe it should be a required
feature.

   However, from an abstract point of view, multiple URIs can identify
   the same resource even if they live on separate HTTP servers.
   In particular, the implementations wouldn't even know about the
   "other" URI, and it would be impossible require both servers to
   return the same DAV:resourceid.

The only way the same resource could live on separate HTTP servers
would be if the resource is immutable, or unless one server is
intimately linked to the other (so that all changes made through one
server to that resource are automatically available when accessing
the resource from the other server).  In either case, the server
would be able to return the same DAV:resourceid.

   Seems we need better terminology here.

Which terms do you think need to be replaced?

   5) The spec defines a live property (DAV:bindings) that contains a
   list of a URI mappings to a resource. From a marshalling
   perspective, that's a bad thing. It can be expensive to compute (so
   we would have to enforce RFC3253 propfind/allprop behaviour).

Which is what we should do.

   Furthermore, a particular user may not have the right to see all
   URI mappings, and that kind of information is hard to marshall
   inside a live property. I think this should be modernized to use an
   explicit REPORT instead.

If a client wants to retrieve this information, they should be able to
batch up that request with other live property information, and should
be able to use functionality like the DAV:expand-property report to
thread through it.  Like other live properties with sensitive
information (such as DAV:acl or DAV:version-history), the server will
omit DAV:binding information for clients that are not permitted to see
it.  Reports should be only used when parameters are required for the
request, and DAV:binding is not a parameterized request.

Cheers,
Geoff

Received on Thursday, 1 August 2002 23:52:20 UTC