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

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 4 Mar 2003 21:24:47 -0500

GULP is actually pretty short, so I probably wouldn't mind
adding a copy to the binding protocol *if* we get consensus
that GULP correctly defines the WebDAV locking semantics.
What I don't want to have happen is for the binding protocol
to become a draft standard and then have RFC-2518bis decide
that some GULP variant is needed, and have the binding RFC
conflict with 2518bis RFC (with the resulting interoperability
problems inevitably appearing).

So I'll take this opportunity to again ask everyone to either
explicitly support the current GULP proposal, or identify any
problems in semantics or terminology, so we can get this 
language committed to 2518bis ASAP.

Cheers,
Geoff

-----Original Message-----
From: Brian Korver [mailto:[email-masked]]
Sent: Tuesday, March 04, 2003 8:31 PM
To: WebDAV
Subject: Re: Bindings and Locks (was: bind draft issues)

On Monday, March 3, 2003, at 01:50  PM, Clemm, Geoff wrote:
>
> I wouldn't want to tug any harder on that particular string (i.e.
> defining precisely what "protect" means), or else we'd end up needing
> to include most of the GULP (Grand Unified Locking Proposal) in the
> binding draft.

Given that I think that the binding draft needs to be more
explicit about the behavior of locks, what would be so awful
about including some of GULP?

> Since we currently only have definitions of the semantics of write
> locks, I try to avoid speculating on what semantics non-write locks
> may have some day.
>
> Cheers,
> Geoff

-brian
[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Tue, 4 Mar 2003 18:34:45 -0800

> language committed to 2518bis ASAP.

Geoff,

I'll get you comments RSN.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 5 Mar 2003 09:32:27 +0100

I explicitly support GULP being added RFC2518.

In particular, I ask everybody to either state

- if  they find GULP technically incorrect (so that we can fix it) or

- otherwise explain why it can't be added to RFC2518bis as is.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Wednesday, March 05, 2003 3:25 AM
> To: WebDAV
> Subject: RE: Bindings and Locks (was: bind draft issues)
> 
> 
>

---

From: Brian Korver <[email-masked]>
Date: Wed, 5 Mar 2003 11:45:26 -0800

> - otherwise explain why it can't be added to RFC2518bis as is.

Julian,

I'm not convinced that the bindings that you see in 2518
are really there.  In fact, I'm worried that inserting the
semantics of bindings into 2518bis will prohibit the use
of WebDAV in contexts where these bindings cannot be
supported.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 5 Mar 2003 20:55:35 +0100

> [mailto:[email-masked]]On Behalf Of Brian Korver
> Sent: Wednesday, March 05, 2003 8:45 PM
> To: WebDAV

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."

So, please be more specific about where you see that problem.

> of WebDAV in contexts where these bindings cannot be

How?

Julian

---

From: Brian Korver <[email-masked]>
Date: Wed, 5 Mar 2003 14:24:59 -0800

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
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?

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.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 5 Mar 2003 23:47:11 +0100

> Sent: Wednesday, March 05, 2003 11:25 PM
> To: WebDAV

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.

> 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.

> 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>