On Wed, Jul 8, 2026 at 1:46 PM John R Levine <[email protected]> wrote:
> >> I largely agree, and think this is worth a LOT of time exploring. > > > > But as John Klensin may well remind us, this is a very long-standing > > problem that the IETF side of the house has failed to tackle for the > > last 25 years or so. It will take something amounting to a revolution > > to make significant changes. > > Oh, I know, starting with the question about whether immutable RFCs is a > sacred principle, or just a leftover from the era when they were > mimeographed. I wonder if there is an opportunity to sidestep this question at least temporarily by focusing on principles and then later trying to map them onto the RFC series. My starting point here would be something like: - We want a single reference that somehow points to the collective set of information that you need to implement a protocol. The target of the reference needs to evolve as the protocol evolves. - The important (main?) pieces of the protocol should be specified in a single coherent document. This may include things that are formally extensions but really are needed. For example, in TLS you might want to pull in SNI, because it's needed almost all the time. This may change over time; for instance a new algorithm might be added as an optional extension but then become dominant and so be moved into the main document. I'm not quite sure where exactly to draw the line here, hence the handwaving above. - It should be easy to update documents for comparatively minor changes. In a previous message, I provided a taxonomy of updating, so I don't want to go into it again here, but perhaps it would be easiest to think in terms of timelines and effort levels. For example, fixing an obvious typo should be very easy and shouldn't take more than a day or two. Non-semantic clarifications might take a little longer, semantic changes would need something more like the IETF Consensus process, etc. [0] I'm not trying to hide the ball: I think the right way to handle this is with dot revisions of RFCs (e.g., RFC XXXXX.VV), but you could also handle this with some construct that sat on top (SPEC 1234, which points to an RFC or a set of RFCs). But as I said above, perhaps we can defer that debate and see if we can agree on some principles at the level of the above--though most likely not exactly these--and then use that to work through the mechanics. What do people think? -Ekr [0] As I've mentioned previously, if we make it technically easy to make updates, then this lowers the risk of an inappropriate update sneaking through, as we can reverse it.
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
