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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf