I read this note twice, and then went and reread the draft.
As far as I can tell, the "amends" tag is trying to do something that the updates tag does not do today. There is a way to say that efforts to implement X MUST implement Y. That is not by "Updates". It is by "Obsoletes." I grant that writing the full draft Y to obsolete X is a pain. But having a set of draft that say if you do X, you must do Y, and if you do Y, you must do Z, is simply a minefield asking folks to get it wrong. This may be an argument forr some cleaner way to produce a revision to an RFC. But I would really prefer we not make the tags such a mess that we invite trouble.
Note: I can believe we have sometimes abused "updates" when we should have done a revision. That doesn't make it right. And very much does not make it something I think we should do as a matter of course. (I think I had missed this because I simply did not believe we inte4nded it. But Michael was quite clear that he intended it. Clarity is good.)
If we want to put out an RFC that says "no, Updates does not mean that, too bad", I cna live with that. If we want to clarify when updates is needed vs when just adding a registry entry is needed, I can live with that.
Yours, Joel On 7/5/2026 4:24 PM, Michael Richardson wrote:
Eliot Lear <[email protected]> wrote: > &TL;DR; the cure will cause interoperability problems. I strongly disagree. "Updates FOO" is essentially meaningless today. The most useful thing that it does today is insert meta-data against the previous document that provides for "Updated by XYZ". > * 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. 1. It's actually enough that *WE* understand the distinction. 2. Since it's hardly being used so far, how could anyone else ever know at this point? 3. RFC9914 uses both Extends and Amends, and I think we did it correctly. Was it easy to get right? No, but it made us think about which parts were which, how we would get around changes to base behaviour. > * 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. If I write an Update that is a mandatory to use _Amends_ , I create the same confusion/non-interoperability. Except without the term to clarify. That can happen today, and we don't have a term for it. At least, we could have a way to talk about this. > * 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. Yes, sometimes that is true. What about it? RFC9914 definitely Amends RF6550, but there is no way I'm revising a 157 page document, particularly since it's still completely valid to not implement 9914. There *could* be alternative ways to do the work that Extends based upon a pre-existing IANA Registry, rather than Amends. WG definitely need to consider that, as you suggest. > * 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. If you understood that, then the document did a poor job. Extends means: we used the IANA Considerations to add this new thing. Sometimes, there wasn't a registry, and that was in fact the mistake that is first Amended ("Add registry"), and then Extended using the registry. > I would not deny that there are inconsistencies with Updates. Let's just fix > that. I await an alternative proposal to fix that :-) I haven't seen anything yet. > 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. Yes, and ADs ask for such things regularily. Then complain that the explanation of "how" was inconsistent and confusing. So... use terms like Amends and Extends in that section. For example: https://www.rfc-editor.org/rfc/rfc9914.html#name-extending-and-amending-exis > Are we still so inconsistent in Updates' use? Yes. An RFC that uses existing IANA Considerations to allocate a code point for some new use ("Extends"), should probably *NOT* Update the base specification, unless the new thing is operationally mandatory. Whether or not it does do is not consistent at all. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours **
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
