On Jul 8, 2026, at 14:40, Eric Rescorla <[email protected]> wrote: > 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?
That this topic needed a new subject line. > -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]
