As far as I can tell, this discussion has made a very good case for
needing a better way to produce revisions of RFCs. I am not confident
I know what the constraints and properties of a solution are. I do now
understand that saying "what we have works" is counter-factual.
Yours,
Joel
On 7/7/2026 9:54 PM, Eric Rescorla wrote:
On Tue, Jul 7, 2026 at 6:36 PM John Levine <[email protected]> wrote:
It appears that Martin Thomson <[email protected]> said:
>Pulling back to Brian's email, because the discussion has
wandered off.
>
>I reach a different conclusion. It's not really broken as it is.
I'd draw a different conclusion. We really need a better way to
update our
standards.
Unsurprisingly, I agree with this.
Other SDOs manage to publish updated editions of their standards
with a process
to add or change parts of them without having to reissue the whole
thing.
Here is a potentially nonexclusive list of cases, in rough order from
smallest to biggest:
- Editorial (non-semantic) changes (typos, rewrites, etc.)
- Clarifications that are theoretically semantic (e.g., fixing things
where
everyone agrees what the the spec should say but it doesn't
say it or it's unclear).
- Isolated semantic changes (e.g., forbidding algorithms, adding
new algorithms, etc.)
- Significant extensions (something like TLS ECH)
- Total rewrites
One important question is how high in this ladder we can go
while maintaining a single document. My personal inclination
is pretty high, up to and including some extensions, but I
imagine others will have different beliefs.
-Ekr
I realize this is a bigger discussion than whether to put Updates:
or Amends: in
the XML header, but I think it's a real problem we've been
avoiding for a very
long time.
R's,
John
--
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]
