Subject: RE: Bind issues

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 1 Dec 2003 10:21:19 -0800

> Lisa,
> 
> you haven't replied to my mail dated Nov 18
> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec
> /0207.html>).

Hi Julian,  many of us just got back from a 4-day weekend due
to American Thanksgiving.  I haven't had time to reread the bind
draft yet as you suggested.

> As far as I can tell among the three questions you raised,
> 
> - one is closed (by the introduction of REBIND in addition to MOVE),
> 
> - one is still open (bind loop error marshalling), proposal 
> for resolution
> is at
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0200.html>

> - one will be closed by updating GULP
> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0367.html>)
> to clarify when a lock token counts as "submitted".

I don't think that adding any text to RFC2518bis will fix the problem in the

bind draft.  It's not clear RFC2518bis will finish soon, or if it does, 
what status it will have, or how bindings will depend on it.  Unless the
bindings draft waits on RFC2518bis to finish, it needs to stand on its
own in this respect.

(As I've already said, I think all the language from GULP *is* in 
RFC2518bis.  I may have missed something and I'm happy to have it pointed
out, but due to the dependency issue, whether or not that's complete or
agreed upon may not be relevant to bindings status)

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Dec 2003 21:31:06 +0100

> draft yet as you suggested.

Ok.

> bindings draft waits on RFC2518bis to finish, it needs to stand on its

Well, I think I can agree with this. However we need to ensure that BIND 
and RFC2518bis actually say the same thing. So I'm in favor of adding 
GULP to the BIND spec *if and only if* there's a clearly expressed 
working group consensus on that this indeed is what RFC2518bis should 
say as well. Ideally, in identical words.

> agreed upon may not be relevant to bindings status)

Well, GULP is the result of many mailing list members trying to come up 
with the best possible explanation of how locks work in WebDAV 
(completely independantly of the BIND spec, by the way). It's not only 
about what is says, but also how it does that. Therefore, I think this 
should be *the* normative statement, and that it belongs into the base 
spec. Let's just vote on it, I don't think that any further discussion 
about this will reveal any new arguments.

Julian

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 1 Dec 2003 13:30:18 -0800

> about this will reveal any new arguments.

I don't have a problem with GULP.  What I'm trying to do is make sure it
fits into the WebDAV specification.  Sure, we could bung it in randomly,
any section remotely related to locking.  Instead, however, I tried to

 - keep to the structure of the spec 
 - have the spec be linguistically consistent with GULP
 - have the spec be logically consistent with GULP

I'd still like to hear how this could be better, for example whether any
subtlety was lost in the way GULP was incorporated.

But if you think this is irrelevant and you want to call a vote, Jim can 
determine consensus.  Please indicate where you would like me to put GULP
into RFC2518bis.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Dec 2003 20:15:57 +0100

> any section remotely related to locking.  Instead, however, I tried to

OTOH, we could put it into section 6, and then try to remove any 
language that's not needed anymore. Note that I'm not against keeping 
examples and extended usage discussions, it should be just clear that 
the few paragraphs of GULP are actually all that's required to fully 
specify the locking semantics. Having that in one single place instead 
of spreading it over different sections (Locking intro, LOCK method, If 
header) IMHO makes things a lot easier to understand.

> subtlety was lost in the way GULP was incorporated.

Well, it seems. We have this discussion because you pointed out that 
BIND spec neglects to specify locking behaviour. If RFC2518bis indeed 
already says the same thing as GULP, there shouldn't be an issue 
(because it's supposed to fully explain how locking works when there are 
multiple URIs for the same resource).

> determine consensus.  Please indicate where you would like me to put GULP

I'm happy to make a more detailed proposal, but I'd prefer to make a 
base decision first. Jim?

Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Dec 2003 20:21:14 +0100

> bindings draft waits on RFC2518bis to finish, it needs to stand on its

Well, we've talked about that many times before, but anyway...

BIND does *not* introduce the concept on bindings (multiple URIs mapped 
to the same resource). This concept already exists implicitly in 
RFC2616, RFC2518 and RFC3253. In RFC3253, some operations even 
implicitly create possibly multiple bindings.

So if RFC2518bis doesn't already fully explain how locking and multiple 
URI mappings interact, it's RFC2518bis that is incomplete.

All the BIND spec adds is

- a method to explicitly create new bindings
- new methods in addition to MOVE/DELETE which are more clearly defined 
in how they interact with multiple bindings (so avoiding changing the 
semantics of MOVE/DELETE if a server implementer doesn't want to do that)
- error marshalling extensions
- discovery of the "other" bindings to a resource, detecting whether to 
URIs identify the same resource.

But again, the BIND draft does *not* introduce the concept itself. It's 
been here all the time,

> agreed upon may not be relevant to bindings status)

Regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 2 Dec 2003 11:57:42 -0800

> implicitly create possibly multiple bindings.

How so?

> URI mappings interact, it's RFC2518bis that is incomplete.

RFC2518bis implicitly included the concept that files had previous
versions (that you just couldn't happen to know about or view).
Still, when DeltaV added versions, it was reasonable and right
to add requirements on how servers supporting DeltaV had to MOVE
and COPY resources with versions.

The difference is that before the bindings work, bindings could
exist but weren't standardized.  One major goal of standardizing
a feature ought to be to ensure that it works the same in different
implementations.

So, if the bindings draft leaves it optional to servers how to 
apply LOCK to multiple bindings, then it's my opinion that the 
bindings draft needs to be fixed.  Even if we believe that the
required behavior is implicit in GULP, I'd like to see it spelled
out in the bindings proposal to minimize confusion and implementation
differences.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Dec 2003 21:31:43 +0100

>>implicitly create possibly multiple bindings.

RFC2518: section 5.1:

"Although implicit in [RFC2068] and [RFC2396], any resource, including 
collection resources, MAY be identified by more than one URI. For 
example, a resource could be identified by multiple HTTP URLs."

RFC3253: section 14:

"Unlike a version-controlled collection, which contains bindings to 
version-controlled resources and non-version-controlled resources, a 
working collection contains bindings to version history resources and 
non-version-controlled resources."

> and COPY resources with versions.

I agree, but I don't understand how that compares to the issue we're 
discussing....

> a feature ought to be to ensure that it works the same in different

Agreed. I think we're just discussing the best way to ensure this. As 
multiple bindings (multiple internal member URIs...) to the same 
resource already appear in RFC2518 and RFC3253, I don't see why it must 
be the BIND spec that clarifies their locking semantics. *If* it's going 
to do that, we *must* ensure that it's consistent with what RFC2518bis 
says. In which case, using the identical description is the easiest way 
to achieve this.

> apply LOCK to multiple bindings, then it's my opinion that the

No, it doesn't leave it optional. It just (currently) doesn't say 
something that really should be said somewhere else.

> out in the bindings proposal to minimize confusion and implementation

If there is anything that actually needs to be clarified, I think it's 
up to you to point to it. Geoff and others have tried to make GULP as 
precise as possible. If you think that it doesn't do that well enough 
yet, please tell us where you think it needs to be improved.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 2 Dec 2003 15:55:18 -0500

I agree with all of Julian's points.  Another example of where
multiple bindings are explicitly created by RFC3253 operations are
when a version-controlled collection is updated to a different
version of a collection.  If a member of the specified collection
version is a version history for a resource that is already
present in the workspace of that collection, the server MUST
create a second binding to that resource. (RFC-3253, Section 14.11).

Cheers,
Geoff