Draft -16 out now

Cullen Jennings schrieb:
>> Well, no. Before, the specification allowed *any*
kind of secure 
>> connection, and listed TLS and a network with
restricted access as 
>> *examples*. This is why we didn't need a normative
reference to TLS 
>> after all.
>>
>> Now, Basic Auth MUST use TLS, which is a new
requirement, that 
>> definitively hasn't been discussed here before.
>>
>> Personally, I would propose not to mess with this
section unless 
>> there's something clearly wrong with it.
> 
> Ok - I see your point. At this point, my primary goal
is getting a 
> document that is better than RFC 2518 off to the IESG.
So I'm proposing 
> that I ask Lisa to replace the text with the flowing
and I will provide 
> an explanation of why this text below.
> 
>   A password sent in the clear over an insecure channel
>   is an inadequate means for protecting the
accessibility
>   and integrity of a resource as the password may be
>   intercepted. Since Basic authentication for HTTP/1.1
>   performs essentially clear text transmission of a
>   password, Basic authentication MUST NOT be used to
>   authenticate a WebDAV client to a server unless the
>   connection is secure. Furthermore, a WebDAV server
>   MUST NOT send a Basic authentication challenge in
>   a WWW-Authenticate header unless the connection
>   is secure. An examples of a secure connections
>   would be a Transport Layer Security (TLS) connection
>   employing a strong cipher suite and server
authentication.
> 
> This text is some cut and pasted of what was in 15. I
changed the 
> "credential" to "challenge" as that
seemed to be a bug in the text. I 

Good.

> removed the "mutual" authentication because
in TLS, "mutual" means that 
> the client would require a certificate and is not what
is needed or what 
> I think the WG meant here. (Classic HTTPS connections
are not "mutual" 
> in the TLS sense of the word). I removed the isolated
building example 

Good.

> because there is no way for a webdav client or server
to detect that it 
> is running in an environment such as this. I left the
text open so that 

I'm not entirely happy with that, but it guess that if a
server is 
running in an isolated environment, it's not on the Internet
so 
compliance to the spec isn't really important.

> TLS is only one possible example and other examples of
secure networks 
> are also allowed - SASL upgrade approaches come to
mind. I would not be 
> surprised to see this text get some comments in IETF
last call but if it 
> represents rough consensus in this WG, I would be glad
to request 
> publication.
> 
> Could everyone in the WG let me know if you could live
with this really 
> soon and I will ask Lisa to make this change.

I'm happy with this change, but I don't think the spec is
ready at all. 
We have tons of open issues, many of them being raised in WG
last call, 
some later, and also lots of editorial problems as well. See

<http://ietf.osafoun
dation.org:8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-
bis&bug_status=NEW&bug_status=ASSIGNED&bug_statu
s=REOPENED> 
which currently list 35 open bugs.

For many of them, there are proposed fixes in 
<http://greenbytes.de/tech/webda
v/draft-reschke-webdav-rfc2518bis-latest.html>. 
If we *finally* get back to work, we should start addressing
those.

As an example, have a look at 
<http://ietf.osafoundation.org:8080/bugzilla/
show_bug.cgi?id=227>. This 
problem has been raised in February, there's a consensus how
to resolve 
it, but it doesn't show up in draft 14, 15 or 16. I hope
this explains 
why I'm so unhappy with how the draft has been developed in
the previous 
months.

Best regards, Julian

For some reason, I am only seeing Julian's replies to
Cullen; this reply
is really to Cullen, but applies to the whole thread.
At 11:29 AM +0100 11/28/06, Julian Reschke wrote:
>Cullen Jennings schrieb:
>>
>>Ok - I see your point. At this point, my primary
goal is getting a document that is better than RFC 2518 off
to the IESG.

I'm glad that this issue seems to have been so quickly
resolved, and I hope others
can comment about whether the new text is okay.  But I think
folks should really
be narrowing focus at this point.  This effort has been
around for a long time, and
we agreed nearly a year ago to get this document through the
last hump and out
the door.  The chair and document author both getting put on
the IESG at the
same time pulled critical energy from the group during what
should have been
its final clean-up.   Since that point, we have had only
occasional bursts of energy,
and some of that has focused on areas that were not truly
core to the work
(like the WEBDAV capabilities in HTML thread Jim
raised--these are interesting,
but not chartered work).

I believe that we have had strong consensus for a long time
to replace RFC 2518,
and I think the focus at this point has to narrow to places
where the current document
isn't as clear as 2518.  Given the traffic since the WGLC on
-14 back in February,
I just don't see the energy to take on more at this point. 
I think putting the document
in front of the larger community and acknowledging that it
isn't  perfect but
is a needed improvement is the way to go.

If the group cannot do that in a short period of time, I
would have to seriously
consider closing it.  The amount of energy here would
clearly not justify a new
working group; this one has continued despite that
participation level partially
because of continuity and partly because of the issues in
2518.  I am not sure,
however, that there is enough energy to survive another AD
transition, and
handing off to a new AD is March is a certainty.

I encourage everyone to focus on the highest priority items
*only* at this point
and to keep in mind that not getting this out means 2518
stays as the standard
for this.  I do not think that is anyone's interest at this
point.
				regards,
					Ted Hardie