Joel, Thanks for your note.
On Wed, Jul 8, 2026 at 3:41 PM Joel Halpern <[email protected]> wrote: > I think the two problems EKR describes are different and separable. > > The first problem, somehow providing an umbrella that actually makes it is > easy to figure out what all the pieces of protocol X (SMTP, HTTP, BGP,...) > are is a useful result. It is however one that we have failed on multiple > times, for multiple reasons (some good, some in my opinion bad, but > multiple efforts and multiple failures.) > > On the other hand, being able to easily update RFCs, with the kind of > distinction EKR describes below, far more easily than we currently can > seems like a good idea. As Jay suggests, some of the errata handlign > moves the ball a little on this front. I think we can do more, and be > careful to make sure we keep the requirements for consensus clear. > > While I can imagine interaction between those two, it is not all obvious > that such interaction is necessary. Admittedly this is in part because I > think there are good reasons to sometimes keep document separate but > related, so the umbrella need is not always addressed by revising the base > document. Guessin which of the two will turn otu to be easier is beyond my > crystal ball. I am however confident that tying them together will be > harder. > I agree with you that they are separable. The way they got glued together in my head was that I want some reference that gets me to (say) the current version of HTTP. But I think if that was just one document, then that work OK, especially if, as you suggest, we made the processes for updating easier, so that if you had something which naturally fit in the "important parts" spec, you could do that with a revision, rather than doing a new spec just because it was easier. If we just did those things, I think we would have made a lot of progress. -Ekr > Yours, > > Joel > On 7/8/2026 5:40 PM, Eric Rescorla wrote: > > > > On Wed, Jul 8, 2026 at 1:46 PM John R Levine <[email protected]> > <[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]
