- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 2 Aug 2002 09:52:53 +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: Friday, August 02, 2002 5:52 AM > To: 'Webdav WG (E-mail)' > Subject: RE: Bindings > > .. > > 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. (see separate answer). > Seems we need better terminology here. > > Which terms do you think need to be replaced? I think "same resource" only works when using it in a very technical sense. It won't when using it in the generic sense when identifying abstract concepts. > 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. RFC3253 counter example: DAV:version-tree report -- could have been replaced using a DAV:version-set report and the DAV:expand-property report Another one: why have the report DAV:locate-by-history if a DAV:version-controlled-resource-set property would offer the same information? I'm not convinced: the set of bindings of a resource is *not* a quality of the resource -- it's a quality of the collections that contain them. Computing all binds can be *very* expensive (for instance and AFAIK, in a plain old Unix filesystem you'll have to traverse the full namespace to find all bindings).
Received on Friday, 2 August 2002 03:52:58 UTC