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?
Attachment:
pgp00393.pgp
Description: PGP signature