RE: Bindings and Locks (was: bind draft issues)

> 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