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

RE: Bindings, was: Issue: URI_URL, proposed changes

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 2 Aug 2002 09:39:15 +0200
To: "Jason Crawford" <ccjason@us.ibm.com>, "'Webdav WG \(E-mail\)'" <w3c-dist-auth@w3c.org>
Cc: "Clemm, Geoff" <gclemm@rational.com>
Message-ID: <JIEGINCHMLABHJBIGKBCOECGFBAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Jason Crawford
> Sent: Thursday, August 01, 2002 7:02 PM
> To: Julian Reschke
> Cc: Clemm, Geoff; 'Webdav WG (E-mail)'
> Subject: Re: Bindings, was: Issue: URI_URL, proposed changes
> <<
> However, from an abstract point of view, multiple URIs can identify the
> 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.
> >>
> I believe you're talking about inter-server bindings.

See, that's the issue. Whether you consider two resources to be the "same"
depends on your POV, and the layer you're look at. Consider the URI:


I just made it up, and it identifies an abstract resource. I can claim that
the following URIs identify the same resource:


However, nobody will argue that this is the same type of "sameness" as
described in the BIND protocol. So, no, I wasn't talking about inter-server

> Because of garbage collection issues, I suspect the server that actually
> holds the resource will know about all bindings to the resource. But more
> importantly, I suspect all servers that bind to that resource will get the
> resourceid from the server that actually contains the resource just as
> they'd get other properties like the last modification date.
> Did you have something else in mind?
> I believe the resources should have a resourceid, but right now I can live
> with a proposal that lacks it.
Received on Friday, 2 August 2002 03:39:50 UTC

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