On 19-May-26 08:59, Eric Rescorla wrote:
On Mon, May 18, 2026 at 1:57 PM Brian E Carpenter <[email protected] <mailto:[email protected]>> wrote: Interested, yes, but not if you do it during Austrian working hours... Re draft-rescorla-rfc-jit, I'm all for an RFC12345.1 model but it has to come with an improved errata process; I view that as a single package. Hi Brian, Do you think you could elaborate a bit on what you would want to see in an improved errata process? I have my own ideas, of course, but I'm curious about yours.
A good question, and I haven't thought about it enough yet. Mainly, a better defined process for each stream to rapidly process each erratum, establish whether it's editorial or needs a consensus discussion, and get it done and integrated into a new version of the source (presumably .xml), and issue a .1 version. It really isn't OK that we have unresolved errata going back years. Brian
Regards/Ngā mihi Brian On 19-May-26 03:31, Eliot Lear wrote: > 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] <mailto:[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 versions >> >> My put for non-semantic changes is: https://datatracker.ietf.org/doc/draft-rescorla-rfc-jit/ <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 >> >-- rswg mailing list -- [email protected] <mailto:[email protected]>To unsubscribe send an email to [email protected] <mailto:[email protected]>
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
