W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2007

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 21 Feb 2007 14:22:07 +0100
Message-ID: <45DC477F.40607@gmx.de>
To: Cullen Jennings <fluffy@cisco.com>
CC: ietf@ietf.org, WebDAV <w3c-dist-auth@w3.org>

Cullen Jennings schrieb:
> On Jan 22, 2007, at 4:49 AM, Julian Reschke wrote:
>> Hi,
>> RFC2518bis updates parts of RFC3253 (DAV:error below DAV:response) in an
>> incompatible way, and thus should note it in the front matter 
>> ("Updates: 3253") and mention it as a change near the Changes Appendix.
>> (see <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=258>)
>> Best regards, Julian
> Sent with my behave chair hat on ...
> This is always a complicated problem of does an update document update 
> the documents that depend on the drafts it's updates. An extreme example 
> is should TLS 1.2 update every document that uses TLS 1.0. It's pretty 
> unwieldy to take that path so I I think a better path is that 3253 
> depends on 2518 and when we update 3253, then it will be changed to 
> depend on the RFC that comes out of the 2518bis draft.

Well, right now RFC3253 doesn't indicate that it updates RFC2518. For 
that matter, nor does RFC2518 indicate that it updates RFC2068, or 
draft-RFC2518bis that it updates RFC2616 (one could argue it should 
because it updates the set of methods, headers, and status codes).

Generally, the linkage using "obsoletes" and "updates" is really 
restricted and doesn't work well, except for simple cases such as 
"RFC2616 obsoletes RFC2068".

> The WG definitely considered the impact of the incompatibilities here 
> and decided that this was an acceptable path - the only question we are 
> trying to sort out here is if the id tracker shows this an up update on 
> 3253 or not.

That's not the only question. The other question is whether it's wise to 
make an incompatible change and not to mention that at all. I strongly 
suggest we at least make it clear that this is a change, and that it was 

Proposed Change (see also 
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=258> and 

Section 14.24., para. 4:

     <!ELEMENT response (href, ((href*, status)|(propstat+)),
                         error?, responsedescription? , location?) >


     <!ELEMENT response (href, ((href*, status)|(propstat+)),
                         error?, responsedescription?, location?) >

        Note: the usage of the 'error' element inside 'response' is an
        incompatible change to [RFC3253], Section 1.6, paragraph 2 (where
        'error' appeared as a child element of 'responsedescription').


Best regards, Julian
Received on Wednesday, 21 February 2007 13:22:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC