ietf
[Top] [All Lists]

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

2007-02-21 06:23:23
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 intentional.

Proposed Change (see also <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=258> and <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz258>):

+++
Section 14.24., para. 4:
OLD:

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

NEW:

    <!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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf