- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 1 Aug 2002 23:51:48 -0400
- To: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
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