We are VERY inconsistent on Updates.  Some, including me, believe Updates 
changes something about the prior work. Others believe that it informs readers 
that there is prior relevant work. The example is a simple extension. The 
extension adds capability, does not change anything to the updated RFC.  So 
does the document that describes the function extension Update or not?  I have 
a draft that presents this very issue. One chair believes that Updates is 
needed. I, and the relevant AD do not. We should not be in this situation.   I 
think an Extends label is precisely what it needed, and some label should be 
used  in a draft that makes some actual change.  Amends works for me.   

Brian

> On Jul 4, 2026, at 9:43 AM, Eliot Lear <[email protected]> wrote:
> 
> &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>
> --
> rswg mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
-- 
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to