Subject: Re: Last Call: draft-ietf-webdav-rfc2518bis (HTTP Extensions for Distributed Authoring - WebDAV) to Proposed Standard

From: "Julian Reschke" <[email-masked]>
Date: Mon, 15 Jan 2007 17:42:50 +0100

The IESG schrieb:
> The IESG has received a request from the WWW Distributed Authoring and Versioning WG (webdav) to consider the following document:
>
> - 'HTTP Extensions for Distributed Authoring - WebDAV '
>    <draft-ietf-webdav-rfc2518bis-17.txt> as a Proposed Standard
> ...

The short answer: this draft fixes a number of well-known problems in RFC2518, removes some unimplemented features, and adds some minor improvements. Some parts of the spec are clearly better than before, others are worse in that they replace the description of locking by new text which is unnecessarily confusing, partly incorrect and inconsistent. As such, the document should not be approved and published in its current state.

The long answer:

(1) History of this Last Call

RFC2518bis has been under development for an extremely long time, starting almost five (!!!) years ago. Up until autumn 2005 however, there was only very little activity. When faced with the alternative to either shut down the working group, or to produce a usable document in a relatively short of time, the most active members of the working group decided to give it a try.

Draft 14 was (WG) last-called in February 2006, containing lots of improvements, but also a new section about locking which had had almost no review (being added in draft 12, published the same month). The last call basically happened not because the working group thought that the document was ready, but to make the deadline.

After the WG Last Call, we have seen fewer reviews than we hoped for, but certainly not many. The majority of issues raised during LC (and later on) have not been addressed at all in the WG's document. Basically, there has been almost no activity on the WG's document since.

At the time of this writing, there were over fifty issues opened against the specification (see <http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-bis>). For many of them there were suggestions resolving the problems with spec-ready text (all mention some of them later on).

(2) Compatibility with RFC2518

The Last Call announcement states:

> While the WEBDAV working group was originally chartered to produce a
> draft standard update to RFC 2518, this documented is being targeted
> as a replacement Proposed Standard because of a number of substantive
> changes to the original semantics.

This is completely inaccurate. None of the original semantics has been changed substantively at all. The main reason why the WG didn't try to achieve Draft Status was because there was not sufficient energy for collecting the required interoperability data. We also realized that some of the minor improvements we made weren't widely implemented (nor not implemented at all), and thus decided it would make more sense doing a revision that stays at the stage of a Proposed Standard.

As a matter of fact, it was long discussed whether a new compliance level (Section 18.3) was required at all. As far as I can tell, the only change for which the new compliance level helps at all is the ability to find out about the server's support for absolute paths in the "If" and "Destination" header.

(3) Alternatives offered by the IESG

The announcement goes on saying:

> A key question for reviewers is whether
> this document is substantially better than RFC 2518 and should
> replace it.

For many of the open issues there *are* proposals how to resolve them. The recommended changes are recorded both in the issue tracker (<http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-bis>) and an experimental draft available at <file:///C:/projects/xml2rfc/draft-reschke-webdav-rfc2518bis-latest.html>. The latter does not resolve *all* open issues *yet*, mainly in an attempt to keep the differences to the Working Group's document to a manageable size.

So I would appreciate if reviewers not only take a look at RFC2518 and the Last Call draft, but also to the resources above.

(4) Examples for open issues

(4a) One of the things RFC2518bis was supposed to fix was the confusion around locking. Right now, it fails big time. For instance, it fails to consistently distinguish between the "owner" and the "creator" of a lock (issue 244), and is inconsistent with respect to the term "lock root" (sometime it say it's a URI, sometimes it says it's a resource; which is a significant difference when a resourse is identified by multiple URIs) (issue 251).

(4b) Unnecessary new requirements: an example is the new (MUST-level) requirement to submit a Depth header with PROPFIND (issue 213). This is just one of several cases where the draft made changes for no apparent reason; that is, there was no problem with what RFC2518 said previously.

(4c) Issue 237 raises a security issue that isn't discussed in RFC2518, and I think it's quite important. As far as I can tell, there's some sort of agreement that this really is a user agent problem. That being said, all user agents expose this problem, and the W3C WEBAPI working group was quite unresponsive when it was mentioned. Thus, it seems to me that RFC2518bis *minimally* needs to minimally mention the problem, making server implementors/admins at least aware.

I could go on and on, but all of this is in the issue tracker, and has been known to the working group.

Best regards, Julian

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Ted Hardie <[email-masked]>
Date: Mon, 15 Jan 2007 11:22:55 -0800

At 5:42 PM +0100 1/15/07, Julian Reschke wrote:
>This is completely inaccurate. None of the original semantics has been changed substantively at all. The main reason why the WG didn't try to achieve Draft Status was because there was not sufficient energy for collecting the required interoperability data.

It is certainly also true that the working group has very little energy, and that collecting
the required interoperability data would have likely failed.  The document's listing
of changes since RFC 2518 shows several items, though, that would have caused
a recycle at Proposed no matter what energy level was present in the group.  If
you see "are now required" in the listed behavior where it was not before, it
would likely have forced a recycle.  As it stands, though, the key point is that this
is a replacement-in-place for 2518 and that there is no apparent energy for
a successor aiming at Draft any time soon.

>So I would appreciate if reviewers not only take a look at RFC2518 and the Last Call draft, but also to the resources above.

Reviewers are certainly welcome to look at the issue tracker and the proposed
alternative draft.  But any reviewer doing so should also look at the working
group archives.   The discussion and efforts by the WG chair and his predecessors
to achieve consensus and forward progress are noted there, and there have
been multiple attempts to use teleconferences etc. to move things forward as
well.  

As the Last Call requests, reviewers are requested to consider the question:
"Is this better than the document it replaces"?  That it could be better yet
is obviously true, but that has to be understood in the context of the WG's
rate of progress.

>(4a) One of the things RFC2518bis was supposed to fix was the confusion around locking. Right now, it fails big time. For instance, it fails to consistently distinguish between the "owner" and the "…

The locking issue was raised by Julian prior to last call to me and to Cullen as WG chair.
It was the subject of a specific question of mine in a solicited review request sent
prior to making the IETF Last Call.  I have been waiting on permission to forward those
to the IETF list; lacking that, I have entered the responses in the draft tracker as
"solicited review one" and "solicited review two".  They can be read here:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8360&rfc_flag=0

These solicited reviews also recommend changes to the locking text and I expect
to see updated text discussed on the WG mailing list prior to the document
going to the IESG. 

				regards,
					Ted Hardie

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 15 Jan 2007 17:24:09 -0800

WIth my WebDAV WG Chair hat on I would like to make a few comments.

On Jan 15, 2007, at 8:42 AM, Julian Reschke wrote:
... snip...
> (4a) One of the things RFC2518bis was supposed to fix was the  
> confusion around locking. Right now, it fails big time. For  
> instance, it fails to consistently distinguish between the "owner"  
> and the "creator" of a lock (issue 244), and is inconsistent with  
> respect to the term "lock root" (sometime it say it's a URI,  
> sometimes it says it's a resource; which is a significant  
> difference when a resourse is identified by multiple URIs) (issue  
> 251).
>
This was identified as an issues in WGLC and Ted as our AD has been  
working on it.

> (4b) Unnecessary new requirements: an example is the new (MUST- 
> level) requirement to submit a Depth header with PROPFIND (issue  
> 213). This is just one of several cases where the draft made  
> changes for no apparent reason; that is, there was no problem with  
> what RFC2518 said previously.

On the Feb  8, 2006 conference call, several people on the call came  
to agreement to, I quote
	"Agreed to add text to the document specifying that clients MUST  
include a Depth
	header in every PROPFIND request."
Since that point in time, the only email I have seen on this is that  
you have objected it and one other person sent a "+1" to few pages  
full of changes you were proposing that included removing this MUST  
among many others changes. I have no idea if that person was  
specifically supporting this change or not but for purposes of this,  
I will assume there were. Given the people on the call, and the fact  
that this text has been in the version 14 (published Feb 2006), 15,  
16, and 17 of the draft and I have only received objections from one  
or two people. I feel pretty comfortable saying there is WG consensus  
for the text as it.

My understanding of this issue is that you believe that this  
statement causes no harm but is unnecessary since for backwards  
compatibility reasons it is already specified what a server does for  
a request that does not have this header. My recollection of the  
conference call (and I admit my notes on this are not great) was that  
people argued that at some future point in time, one could decide for  
servers not to provide backwards compatible support for 2518 clients,  
and at that point the server could return an error and this would  
facilitate reduced bugs and improved diagnostics.

>
> (4c) Issue 237 raises a security issue that isn't discussed in  
> RFC2518, and I think it's quite important. As far as I can tell,  
> there's some sort of agreement that this really is a user agent  
> problem. That being said, all user agents expose this problem, and  
> the W3C WEBAPI working group was quite unresponsive when it was  
> mentioned. Thus, it seems to me that RFC2518bis *minimally* needs  
> to minimally mention the problem, making server implementors/admins  
> at least aware.

There was no working group consensus for changes to the draft related  
to this. We had two people post on the list about it. Julian said we  
should add some text explaining it, the other person said it was not  
specific to dav and we should not add text about it. As chair I can  
not claim there was any consensus to include this. The fact that only  
two people comment on a fundamental security issue with WebDAV is a  
testament to the amount of energy in the WG to review this document.  
Thank you for bringing this up in IETF LC, I think it is good that it  
has been brought to the attention of the Security ADs.

Cullen <with my WebDAV Chair hat on>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Jan 2007 13:46:25 +0100

> a successor aiming at Draft any time soon.

Well, I still think you aver over-estimating the amount of changes that 
were made. As far as I can tell, the spec mainly followed the rule of 
documenting what the widely deployed servers already did. Also, I do 
think that most of the "changes" are implemented in at least two 
different servers, and are compatible with existing clients, so it would 
have been possible to pass the criteria for "Draft" (except for lack of 
energy for addressing the administrative hurdle).

> been multiple attempts to use teleconferences etc. to move things forward as

Yes. I also highly recommend to look at the archive for 2006, during 
which last call comments were sent to the mailing list (and not addressed).

> is obviously true, but that has to be understood in the context of the WG's

Please also consider the questions "Do we want to publish a document 
that already has a long list of errata?" and "Can we do much better than 
that with little effort?".

> The locking issue was raised by Julian prior to last call to me and to Cullen as WG chair.

Repeated. It has been raised on this mailing list before.

> to see updated text discussed on the WG mailing list prior to the document

Thanks. It's good if these things are addressed, but keep in mind that I 
mentioned them in my feedback as *examples*, not as a complete list of 
thins that should be changed.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Jan 2007 14:06:31 +0100

Cullen Jennings schrieb:
> ...
>> (4b) Unnecessary new requirements: an example is the new (MUST-level) 
>> requirement to submit a Depth header with PROPFIND (issue 213). This 
>> is just one of several cases where the draft made changes for no 
>> apparent reason; that is, there was no problem with what RFC2518 said 
>> previously.
> 
> On the Feb  8, 2006 conference call, several people on the call came to 
> agreement to, I quote
> Since that point in time, the only email I have seen on this is that you 
> have objected it and one other person sent a "+1" to few pages full of 
> changes you were proposing that included removing this MUST among many 
> others changes. I have no idea if that person was specifically 
> supporting this change or not but for purposes of this, I will assume 
> there were. Given the people on the call, and the fact that this text 
> has been in the version 14 (published Feb 2006), 15, 16, and 17 of the 
> draft and I have only received objections from one or two people. I feel 
> pretty comfortable saying there is WG consensus for the text as it.

Cullen, I think this is an example of a process failure.

(1) I can't recall whether I objected during the call, or whether I just 
resigned in order to get to other topics. It was raised on the mailing 
list, and at least one person has agreed to that it's a problem. Nobody 
on the mailing list (AFAIR) has supported that change. So where's the 
consensus for it?

(2) In any case, this is a (needless) change to RFC2518, adding useless 
work for client implementors.

(3) Sorry, but this almost smells like a strategy. Push-back from the WG 
is ignored, and changes with no consensus are kept in subsequent drafts. 
Later on, the fact that the change has been in these drafts is being 
re-interpreted that there was some kind of support, when there wasn't.

> My understanding of this issue is that you believe that this statement 
> causes no harm but is unnecessary since for backwards compatibility 
> reasons it is already specified what a server does for a request that 
> does not have this header. My recollection of the conference call (and I 
> admit my notes on this are not great) was that people argued that at 
> some future point in time, one could decide for servers not to provide 
> backwards compatible support for 2518 clients, and at that point the 
> server could return an error and this would facilitate reduced bugs and 
> improved diagnostics.

I really have no idea why we would ever change the definition of the 
default. This seems to be a very theoretical argument.

Just to explain what we're talking about:

1) RFC2518 defines Depth 0, 1 and infinity for PROPFIND. The default (no 
header specified) is Depth: infinity.

2) In reality, many existing servers come configured to reject depth: 
infinity (including httpd/mod_dav), rejecting potentially expensive 
requests.

3) RFC2518bis therefore specifically mentions that clients should not 
rely on the ability to do depth: infinity PROPFINDs.

I think that at this point, we were done. We are documenting how the 
protocol works today, and there simply was no additional problem to 
address. Adding the new client requirement simply is pointless.

>> problem. That being said, all user agents expose this problem, and the 
>> W3C WEBAPI working group was quite unresponsive when it was mentioned. 
>> Thus, it seems to me that RFC2518bis *minimally* needs to minimally 
>> mention the problem, making server implementors/admins at least aware.
> 
> There was no working group consensus for changes to the draft related to 
> this. We had two people post on the list about it. Julian said we should 
> add some text explaining it, the other person said it was not specific 
> to dav and we should not add text about it. As chair I can not claim 
> there was any consensus to include this. The fact that only two people 
> comment on a fundamental security issue with WebDAV is a testament to 
> the amount of energy in the WG to review this document. Thank you for 
> bringing this up in IETF LC, I think it is good that it has been brought 
> to the attention of the Security ADs.

I am very nervous to publish a revision of RFC2518 with a known, very 
real security issue. Note that I do agree it's not specific to WebDAV 
from a theoretical point of view, but it is likely to occur in the 
context of collaborative authoring, and now what we have been made aware 
of it, it seems to me that it would be best to just document it.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jan 2007 12:43:47 -0800

Julian's draft has been around for a very long time and I think that  
you have suggested we just adopt it before so the WG certainly has  
been aware of this option. The bulk of this draft has been available  
to the WG for many months if not years and the WG did choose to use  
text out of parts of this draft.

The WG has almost no people in it at this point and very little  
energy to do any work. What you are proposing here is that  we could  
toss out the current work,  and start over with a new individual  
contributor document as the base document. At the peak of the WGs  
productivity, I would estimate this would take about two years not  
two months to get to WGLC. At the current rate of progress I would  
have to expect significantly longer.

Cullen <with my WebDav WG chair hat on>

On Jan 19, 2007, at 7:50 AM, Manfred Baedke wrote:

> This sounds very sensible to me.
>
> Regards,
> Manfred
>
> Geoffrey M Clemm wrote:
>>
>> First, my appreciation to everyone that has participated in the  
>> recent push
>> to produce a revision of RFC-2518.
>>
>> I have reviewed rfc2518bis-17, as well as the remaining issues in  
>> bugzilla
>> and the document:
>> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis- 
>> latest.html>
>>
>> I believe that a significantly better document could be produced  
>> within the
>> next 2 months, based on reschcke document.
>>
>> I would like to see action on the current bis document be deferred  
>> for
>> that period of time, with the explicit goal of giving the working  
>> group
>> an opportunity to evaluate and express a preference between the  
>> two alternatives.
>> We'll be living with the rfc2518bis document for a long time, so I  
>> believe
>> this extra two months would be time well spent.
>>
>> Cheers,
>> Geoff
>>
>> Julian wrote on 01/15/2007 11:42:50 AM:
>> >
>> > The IESG schrieb:
>> > > The IESG has received a request from the WWW Distributed  
>> Authoring
>> > and Versioning WG (webdav) to consider the following document:
>> > >
>> > At the time of this writing, there were over fifty issues opened
>> > against the specification (see <http://ietf.osafoundation.org:
>> > 8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-bis>). For many of
>> > them there were suggestions resolving the problems with spec-ready
>> > text (all mention some of them later on).
>> >
>> > ...
>> >
>> > For many of the open issues there *are* proposals how to resolve
>> > them. The recommended changes are recorded both in the issue  
>> tracker (<
>> > http://ietf.osafoundation.org:8080/bugzilla/buglist.cgi?
>> > product=WebDAV-RFC2518-bis>) and an experimental draft available  
>> at <
>> > file:///C:/projects/xml2rfc/draft-reschke-webdav-rfc2518bis- 
>> latest.html
>> > >. The latter does not resolve *all* open issues *yet*, mainly  
>> in an
>> > attempt to keep the differences to the Working Group's document  
>> to a
>> > manageable size.
>> >
>> > So I would appreciate if reviewers not only take a look at RFC2518
>> > and the Last Call draft, but also to the resources above.
>>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 19 Jan 2007 21:58:21 +0100

Cullen Jennings schrieb:
> 
> Julian's draft has been around for a very long time and I think that you 
> have suggested we just adopt it before so the WG certainly has been 
> aware of this option. The bulk of this draft has been available to the 
> WG for many months if not years and the WG did choose to use text out of 
> parts of this draft. 
> 
> The WG has almost no people in it at this point and very little energy 
> to do any work. What you are proposing here is that  we could toss out 
> the current work,  and start over with a new individual contributor 
> document as the base document. At the peak of the WGs productivity, I 
> would estimate this would take about two years not two months to get to 
> WGLC. At the current rate of progress I would have to expect 
> significantly longer. 
> 

Cullen,

the only reason why "my" draft doesn't contain resolutions for all 
(instead of many) open issues is that at some point of time, it didn't 
seem to matter anymore, as the proposals basically were ignored by you 
and the editor. Should this change, I could and would finish it.

BTW: it seems that you don't consider Geoff or Manfred to be part of the 
WG. I'd really like to understand how one could come to that point of 
view (I'll remind everybody that Geoff is one of the authors of many 
WebDAV RFCs, and that Manfred has offered a complete rewrite of the 
locking sections a few months ago).

Best regards,

Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 19 Jan 2007 22:03:57 +0100

Cullen,

I was tempted to finish that mail with "and thanks for the fish", in 
honor of Douglas Adams, but I resisted.

Anyway, please understand that I don't want to make your or Ted's life 
harder than it needs to be. I just feel that the document is not good. 
And I'm going to continue to say what I think even if there are three 
ADs on the other side.

I'd also *really* like to understand why it seems to me that some voices 
on the mailing list are taken more seriously than others, or, for that 
matter, why anonymous feedback during the IETF Last Call obviously is 
more seriously considered than all the feedback that *did* arrive on the 
mailing list.

So, again, thanks for the Sushi that I really enjoyed. Hopefully you'll 
consider my work on the IMPP-vcard draft as sort of payback.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 19 Jan 2007 22:15:01 +0100

> Cullen,

OK,

this was intended to be off-list. Sorry for that. Everybody please 
ignore everything, or at least the parts that don't parse.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 20 Jan 2007 12:03:29 -0800

I certainly consider Geoff and Manfred part of the WG.  I don't think  
any of these were ignored my Lisa or me, I've read everyone one of  
them several times. I think that for WG did not come to consensus to  
adopt these into the WG draft.

Cullen <with my webdav WG chair hat on>

On Jan 19, 2007, at 12:58 PM, Julian Reschke wrote:

> (instead of many) open issues is that at some point of time, it  
> didn't seem to matter anymore, as the proposals basically were  
> ignored by you and the editor. Should this change, I could and  
> would finish it.
>
> BTW: it seems that you don't consider Geoff or ManfreFrom [email-masked] Sat Jan 20 15:13:36 2007
From: Cullen Jennings <[email-masked]>
Date: Sat, 20 Jan 2007 12:03:29 -0800
To: Julian Reschke <[email-masked]>
Cc: Geoffrey M Clemm <[email-masked]>,
	Manfred Baedke <[email-masked]>, [email-masked],
	WebDav <[email-masked]>
Subject: Re: Last Call: draft-ietf-webdav-rfc2518bis (HTTP Extensions for
	Distributed Authoring - WebDAV) to Proposed Standard

I certainly consider Geoff and Manfred part of the WG.  I don't think  
any of these were ignored my Lisa or me, I've read everyone one of  
them several times. I think that for WG did not come to consensus to  
adopt these into the WG draft.

Cullen <with my webdav WG chair hat on>

On Jan 19, 2007, at 12:58 PM, Julian Reschke wrote:

> (instead of many) open issues is that at some point of time, it  
> didn't seem to matter anymore, as the proposals basically were  
> ignored by you and the editor. Should this change, I could and  
> would finish it.
>
> BTW: it seems that you don't consider Geoff or Manfred to be part  
> of the WG. I'd really like to understand how one could come to that  
> point of view (I'll remind everybody that Geoff is one of the  
> authors of many WebDAV RFCs, and that Manfred has offered a  
> complete rewrite of the locking sections a few months ago).
>

---



> complete rewrite of the locking sections a few months ago).

--Apple-Mail-12--109834736
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>I=A0certainly consider Geoff and =
Manfred part of the WG.=A0 I don't think any of these were ignored my =
Lisa or me, I've read everyone one of them several times. I think that =
for WG did not come to consensus to adopt these into the WG =
draft.=A0<DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Cullen &lt;with my webdav =
WG chair hat on&gt;</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR><DIV><DIV>On Jan 19, =
2007, at 12:58 PM, Julian Reschke wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; =
min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">the only reason why "my" draft doesn't contain resolutions =
for all (instead of many) open issues is that at some point of time, it =
didn't seem to matter anymore, as the proposals basically were ignored =
by you and the editor. Should this change, I could and would finish =
it.</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px =
Helvetica; min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">BTW: it seems that you don't consider Geoff or Manfred to be =
part of the WG. I'd really like to understand how one could come to that =
point of view (I'll remind everybody that Geoff is one of the authors of =
many WebDAV RFCs, and that Manfred has offered a complete rewrite of the =
locking sections a few months ago).</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-12--109834736--

--===============0629354877==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0629354877==--

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 20 Jan 2007 12:04:48 -0800

On Jan 19, 2007, at 1:03 PM, Julian Reschke wrote:

> Cullen,
>
> I was tempted to finish that mail with "and thanks for the fish",  
> in honor of Douglas Adams, but I resisted.

lol :-)

>
> Anyway, please understand that I don't want to make your or Ted's  
> life harder than it needs to be. I just feel that the document is  
> not good.

I know you are not trying to make anyones life hard and you are just  
trying to get this document to be right. I agree with you that the  
document has many problems and could be much better. I think that is  
important that you say it is not good if that is what you feel.  
However, I do think that it is better than rfc2518 and I am totally  
convinced given the last 18 months that this WG is not capable of  
making significant advances to this document. Perhaps I am just the  
wrong person and the folks in this WG are just too burned out  to  
drive more forward progress on this document. I hope someone does try  
to do something better than this draft, but given where we are today,  
I think we should publish this while waiting for the next thing.

> .
>
> I'd also *really* like to understand why it seems to me that some  
> voices on the mailing list are taken more seriously than others,  
> or, for that matter, why anonymous feedback during the IETF Last  
> Call obviously is more seriously considered than all the feedback  
> that *did* arrive on the mailing list.
>

The working group takes some people more seriously than others. For  
example, if you say "that will break several existing  
implementation," most people in the WG believe that much more than if  
I said it". That's good - you have much ore experience with the  
deployed system and it is typical for a WG to have some leaders that  
others look to for their advice and opinions. Ten seconds of looking  
at the archives will convince anyone that some people look to your  
opinion. I'm sure I can't count the number of "I agree with Julian"  
emails I have seen. However don't confuse that with what happens when  
trying to judge consensus - as a chair in trying to judge consensus,  
I do listen to everyone. The biggest problem in this WG is often so  
few people comment on [email-masked]> <[email-masked]>
From: Cullen Jennings <[email-masked]>
Date: Sat, 20 Jan 2007 12:04:48 -0800
To: Julian Reschke <[email-masked]>
Cc: [email-masked], WebDav <[email-masked]>
Subject: Re: Last Call: draft-ietf-webdav-rfc2518bis (HTTP Extensions for
	Distributed Authoring - WebDAV) to Proposed Standard

On Jan 19, 2007, at 1:03 PM, Julian Reschke wrote:

> Cullen,
>
> I was tempted to finish that mail with "and thanks for the fish",  
> in honor of Douglas Adams, but I resisted.

lol :-)

>
> Anyway, please understand that I don't want to make your or Ted's  
> life harder than it needs to be. I just feel that the document is  
> not good.

I know you are not trying to make anyones life hard and you are just  
trying to get this document to be right. I agree with you that the  
document has many problems and could be much better. I think that is  
important that you say it is not good if that is what you feel.  
However, I do think that it is better than rfc2518 and I am totally  
convinced given the last 18 months that this WG is not capable of  
making significant advances to this document. Perhaps I am just the  
wrong person and the folks in this WG are just too burned out  to  
drive more forward progress on this document. I hope someone does try  
to do something better than this draft, but given where we are today,  
I think we should publish this while waiting for the next thing.

> .
>
> I'd also *really* like to understand why it seems to me that some  
> voices on the mailing list are taken more seriously than others,  
> or, for that matter, why anonymous feedback during the IETF Last  
> Call obviously is more seriously considered than all the feedback  
> that *did* arrive on the mailing list.
>

The working group takes some people more seriously than others. For  
example, if you say "that will break several existing  
implementation," most people in the WG believe that much more than if  
I said it". That's good - you have much ore experience with the  
deployed system and it is typical for a WG to have some leaders that  
others look to for their advice and opinions. Ten seconds of looking  
at the archives will convince anyone that some people look to your  
opinion. I'm sure I can't count the number of "I agree with Julian"  
emails I have seen. However don't confuse that with what happens when  
trying to judge consensus - as a chair in trying to judge consensus,  
I do listen to everyone. The biggest problem in this WG is often so  
few people comment on anything that even if they all agree it's such  
a small fraction of the WG that it is hard to call it consensus.

> So, again, thanks for the Sushi that I really enjoyed. Hopefully  
> you'll consider my work on the IMPP-vcard draft as sort of payback.

I'm very thankful for the work you did on IMPP-vcard. It was  
something that I was never going to mange to finish. Likewise, don't  
take the lack of ability to come to agreement  on a much better  
version of 2518bis to be reflective of everything that is happening  
at IETF. This is basically the problem of a WG with so few people  
willing to even review comments and it's too small to really  
effectively function as a WG. You have a ton of expertise in XML,  
DAV, schema and lots of other things that IETF is doing active work  
in. Come to Prague and meet the people working on them and check out  
some of the more vibrant and less frustrating work the Wbdav.

ng that even if they all agree it's such  
a small fraction of the WG that it is hard to call it consensus.

> So, again, thanks for the Sushi that I really enjoyed. Hopefully  
> you'll consider my work on the IMPP-vcard draft as sort of payback.

I'm very thankful for the work you did on IMPP-vcard. It was  
something that I was never going to mange to finish. Likewise, don't  
take the lack of ability to come to agreement  on a much better  
version of 2518bis to be reflective of everything that is happening  
at IETF. This is basically the problem of a WG with so few people  
willing to even review comments and it's too small to really  
effectively function as a WG. You have a ton of expertise in XML,  
DAV, schema and lots of other things that IETF is doing active work  
in. Come to Prague and meet the people working on them and check out  
some of the more vibrant and less frustrating work the Wbdav.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 18 Jan 2007 19:12:55 -0500

First, my appreciation to everyone that has participated in the recent 
push
to produce a revision of RFC-2518. 

I have reviewed rfc2518bis-17, as well as the remaining issues in bugzilla
and the document:
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html>

I believe that a significantly better document could be produced within 
the 
next 2 months, based on reschcke document.

I would like to see action on the current bis document be deferred for
that period of time, with the explicit goal of giving the working group
an opportunity to evaluate and express a preference between the two 
alternatives.
We'll be living with the rfc2518bis document for a long time, so I believe
this extra two months would be time well spent.

Cheers,
Geoff

Julian wrote on 01/15/2007 11:42:50 AM:
> 
> The IESG schrieb:
> > The IESG has received a request from the WWW Distributed Authoring
> them. The recommended changes are recorded both in the issue tracker (<
> product=WebDAV-RFC2518-bis>) and an experimental draft available at <
> file:///C:/projects/xml2rfc/draft-reschke-webdav-rfc2518bis-latest.html
> >. The latter does not resolve *all* open issues *yet*, mainly in an
> attempt to keep the differences to the Working Group's document to a
> manageable size.
>

---

From: Manfred Baedke <[email-masked]>
Date: Fri, 19 Jan 2007 16:50:58 +0100

Regards,
Manfred