On Fri, 02 Jan 2004 19:38:34 +0100, Julian Reschke said:
Not at all. IMHO the situation is as follows: RFC2396 completely
replaces all previous definitions of URI syntax and resolution
(including the syntax for relative URI references).
However, previous documents *also* contained definitions of particular
schemes which were not included in RFC2396, thus it doesn't obsolete
these documents. Nevertheless, RFC2396 can be read without reading the
previous documents (unless you happen for instance to be interested in
the "ftp" URI scheme).
OK.. I'm obviously caffeine-deficient today. ;)
I see what you mean now, I had it 100% backwards. ;) And yes, there's a buglet
in the wording, but I'm not sure how to fix it for what is probably a special
case. I'm pretty sure that it's relatively rare for an updating RFC to do a
wholesale clean replacement of one section in such a way that the new RFC
updates the old but still stands on its own. Much more common are the cases
like 3445 (updating 2535) or 3442 (updating 2132), where it *really* can't
stand on its own.
As far as I can tell, the text in 2223bis-07 is only inaccurate in the rare
case where the base document is an aggregation of several registration-type
definitions, as is the case for 1808 (or rfc2046 for MIME types), and the
proper classification for the base *would* have been 'obsoletes' if the one
section had been published on its own. So for instance, RFC2112 was able to
obsolete 1872 (Multipart/Related), and was itself obsoleted by 2387 - but doing
the same for multipart/mixed isn't feasible without either:
a) Doing a full rev of 2046 that 'obsoletes 2046'.
b) Live with the fact that the 2223bis wording says that the new definition
depends on 2046 when it really doesn't.
Are there really enough documents like 1808 or 2046 for it to matter?
And if so, do you have any good verbiage to recommend that will in fact make
things cleared, rather than making it murkier due to special-casing?
pgp7tLabHluWC.pgp
Description: PGP signature