- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 5 Mar 2003 23:47:11 +0100
- To: "Brian Korver" <briank@xythos.com>, "WebDAV" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 11:25 PM > To: WebDAV > Subject: Re: Bindings and Locks (was: bind draft issues) > > > > On Wednesday, March 5, 2003, at 11:55 AM, Julian Reschke wrote: > > Again, quoting Geoff quoting RFC2616: > > > >> In case there remains any question about whether HTTP supports > >> multiple URIs being mapped to the same resource, the following quote > >> appears in section 9.6 of RFC-2616: > >> > >> "A single resource MAY be identified by many different URIs. For > >> example, an article might have a URI for identifying "the current > >> version" which is separate from the URI identifying each > >> particular version. In this case, a PUT request on a general URI > >> might result in several other URIs being defined by the origin > >> server." > > Julian, > > It doesn't follow from above that HTTP must have bindings as > they are specified in the binding document (and GULP). One can > imagine a number of scenarios where there are multiple > URIs for a resource that have quite different semantics and > behavior. > > In fact, it's easy to imagine a different binding draft > that specifies, for instance, soft links. This binding Nope. A symbolic link is a different resource than the resource it's pointing to. It can exist while it's target is removed. It can be created although it's target doesn't exist. It doesn't track it's target. Technically it does have it's own properties and ACLs. This is not what the BIND spec describes. > draft would be perfectly consistent with both HTTP and > WebDAV, but would behave very differently from the > current draft. In fact, implementations which are built > directly on top of unix file systems might prefer that > draft to the current draft. Are there good reasons to > prevent other binding models by forcing the binding > model of the current bind draft into WebDAV? Yes and no. Staying with the Unix terminology: hard (true) links and symbolic links are very different things. The BIND spec basically defines the HTTP equivalent of hard links. The (unfinished) redirect reference spec does specify the equivalent of symbolic links. If you want to base your linking implementation on symbolic links, the bind spec clearly isn't the right spec for you. > Especially given our lack of experience with deploying > bindings, I'd prefer WebDAV to be agnostic for the time > being. Let's face it, file systems find a need to > support different binding models, so it's plausible > that WebDAV might find this need as well. Nobody ever said that the binding spec can be the only protocol extension that describes links. As I said there *is* a companion spec that is closer to symbolic links which is the redirect ref spec [1]. We are discussing the BIND spec right now because - RFC3253 more or less requires it, and - somebody (Geoff) volunteered to pick up the abandoned draft and invest the time to drive it to completion. I absolutely agree that the BIND spec doesn't address all linking scenarios (just as hard links don't), and we (SAP/greenbytes) implement the (old) redirect ref spec as well. We intend to drive the redirect ref spec to completion as soon as time permits (in particular once we manage to get the other two advanced collectiom drafts -- BIND and ordering -- out of the door). Julian [1] <http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-02. html> -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 5 March 2003 17:47:25 UTC