- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 1 Aug 2002 09:42:58 +0200
- To: "Clemm, Geoff" <gclemm@rational.com>, "'Webdav WG \(E-mail\)'" <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, July 31, 2002 2:02 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Issue: URI_URL, proposed changes > > ... > > I also believe that it would be valuable to have a standard > property that identifies a URN for a resource, and that is > one goal of the binding spec (which we should be able to finish > up as soon as we have the ACL spec wrapped up). In particular, > the binding spec introduces the DAV:urn property for this purpose. > > I wouldn't want the DAV:source property confused with the DAV:urn > property. I'm not sure how the DAV:source property relates to bindings, but this is certainly a good opportunity to discuss some open issues with the BIND spec. I read some of the discussion from winter 2000 on the mailing list (just after submission of the 02 draft... [1]), and I'll try to summarize the main open points... 1) It seems to me that there is agreement on what a BIND is, and how the presence of multiple bindings to the same resource affects DELETE. 2) As some recent discussion in the deltav mailing list showed, we already have situations where additional bindings are created as side effects of versioning operations. As a matter of fact, just because the BIND spec wasn't finished doesn't mean that there aren't already shipping WebDAV implementations that have to deal with bindings -- we're just lacking standardized methods to explicitly create them / to get additional information about them. 3) 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. 4) 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?). The issue here seems to be that "identity" of a resource is hard to define. 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?)? 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. Seems we need better terminology here. 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). 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. Julian [1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/thread.html#12 5>
Received on Thursday, 1 August 2002 03:43:34 UTC