Hi all, Good to see that there is interest in working on this problem. However, as the discussion already shows, in all previous discussion it was hard to find consensus so far. But I hope having this group now would help us to find consensus eventually, so we thought to give it another (last) try. Please keep the past discussion and history in mind for future discussion.
To the point: I’m making a top level posting to address multiple, already raised high level points rather than providing comments to concrete discussions below in order to provide some perspective on how we got to this proposals. Initially when we started this work (about 7 years ago when I was still on the IESG), we wanted to actually “simply” provide a definition for “updates", as not having one creates over and over the same discussion in the IESG and community and probably also leads to some confusion to the reader (however, we have never fully assess the reader point of view). However during this discussion it became very clear that there is no chance to come to a common agreement about the meaning of the updates tag. Effectively the only thing we can say for sure is that it provides a way to add reference in the header metadata from an existing RFC to a new RFC. However, there are also a lot of people who have very strong opinions about how “updates” should and should not be used, have been following their own rules, and are not willing to change them. This reaches from the point of view where some think that adding “updates” makes something actually mandatory to implement, while others really use this loosely as a reference. To quickly come back to a point in Brian’s first mail: This is also the reason why we propose to use “extends” instead of keep using “updates”. At some point in the discussion, we came to the conclusion that is it better/easier to simply not use “updates” at all only more. However, stepping back and let’s discuss the problem we want to solve. As raised by Ekr, we wouldn’t have this problem if we would have some kind of “living” documents, however, that’s not where we are and I don’t think it will be easier or faster to actually find consensus for a solution to this problem. Some people also said basically that we shouldn’t use “updates” and rather always do a full spec revision. I’m not necessarily disagreeing with that but the truth is that will not happen. I have been myself arguing that we shouldn’t touch a large spec and rev it as it would take too long and rather do a small update in a separate doc. I think if we would take away that option, many protocols would simply not be maintained. So the problem we would like to solve is to provide a clear definition for the today used practices. During previous discussion it has become clear that there are at least two well defined use cases for “updates”: one is the kind of OLD/NEW style document or similar (it doesn’t have to be OLD/NEW but something that clearly indicates that some text is changed); the other one is the use for extension utilising existing extension points. Plus, as it also came up in this discussion, there are strong opinions that “updates” should or should not be used of the second case. Therefore we thought that clearly defining these two cases and separating them could be a way forward. Then we also added the “see also” tag as a catch-all for the all remaining cases; this tag of course has the same problem as the current updates tag in that its use cases are not clearly defined but at least it is written down that this is on purpose and that is effectively only provides a references and no other “guarantees”. However, if it turns out that this is not useful, it will simply not be used, so I don’t think there is strong harm in defining it. The question came up if that actually helps the reader or creates more confusion. I think currently we do have the problem that there is a mismatch. Some people apply the “updates” tag with certain exceptions (including that it is mandatory to implement), however, this is not understood by the reader. I don’t think any new solution can be more confusing than where we are now, where we don't have a definition. Also, I personally not sure that having a definition that just covers all current uses would help, as “updates" has been used very inconsistently so far. But even if we define two or three new tags and these are not equally well understand by the reader, I don’t think that is a real problem as implementors anyway implement in the end what they need for their use case. Often even one RFC might not be fully implemented. Adding these new tags doesn’t take away the need of an implementor to look at all RFCs and make a decisions. But maybe it helps a bit to make that decision. Also, adding tags does not change any compliance requirements; implementing one RFC means implementing that RFC only. I think that’s also what the draft says. However, it would make it easier to formulate a requirement where I want a product that implements RFC X and also all RFCs that “amend” it. And, yes, interoperability problems can happen, but that’s also true today (no matter if “updates” is used or not). And also “amends” and “extends” to not indicate different importance or something like that as it was implied at least by Ekr I think; these are simply different use cases and at the end every implementor has to make their own decisions which RFCs or parts of RFCs they implement for their one use case. However, there is a difference between a chance in spec or the use of an extension that has a negotiation mechanism and “fallback” and making this difference clear seems really useful to me, especially when considering interoperability requirements. If people, think there is a way forward to find and agree to a definition for “updates” that would for sure be another way forward, but I personally don’t think we would be able to reach consensus and therefore I wouldn’t want to edit such a draft. If someone else wants to start another draft, please do! Mirja > On 6. Jul 2026, at 09:57, 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]
