Are others interested? We can do it virtual if that's more convenient.
Eliot On 18.05.2026 16:39, Eric Rescorla wrote:
On Mon, May 18, 2026 at 7:21 AM Eliot Lear <[email protected]> wrote: On 18.05.2026 14:42, Eric Rescorla wrote:As I said, i don't think this is addressing the primary problems with mapping specifications onto RFCs, which are much more about the ability to progressively revise than imposing some sort of meta-structure.I'd like to see us focus on that ability to progressively revise specifications. Is that something we might want to grab a room to discuss in Vienna? I'm thinking about the following: I won't be in Vienna, but might be able to call in. * What are the process limits? * What are the tooling limits? * Are the requirements of all levels of the stack the same? * Related, what are the necessary interoperability requirements? I think there are actually a number of related issues: - Non-semantic changes (editorial issues, errata, etc.)?- Semantic changes that aren't really new versions (e.g., RFC 8446-bis, which is largely a clarification of 8446, but does in fact contain new normative text)?- New versionsMy put for non-semantic changes is: https://datatracker.ietf.org/doc/draft-rescorla-rfc-jit/. I suspect we'd need different processes for the other two.-Ekr What I would like NOT to do would be to create the IETF version of the NPM/Pypi dependency mess. Even if we keep the process the same, can we improve other aspects, like how readers view errata or evolutions of works like TLS. We've got another one coming: TEAPv2. We don't need to rewrite *all* of TEAP, but rather do some incremental changes. Thoughts? Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
