Just sent out a longer mail and then read yours. Just wanted to quickly add that I agree on all what you wrote below. That's exactly the point. The disagreement is when to use or when it should not be used and people have quite strong opinions on both that don’t align. I think the only way forward to address both views (when it should be used and when it should not be used), is to have more than one tag. Further, as you say, I think there is some values for the reader as it provides a structured indication, rather then just free text but it might not fully replace such text either. However, that’s not the main problem to solve.
> On 6. Jul 2026, at 11:40, Brian Rosen <[email protected]> > wrote: > > We have historically used Obsoletes when the new RFC has a complete text so > the document stands alone. If we make a change that is mandatory to > implement for some reason, and the new document doesn’t provide complete > text, but just the change, then we have historically used Updates. But we > also sometimes use Updates when we add a new, totally optional feature. We > need to differentiate between a document that must be considered before > implementing and a document that might be useful before implementing. > Amends says, “you must pay attention”. “Extends” says “might be > interesting”. “Updates” doesn’t say. If you write a piece of text in the > abstract or intro that says what it does, then the tag doesn’t matter - you > have to read the text. The tag might as well be “Note”. > > If we end up with the idea that Updates requires text to say what Updates are > made, does a doc that extends but does not amend need Updates? That’s the > confusion: how much of a change requires Updates? The current dilemma isn’t > what is Updated, it’s where is the threshold between no tag and the Updates > tag? > > Brian > >> On Jul 6, 2026, at 8:59 AM, Brian E Carpenter <[email protected]> >> wrote: >> >> 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] > > -- > 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]
