Hi Eliot, Yes, I think there is relatively broad agreement that updates covers this first case. However, there is disagreement if it (must) covers only this case or if it is/should be broader. Clearly it has been used more broadly. That's why we propose a new keyword to cover the agreed case (only) and other key words for everything else that people want to use updates for or have done so in the past and avoid updates entirely in future.
Suresh did manually review RFCs 8000 to 8500 for use of “updates” at some point and to put them into the three proposed new tag categories and this was the outcome: Updating RFCs 95 Updated RFCs 163 Amending 59 Extending 50 See Also 4 See further below. > On 6. Jul 2026, at 15:48, Eliot Lear <[email protected]> wrote: > > Mirja, > > I want to respond to this paragraph, since it squarely hits the heart of the > matter: > > On 06.07.2026 12:06, Mirja Kuehlewind (IETF) wrote: >> 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); > It should be clear in the intro front what has changed, but not necessarily > how (that could get lengthy). This to me is Updates. > > > >> 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. > I mentioned SMTP as an example to Michael. How would you handle the > forthcoming RFC that obsoletes 5321? Do the existing extensions extend? > What happens when that list gets long? Is it still useful? > The question also applies today as updates is already used for extensions: I guess, if you create a new revision of a draft, you can reference all existing, valid extensions directly, rather than using a backward reference. I guess that's the way to go… But happy to discuss this further or add something to the draft. > Eliot > > <OpenPGP_0x87B66B46D9D27A33.asc>-- > 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]
