Subject: Remaining issues with the bind draft -- process

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Apr 2004 20:55:37 +0200

Julian wrote:

> Lisa Dusseault wrote:
>
>> I've re-reviewed the bind draft. Many of these issues have come up
>> before but I feel they haven't been resolved in the draft.
>>
>> General
>> -----------
>>
>> The spec must stand alone, not be dependent on changes to RFC2518 in
>> 'bis'. Otherwise, bind can't be approved until RFC2518bis is approved.
>> That means no dependencies for things like 'lockroot'.
>
> There isn't any.

Lisa, was your reference to 'lockroot' a pointer to one such reference 
which exists, or something which is added to 2518bis which you point 
out is not allowed to be used in the bind draft?

>> In general, the spec needs more info to specify how existing things
>> work. All the following questions must be answered in the spec, NOT 
>> just
>> in email. The spec must be explicit, because different people reading 
>> a
>> model description always end up with different ideas how the model 
>> works
>> in practice.
>
> Here I disagree.

Remember I asked a question explicitly about interoperability between 
things developed by just reading the spec...then look at the list 
below. I don't see the statement "yes, there will be interoperability" 
matches those statements.

Can you explain?

> First of all, there are several ways to resolve questions raised:
>
> 1) If there is a simple answer based on existing specs and the current
> draft, just answer it here on the mailing list.
>
> 2) If the issue is likely to be re-raised (because the answer is not
> obvious), record it (and the answer) on the issues list.
>
> 3) If the issue is indeed valid, add it to the issues list and attempt
> to resolve it.
>
> In general, there are areas where the spec *can't* specify how existing
> things work, because they depend on specific implementations. I
> absolutely agree that those situations should be avoided, but sometime
> there's nothing we can do about that.
>
> I'll post answers to the specific issues in a separate mail.

     paf

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Apr 2004 21:36:27 +0200

On Apr 5, 2004, at 21:18, Julian Reschke wrote:

> And of course it's possible (or actually likely) that we missed 
> something. That's why we're asking for feedback; and the most 
> efficient way to get feedback is by last-calling the document in the 
> working group (the fact that we're having this discussion sort of 
> proves it, right?). So as long as we're getting *new* questions, it's 
> fine to delay the last-call; however once the mail threads stop (which 
> they did last week), we should move on.

Absolutely, you are correct.

BUT, I don't see any reason to last call the document before *I* at 
least understand the issues and misunderstandings and what ever between 
you and Lisa regarding locking and binding. See separate mail.

Else I will as chair just get the same arguments again.

But, message is received.

    paf

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Apr 2004 21:18:33 +0200

Patrik Fältström wrote:

> which exists, or something which is added to 2518bis which you point out 
> is not allowed to be used in the bind draft?

Lisa was probably referring to a previous discussion where we agreed 
that clients will *benefit* from the new DAV:lockroot element, because 
it allows them to programatically discover which URL is protected by a 
lock. However, this is a nice-to-have feature, and clients certainly 
don't require it (after all, they should know the URL because they 
usually issued the LOCK request themselves). So the consensus (imho) was 
that it's presence in RFC2518bis simply is "good enough".

If people feel that DAV:lockroot only being defined by RFC2518bis 
actually is a problem, we can add it to BIND. However, I'd like to avoid 
it because it creates an area of overlap that doesn't seem to be necessary.

>>> work. All the following questions must be answered in the spec, NOT just
>>> in email. The spec must be explicit, because different people reading a
>>> model description always end up with different ideas how the model works
>>> in practice.
>>
>>
>> Here I disagree.
> 
> 
> things developed by just reading the spec...then look at the list below. 
> I don't see the statement "yes, there will be interoperability" matches 
> those statements.
> 
> Can you explain?
> 

Patrik, I'm not sure what you're asking for. There'll always be the 
possibility that people misunderstand a spec, don't read a normative 
reference, or just miss something.

So the question about expected interoperability leads nowhere unless 
it's a *specific* spec question - of course the authors expect that the 
spec is sufficient for interoperable implementations, otherwise we 
wouldn't ask for last-call.

And of course it's possible (or actually likely) that we missed 
something. That's why we're asking for feedback; and the most efficient 
way to get feedback is by last-calling the document in the working group 
(the fact that we're having this discussion sort of proves it, right?). 
So as long as we're getting *new* questions, it's fine to delay the 
last-call; however once the mail threads stop (which they did last 
week), we should move on.

Best regards,

Julian

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

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 5 Apr 2004 12:58:22 -0700

> out is not allowed to be used in the bind draft?

In this discussion, I asked whether a user can UNLOCK a binding that 
wasn't
the binding where the LOCK was issued (these are both bindings to the 
same
resource).  One of the email answers was that the client software could 
always
use the "lockroot" element in the lock information to discover which 
URI was
locked and thus they could find out which one to unlock.

I find that answer unacceptable for two reasons.  First, 'lockroot' 
isn't standardized -- it's
only a proposed extension to WebDAV/RFC2518, and not all servers 
implementing
bindings must implement this proposed extension.   Second, it doesn't 
answer the
question of how server implementations of bindings MUST behave.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Apr 2004 22:11:27 +0200

Lisa Dusseault wrote:

> In this discussion, I asked whether a user can UNLOCK a binding that wasn't
> the binding where the LOCK was issued (these are both bindings to the same
> use the "lockroot" element in the lock information to discover which URI 
> was

1) First of all, clients are not supposed to remove locks they haven't 
created. If the lock was created by themselves, they *know* the original 
request URI. If they didn't, this is definitively an edge case.

2) That being said, the *resource* is locked; and thus it doesn't matter 
what request URI is used to submit the UNLOCK request to. This is 
consistent with the general statement that additional bindings only 
create additional access paths, but that the methods interact with the 
*resources*. In general, the access path does not matter. See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-05.html#rfc.section.1.p.4>:

"The BIND method defined here provides a mechanism for allowing clients 
to create alternative access paths to existing WebDAV resources. HTTP 
[RFC2616] and WebDAV [RFC2518]  methods are able to work because there 
are mappings between URIs and resources. A method is addressed to a URI, 
and the server follows the mapping from that URI to a resource, applying 
the method to that resource. Multiple URIs may be mapped to the same 
resource, but until now there has been no way for clients to create 
additional URIs mapped to existing resources."

So in general, the access path does not matter. That's the whole point 
of the binding spec.

Regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 5 Apr 2004 13:15:44 -0700

On Apr 5, 2004, at 1:11 PM, Julian Reschke wrote:

>> resource).  One of the email answers was that the client software  
>> could always
> created. If the lock was created by themselves, they *know* the  
> original request URI. If they didn't, this is definitively an edge  
> case.
>
> 2) That being said, the *resource* is locked; and thus it doesn't  
> matter what request URI is used to submit the UNLOCK request to. This  
> is consistent with the general statement that additional bindings only  
> "The BIND method defined here provides a mechanism for allowing  
> clients to create alternative access paths to existing WebDAV  
> resources. HTTP [RFC2616] and WebDAV [RFC2518]  methods are able to  
> work because there are mappings between URIs and resources. A method  
> is addressed to a URI, and the server follows the mapping from that  
> URI to a resource, applying the method to that resource. Multiple URIs  
> may be mapped to the same resource, but until now there has been no  
> way for clients to create additional URIs mapped to existing  
> resources."
>

Except for the cases where it does matter, like BIND/UNBIND, MOVE and  
DELETE.  The spec is not clear enough about which methods apply to the  
binding and which apply to the resource, and when.  The spec doesn't  
say whether LOCK behaves more like PUT, or more like BIND.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Apr 2004 22:50:22 +0200

Lisa Dusseault wrote:

>> So in general, the access path does not matter. That's the whole 
>> point  of the binding spec.
> 
> 

I agree that sometimes it may *look* like it does. That follows from the 
specific property that locks do not only apply to the resource, but that 
they *also* protect the request URL to which the lock has been applied. 
So a namespace operation (such as removing a binding) may require a 
lock-token when that binding was protected by the lock, and otherwise 
not. In reprospective, this may have been the wrong design decision; but 
this was done in 1998, not today.

Consider the bindings "p/a1" and "p/a2" to resource A. LOCK was applied 
to the request URI "p/a1", resulting in the resource A being locked by a 
lock that protects the URL "p/a1".

Applying DELETE to "p/a1" requests that the binding "a1" is removed from 
it's parent collection "p". Applying DELETE to "p/a2" requests that the 
binding "a2" is removed from it's parent collection "p". As only the URL 
"p/a1" is protected by the lock, the first request will fail, while the 
second will succeed (if the client doesn't specify the lock token in the 
"If" request header).

What may be confusing here is that in fact the resource "A" isn't 
modified *at all*. Rather than that, it's the state of the collection 
resource identified by "p" that is being manipulated in both cases. For 
UNBIND, the BIND spec gets this right by applying the method to the 
parent collection, and having the actual member URI (to be removed) 
passed in as a parameter in the request body.

I absolutely agree that RFC2518 doesn't explain this very well (*). But 
this is true independantly of the BIND spec, and thus should be fixed in 
RFC2518bis. Alternatively we can also (as discussed in January) extract 
WebDAV locking into a separate independant spec (I'm willing to help 
working on that), but it really has little to do with BIND.

Regards, Julian

(*) For instance, I just tried to figure out where RFC2518 says that I 
can't rename "p" when "p/a1" is being locked without passing the lock 
token for A. Nevertheless, this is true, and everybody seems to agree on it.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Apr 2004 23:00:45 +0200

> token for A. Nevertheless, this is true, and everybody seems to agree on 

Speaking of which, this seems to follow from RFC2518, section 8.9.2:

"A MOVE with "Depth: infinity" instructs that the collection identified 
by the Request-URI be moved to the URI specified in the Destination 
header, and all resources identified by its internal member URIs are to 
be moved to locations relative to it, recursively through all levels of 
the collection hierarchy."

...so it is defined, but RFC2518's introduction of the locking feature 
really could be more explicit about that...

Regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 5 Apr 2004 23:10:13 +0200

Am 05.04.2004 um 22:15 schrieb Lisa Dusseault:
> [...]

Well, the bind spec does not talk about LOCK. It defines how BIND, 
REBIND and UNBIND
work in the presence of locked resources.

RFC 2518 explicitly adresses the case where multiple URLs to a single 
resource do exist
(see 2518 Chapter 5.1). *RFC 2518* does not explain how LOCK and other 
methods
work in the presence of multiple URLs to the same resource.

The bind spec currently defines the behaviour of namespace operations 
in the presence
of bindings. Something which should have been done in RFC 2518, but 
nobody is
perfect. The bind spec is a good place to do so.

What is not a good idea is to throw the complete, current understanding 
of LOCK
into the bind spec. This is not a failure of the spec, but was 
deliberatly chosen as
the path of wisdom to follow.

LOCK and locked resources in RFC 2518 are, as we know today, 
incompletely specified
in RFC 2518 and have let to interoperability issues. Therefore all 
knowledge was agreed
upon in the GULP and it was also agreed that GULP should find its way 
into RFC 2518bis,
because that's where it should be.

So, it is inaccurate and definitely not helping anyone with any 
implementation issue to
request cleanup of LOCKs from the authors of the bind spec. I 
personally am waiting
for 2 years now that RFC 2518bis makes progress comparable to other 
specs of this
group.

//Stefan

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Apr 2004 23:17:51 +0200

Julian Reschke wrote:
 > ...
> ...

For the record: see mail thread 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/thread.html#30>.

Regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Apr 2004 23:20:15 +0200

Stefan Eissing wrote:

> request cleanup of LOCKs from the authors of the bind spec. I personally 
> am waiting

Another way to look at this is that WebDAV LOCKING needs clarifications, 
but it needs them independantly of the BIND spec. It would be funny if 
we'd point people to the BIND spec if they have locking questions, yet 
do not plan to implement the BIND spec at all.

Regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 5 Apr 2004 14:59:32 -0700

At 11:20 PM +0200 04/05/2004, Julian Reschke wrote:
>Another way to look at this is that WebDAV LOCKING needs 
>clarifications, but it needs them independantly of the BIND spec. It 
>would be funny if we'd point people to the BIND spec if they have 
>locking questions, yet do not plan to implement the BIND spec at all.
>

Speaking personally, my concern here would be that if those 
clarifications were not
present, BIND behavior became non-deterministic.  If 2518bis was done, and
BIND pointed to it to solve that hypothetical problem, all might be 
goodness; if
it will not be done, on the other hand, getting the job done in the spec which
will be completed might be the practical way to go.

Again, my personal two cents,
			regards,
				Ted

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 6 Apr 2004 00:09:03 +0200

> will be completed might be the practical way to go.

But, alas, locks need fixing beyond the scope of the bind spec. As one 
example, RFC
2518 is unclear on the interaction between locks and the IF header. 
This is the
biggest area of non-interoperability. Now, the bind spec cannot clarify 
the general
working of the IF header and fixing the IF header needs also to be done 
for
servers which do not want to support the bind feature.

//Stefan

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Apr 2004 00:13:27 +0200

> Again, my personal two cents,

If we rephrase that as "There should be a standards-track document 
clarifying WebDAV looking as soon as possible.", I'll absolutely agree. 
However, I think that document shouldn't be BIND, if only for the simple 
reason that it matters to those who don't plan to implement BIND at all 
as well.

If we can't get RFC2518bis finished soon, I think the approaches (2) and 
(3) presented in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0030.html> 
would make more sense:

--
2) Come up with a separate spec that updates RFC2518 and just summarizes
all that we changed or intend to change regarding locking (like
deprecation of lock-null resources, fixes to LOCK and lock refresh, If
header syntax, and lockdiscovery extensions). That would still be a
"draft standard" as RFC2518, but it would make things easier for
RFC2518bis as well, because all these changes would be written down in a
spec that came out prior to the revision, so wouldn't be "new" anymore.
It would also encourage implementors to actually *implement* these
changes and extensions *before* RFC2518bis comes out.

3) A drastic approach would be to de-couple locking entirely from
RFC2518 ("updating" RFC2518 again). That would look similar to how
RFC3253 is organized (locking would become an optional module, and
everything that needs to be said about locking would reside in that
separate document). Of course that approach would have a significant
impact on RFC2518bis, because optimally, it wouldn't say anything about
locking anymore either.
--

I'm willing to help working on either; we just need working group 
consensus to do this as it would affect the (currently dormant?) 
activities on RFC2518bis.

As an experiment, I've already extracted locking from RFC2518. This 
turned out to be relatively simple *except* for the locking semantics 
built into the "If" header checks (which will require some more 
thinking). BTW: RFC2518 shrinks by about 30% (interested parties just 
email me for a copy).

Regards, Julian

---

From: Antony Blakey <[email-masked]>
Date: Tue, 6 Apr 2004 11:33:33 +0930

I'm a (lurking) WebDAV implementer, and I'm waiting for BIND. I think 
it's bizarre to propose publishing BIND when understanding it depends 
on RFC2518bis, that has an indeterminate publish schedule and may never 
happen. IMO the only thing that makes sense is to publish locking 
separately, and only then publish BIND. I've been hoping this would 
happen ever since I saw GULP, so for what it's worth, I request 
Julian's point 3.

As an aside, I think the BIND spec should err on the side of ease of 
comprehension, rather than being axiomatically minimal. I think the 
process of writing such explanatory content is more likely to bring to 
light misunderstandings that illustrate ambiguity or incomplete 
coverage. Developing such non-normative explanatory content is a 
time-honoured and very effective mechanism to avoid that.

Just my $0.02

> impact on RFC2518bis, because optimally, it wouldn't say anything about

Antony Blakey
-------------
Some defeats are installments to victory.
   --Jacob Riis

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 5 Apr 2004 22:58:13 -0400

I strongly support choice #3 (issuing a locking draft).

If we are considering defining locking behavior in a 
separate draft that isn't about locking (i.e. the bind draft),
then I think doing so in a separate draft makes the most sense.

Especially if Julian has done most of the editorial work
(thanks, Julian!), we should be able to focus on it after
the binding draft is finalized, and get it out soon afterwards
(once it is decoupled from the many unresolved issues in
the rest of 2518bis).

Cheers,
Geoff

Julian wrote on 04/05/2004 06:13:27 PM:

> > it will not be done, on the other hand, getting the job done in the 
spec 
> > which

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 5 Apr 2004 22:58:19 -0400

> matches those statements.

The phrase Julian (and I as well, in a separate message) disagreed with
was "All the following questions must be answered in the spec, NOT 
just in email".

In particular, our response was: some questions are answered in email,
some questions become issues, and some issues end up causing changes to
the spec.  If every question on the mailing list required an explicit
addition to the spec, the spec would become completely inaccessible due
to its bulk.

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 5 Apr 2004 23:22:41 -0400

Hi Antony,

Thanks for speaking up!  It's folks that aren't part of the
design team whose feedback on this point is most valuable.

I agree that comprehensibility is more important than
axiomatic minimality, but we do try to avoid duplicating
normative information from other specs, to avoid confusion
when those other specs are revised.

Were there specific parts about the BIND spec that you felt
merited/required additional explanation?

Thanks,
Geoff

---

From: Antony Blakey <[email-masked]>
Date: Tue, 6 Apr 2004 13:43:30 +0930

> design team whose feedback on this point is most valuable.

The fact that I have to reconstruct design motivations from the mailing 
list when reading the spec in order to review it is demonstration of 
why more non-normative content should be with the spec. Otherwise 
responses will be driven by "that's more work for my server" or "that 
doesn't match my use case" rather than "I understand the trade-offs 
required by both extant and projected uses", which seems to me to be 
what is truly required. I've given an example of this below.

I don't feel qualified to give detailed feedback because I'm not sure 
*why* certain decisions were made.

> when those other specs are revised.

I'm talking about non-normative content. As a matter of process I think 
that writing (for example) a user guide, generates a better spec. In 
this case, the spec would be less likely to reflect the hidden 
assumptions of specific implementers. Writing explanation is like peer 
review of code.

> merited/required additional explanation?

To be honest, my comments were motivated by watching the discussion 
between (principally) Lisa and Julian, rather than reading the most 
recent BIND spec, although now I'm motivated to do that!

I know there have been arguments about DELETE not being equivalent to 
UNBIND, and MOVE not being BIND+UNBIND. However, our implementation is 
transactional and non-transactional semantics seem broken to us - 
that's one place where some non-normative content motivating these 
distinctions would help. As another (tangential) example, having a lock 
create a new resource seems, on the surface, broken to us, because 
effects caused by a failed lock creator should be rolled back at the 
server. IMO any spec specifying that behaviour should say why that's 
required. I'm sure there must be some reason for this that 
non-transactional environments require, which is outside our headspace.

As a matter of completeness: it has always seemed to me that binding is 
more fundamental than locking, and that it would be better to have the 
WebDAV spec recast in terms of bindings, with support for more than one 
binding to a resource as an implementation option. Locking would then 
be on top of that, explaining how core semantics are modified in the 
presence of locks. I know this isn't going to happen.

Antony Blakey
-------------
Reflecting on W.H. Auden's contemplation of 'necessary murders' in the 
Spanish Civil War, George Orwell wrote that such amorality was only 
really possible, 'if you are the kind of person who is always somewhere 
else when the trigger is pulled'.
   -- John Birmingham, "Appeasing Jakarta"

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Apr 2004 09:29:55 +0200

> recent BIND spec, although now I'm motivated to do that!

That whould be great...

> UNBIND, and MOVE not being BIND+UNBIND. However, our implementation is 

Well, REBIND isn't MOVE as the working group couldn't change the 
semantics for MOVE (that would have breaked existing code). Thus REBIND 
is introduced as atomic version of MOVE:

"The REBIND method removes a binding to a resource from one collection, 
and adds a binding to that resource into another collection. It is 
effectively an atomic form of a MOVE request."

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#METHOD_REBIND>

Clients can now select a best-effort move (MOVE) or a transactional one 
(REBIND), when supported by the server.

The situation for DELETE vs UNBIND is a bit more complicated. Do you 
think the rational should be explained here?

> transactional and non-transactional semantics seem broken to us - that's 
> one place where some non-normative content motivating these distinctions 
> would help. As another (tangential) example, having a lock create a new 

Well, that's an issue with RFC2518, right? MOVE and DELETE aren't atomic 
for the simple reason that there are servers that can't or don't want to 
implement in atomically.

> resource seems, on the surface, broken to us, because effects caused by 
> a failed lock creator should be rolled back at the server. IMO any spec 
> specifying that behaviour should say why that's required. I'm sure there 
> must be some reason for this that non-transactional environments 
> require, which is outside our headspace.

I'm not sure what you're talking about here. LOCK is a bit special in 
that it creates an empty resource when the URL wasn't mapped before, but 
that is needed to implement a safe way to do a safe "save as" operation. 
The LOCK operation itself is transactional. Either it succeeds (and 
creates a locked resource), or it fails (in which case nothing should be 
left). BTW, this is standard RFC2518 and has nothing to do with BIND.

> binding to a resource as an implementation option. Locking would then be

I agree with the fact that bindings are more fundamental, as they affect 
the understanding of the relation of URLs, collection membership and 
resources. That being said, RFC2518 already does that in a minimal way; 
it just calls bindings "internal member URIs" and doesn't provide

- "same resource" discovery
- explicitly creating new bindings

But the concept per se is there.

> on top of that, explaining how core semantics are modified in the 

Well, we've been discussing separating locking from the rest for some 
time now (see the mail thread that started in January: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/thread.html#30>). 
However, this proposal affects an official working group item 
(RFC2518bis), so we didn't make any progress here yet, missing support 
from the RFC2518bis authors.

Regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Tue, 13 Apr 2004 11:53:15 -0700

>then I think doing so in a separate draft makes the most sense.
Apologies for jumping into this thread late, I've been traveling on 
business and unable to keep up with the discussion. Anyway, I'd like to 
offer my (non-binding) +1 on issuing GULP as a seperate draft - this 
approach seems to be the most reasonable way to proceed at this juncture.

Elias

>>>present, BIND behavior became non-deterministic.  If 2518bis was done, 
>>>      
>>>
>and
>  
>