Eliot,
On 06-Jul-26 19:18, Eliot Lear wrote:
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.
I draw the opposite conclusion. The fact that it's hard to get it right is
exactly why we *should* get it right, because otherwise we are leaving the
readers in a state of confusion.
> * 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.
Well, that's exactly the problem. If an "Updates:" RFC makes REQUIRED [BCP14] changes to
the protocol, implementers must obey. Now, you could argue that this should be addressed by an
"Obsoletes:" RFC, but I suspect that would mean we've done it wrong a few hundred times.
(RFC2026 is an example, and we're now playing catch-up with RFC2026bis.) This is exactly why there
is a difference between Extends and Amends/Changes/Corrects/Fixes.
"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.
True. But in many cases it also implies that the old RFC was wrong, or at least
contained an ambiguity that affects interoperability.
[But hey, this really seems like a standards process discussion to me.]
Brian
> * 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
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
