Subject: Re: I-D ACTION:draft-ietf-webdav-bind-07.txt

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Oct 2004 09:25:07 +0200

Julian Reschke wrote:
> 
> OK,
> 
> this new draft contains the changes made in the two previous weeks:
> 
> 'A.5  Since draft-ietf-webdav-bind-06
> 
>    Rewrite Editorial Note.  Open and resolve issues "2.6_identical",
>    "specify_safeness_and_idempotence" and "ED_rfc2026_ref".'
> 
> 
> As far as I am concerned (I know I'm speaking for the currently active 
> authors), this spec can be considered finished. There won't be any 
> progress anymore unless more people actually sit down and read it; and 
> the best way to achieve this is to actually issue the working group 
> last-call (as planned in the working group's charter for May).
> 
> Lisa, Joe?
> 
> Best regards, Julian

Lisa, Joe,

could you please be so kind to state why -- from the working groups 
chair's point of view -- the BIND spec hasn't been last-called yet. 
Whatever is blocking progress here, please state it so that the authors 
and the other members of the working group can help resolving it.

Best regards, Julian

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

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 15 Oct 2004 08:04:23 -0700

There's now a machine and we've figured out how to set up Bugzilla as 
an issues tracker.  Joe's in charge of this and we'd like to be able to 
track the resolution of issues to make last calls happen smoothly.  
They're in the process of figuring out what version of Bugzilla to 
install.

Joe also looked into rt but ended up preferring bugzilla.

Lisa

On Oct 15, 2004, at 12:25 AM, Julian Reschke wrote:

>> As far as I am concerned (I know I'm speaking for the currently 
>> active authors), this spec can be considered finished. There won't be 
>> any progress anymore unless more people actually sit down and read 
>> it; and the best way to achieve this is to actually issue the working 
>> group last-call (as planned in the working group's charter for May).
>> Lisa, Joe?
>> Best regards, Julian
>
> Lisa, Joe,
>
> Whatever is blocking progress here, please state it so that the 
> authors and the other members of the working group can help resolving 
> it.
>
> Best regards, Julian
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Oct 2004 17:19:47 +0200

Lisa Dusseault wrote:
> 
> There's now a machine and we've figured out how to set up Bugzilla as an 
> issues tracker.  Joe's in charge of this and we'd like to be able to 
> They're in the process of figuring out what version of Bugzilla to install.
> 

OK, that's good to hear.

I'm still not sure about why the existence of a specific bug tracking 
system is a prerequisite for even *reporting* issues; in fact I haven't 
seen that as a requirement in other working groups before.

So unless somebody is actually reporting an issue with BIND (draft 07) 
on this mailing list, I'll continue to assume that there aren't any. On 
the other hand, if somebody actually *has* an issue, it would be nice to 
get it reported here, no matter whether that new tracking system is in 
place or not.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 15 Oct 2004 09:12:57 -0700

I'll be submitting a number of bind issues to the issues tracking 
database once it's up.

Lisa

On Oct 15, 2004, at 8:19 AM, Julian Reschke wrote:

>> an issues tracker.  Joe's in charge of this and we'd like to be able 
>> to track the resolution of issues to make last calls happen smoothly. 
> system is a prerequisite for even *reporting* issues; in fact I 
> haven't seen that as a requirement in other working groups before.
>
> on this mailing list, I'll continue to assume that there aren't any. 
> On the other hand, if somebody actually *has* an issue, it would be 
> nice to get it reported here, no matter whether that new tracking 
> system is in place or not.
>
> Best regards, Julian
>
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Oct 2004 18:17:32 +0200

> I'll be submitting a number of bind issues to the issues tracking 

Shrug.

It's still unclear to me why you aren't posting them here right away (or 
for that matter, haven't before).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 15 Oct 2004 10:19:20 -0700

Here are some of the issues I've posted before:

http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0016.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0014.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0154.html, 
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0146.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0149.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0140.html

I know that you've answered these emails before, but that doesn't mean 
I consider the issues resolved.  Joe's going to take care of resolving 
them since I wouldn't declare consensus on issues I raised unless it 
were overwhelmingly clear.  I don't particularly want to discuss these 
now because we don't have the issue tracking DB up yet.

Lisa

On Oct 15, 2004, at 9:17 AM, Julian Reschke wrote:

> It's still unclear to me why you aren't posting them here right away 
> (or for that matter, haven't before).
>
> Best regards, Julian
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Oct 2004 20:37:46 +0200

Lisa Dusseault wrote:
> I know that you've answered these emails before, but that doesn't mean I 
> consider the issues resolved.  Joe's going to take care of resolving 

Thanks for putting those on the table; this allows us to at least 
proceed. I'll comment on them separately.

I'm not sure why you don't want to discuss those though. IETF working 
groups by definition do their work on their respective mailing lists; 
whether or not a supporting bug tracking system (which will have to send 
change notifications to the mailing list anyway) is in place should not 
be relevant (although this probably will be helpful).

BTW: issues do not get resolved by a specific person (not even one of 
the chairs), but by discussing them in the working group (== on the 
mailing list) until rough consensus is detected (and yes, the WG chair 
should try to decide when this consensus is reached).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Oct 2004 20:43:42 +0200

See 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0140.html>.

As far as I can tell, this was answered in

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0143.html>

and

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0147.html>

I can't see any posting in which somebody was rejecting these 
explanations, so I have to assume that there was consensuns that this 
isn't a problem and no change is required.

Please let me know

a) if they haven't (in which case I'd like to see answers to the two 
replies) and/or

b) whether the explanations should be added to the BIND issues list.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Oct 2004 20:48:48 +0200

See 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0149.html>.

These were indeed two questions which I tried to answer in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0150.html>.

Summary:

1) BIND and UNBIND require the ACL privileges DAV:bind and DAV:unbind. 
Nobody objected to the statement that this is kind of obvious and 
doesn't need to be stated explicitly.

2) I did not understand the second part of the issue and asked for an 
explanation that was never supplied.

As far as I can tell, part 1 has been resolved, while part 2 is on hold 
until there's an explanation of what the issue actually is.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 15 Oct 2004 11:55:22 -0700

On Oct 15, 2004, at 11:37 AM, Julian Reschke wrote:
> whether or not a supporting bug tracking system (which will have to 
> send change notifications to the mailing list anyway) is in place 
> should not be relevant (although this probably will be helpful).
>
I am quite willing to discuss these on the list, what I said was that I 
wasn't interested in discussing them on the list now (not until Joe's 
ready to monitor the issue discussions and track issues and declare 
consensus.)

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Oct 2004 20:59:17 +0200

See 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0154.html> 
and 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0146.html>.

As far as I understand, this issue is about the BIND spec being 
incompatible with servers that vary the value of a property based on the 
request-URI to which a PROPFIND request was applied.

The authors feel that properties are part of the state of the resource, 
and all the BIND spec defines are additional access paths to the same 
resource. Thus, property values should not vary based on the request-URI.

If a particular server (such as the Microsoft servers mentioned in 
Lisa's mail) behave differently, they'll have to make changes if they 
*also* want to support the BIND protocol (as far as I can tell, there 
are no plans to do that, so I don't think we should worry about that).

In the discussion thread 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/thread.html#154>), 
I see three people agreeing (Geoff, Jason and myself) and nobody 
supporting Lisa's point of view, so, as far as I can tell, there was a 
rough consensus that this isn't a problem at *that* point of time.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Oct 2004 21:27:35 +0200

See 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0016.html> and
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0014.html>.

This is in fact *the* permathread which is IMHO caused by the fact that 
the locking semantics in RFC2518 are underspecified (because of which 
the working group has produced a summary of locking semantics that 
should go into RFC2518bis which is called "GULP", latest version at 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0177.html>).

As far as I can tell from re-reading the whole thread, there was nobody 
(except Lisa) particulary asking for adding LOCK clarifications into the 
BIND spec itself, because these clarifications are needed completely 
independantly of BIND. So they should either appear in RFC2518bis or  in 
a separate WebDAV locking spec (as suggested and demonstrated by myself).

To summarize: this is not really an issue with the BIND spec, but with 
how this working group is approaching the various locking related 
problems in RFC2518. My (latest) summary about this issue can be found 
in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0071.html> 
and I think it would be good if the working group would finally start a 
discussion about it:

"As far as I can tell, the only remaining open question is whether
RFC2518's treatment of locks is sufficient to explain the relation
betweem (multiple) bindings and locks. The (active) authors of the spec
(Geoff and myself) agree that the BIND spec is compatible with what
RFC2518 says about locks, and no further clarification is stricly
required. Note that RFC2518 already talks about locking "replicated
resources"
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3>), so
this has been explicitly planned for even back then. The important fact
here being that multiple bindings to a resource and locks are already
compatible, and nothing needs to ne explicitly changed for that.

Now, how should that spec proceed? There seem to be several options,
including:

#1) Just release the BIND spec as is (that is, immediately do a WG last
call),

#2) Add locking specific clarifications to BIND, then release it,

#3) Release the BIND spec with a normative reference to RFC2518bis
(essentially delaying it until RFC2518bis is finished) or

#4) Extract locking out of RFC2518bis into a separate spec, resolve all
open locking-related issues, and submit this as a new specification
(updating RFC2518) for publication as a proposed standard (note there's
a long summary about this option posted by me in April (!):
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>).
Note that none of these open locking issues (those listed on RFC2518's
issues list at <http://www.webdav.org/wg/rfcdev/issues.htm> actually has
*anything* to do with the relation to multiple bindings). BIND then can
either be released independantly or with a normative reference to that
new spec.

Personally I see nothing wrong with option #1. Several implementors
already have BIND working experimentally as defined in the spec (for
instance Apache Slide and SAP in Netweaver). More people seem to look at
it but may be waiting for it to become an RFC. Unless there's an actual
risk of people misunderstanding BIND and lock interactions (something we
*could* take care of on this mailing list), having possible lock
clarifications appear in something published slightly later doesn't seem
to be any problem at all.

#2 IMHO would be an *extremely* bad idea, because it would duplicate
specification text in several specs, so spec revisions either need to be
100% compatible with it; or BIND would soon need to be updated itself by
these revisions. So there'd be additional work and risk of being
inconsistent with very little gain. Remember that support for multiple
bindings and locking are completely separate things (you can have
multiple bindings on a server without locking support because locking is
an *optional* WebDAV feature).

#3 makes sense if RFC2518bis is actually going to be finished anytime
soon. I made my contribution by pushing for resolutions for almost all
locking-related questions; but it's up to the authors to give an
estimate about when it can be done. (I'll try to review the new draft
before next week; and it would be good if others would do that as well).

#4 is the option I've been working on the last three months (HTML:
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-05.html>,
TXT:
<http://www.ietf.org/internet-drafts/draft-reschke-webdav-locking-05.txt>,
issues list:
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>). 

As far as I'm concerned, this spec is almost done (with the notable
exception of finding the right place for the GULP summary and discussing
the locking-related questions of "If" header semantics). Even if the
working group decides not to adopt this as a WG document, the effort
still will have been worth it for the progress we've been making on open
locking issues. Of course I personally would like to see this to be used
as a basis for a new specification so that the locking feature can be
removed from RFC2518bis. This would actually make it *easier* for
RFC2518bis to progress to a "draft" standard, because it would be
significanly simplified.
In the case the WG makes that decision, I'll happily work together with
volunteers to finish this as a working group document."

I still think that no harm is done by just releasing BIND with no 
changes (option #1) -- as a matter of fact it represents the consensus 
of various implementors *and* running code. This way we get the top 
priority from our working group's agenda done, and we can concentrate on 
the next steps (being RFC2518bis and the RDEDIRECT spec).

Best regards, Julian