Hi Michael On 05.07.2026 22:24, 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.
I would only agree with that statement if we were the only audience for RFCs. I would hope that we all believe that's not the case.
2. Since it's hardly being used so far, how could anyone else ever know at
this point?
I presume you mean "Amends". Update's been used 1280 times, according to my simple grep. That's a little over 10% of the corpus.
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.
That it wasn't easy to get right for the authors is at least a hint that the readers will suffer confusion. So I'm curious as to what challenges you had.
> * 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.
We have never said the following:
The goal of this tag pair is to signal to anyone looking to implement the amended RFC that they MUST also implement the amending RFC.
And that is what causes the conformance confusion. And it's violating a longstanding principle of our series- that once a specification is published, it does not change, modulo errata. Here we are in effect saying the opposite.
"Updates" has the expectation that if you want to be interoperable with the old RFC, you test against the old RFC, and if you want to be interoperable with the update, then you must test against the update as applied to the old RFC.
> * 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.
If it's valid to not implement 9914, then the language in this draft is wrong, and therefore you may have already introduced interoperability challenges for those implementing either 6550 or 9914. If Amends is intended to be what I think we agree Updates should have been, let's just make Updates that ;-)
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.
I don't think extends would add a whole lot of clarity over time. Let's look at three cases:
* TCP port number assignments clearly are not intended to add new operations to TCP; they're just a means of identifying payload. The same could be said for the media-types registry. So extends isn't needed in this case. * SCIM schema are clearly intended to extend the functionality of service. At the moment there are few such extensions, but I expect that to change – rapidly– over time. Moreover, they only have "specification required" as a policy. Does that require extends? * SMTP is a goodie. Do we really need to indicate in the meta-data that extends SMTP some 25 times? An interesting side-effect in this case is that when the new RFC comes out, it would have been extended by old RFCs. How's that for a head twister?At the end of the day, if we need to clarify Updates: I'm totally okay with that, and am willing to either work with this group to provide some text. But I don't think such an update should be limited to "Updates". We have some other issues with "Historic" and "Obsoletes" that should be hammered out as well, when crossing streams (when it happens, it does indeed feel a little like Ghostbusters).
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]
