&TL;DR; the cure will cause interoperability problems.
I appreciate the attempt to clarify semantics, but I don't think this document is a good starting point for the following reasons:
* Nobody outside our little lot is going to understand the differences between extends and amends, so this will just add confusion to the reader. The scariest version of this would be use of any two or even three of these tags. * If they actually understand Amends, the result will be conformance chaos. People claim conformance to and interoperability with, a specification (e.g., an RFC). You cannot retroactively determine that they no longer claim compliance with that spec through some other spec. Either they do or they don't. * Amends seems to invite backward incompatibility and interoperability failure. With so many decades of experience, that should be done sparingly and with great consideration. When it happens, the best approach is create a new spec and obsolete the old one. * Extends seems to attempt to obviate appropriate use of code point registries and IANA, inviting sloppy specifications, knowing that "we can just Extend it later". If appropriate use of code points is used, Extends is not needed.I would not deny that there are inconsistencies with Updates. Let's just fix that. In fact, I thought Barry Leiba had created a best practice for that by saying that when you Update a specification you have to say how you update it in the front matter. Are we still so inconsistent in Updates' use?
Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
