On Mon, May 18, 2026 at 1:57 PM Brian E Carpenter < [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. -Ekr > 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]> 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/. 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] > To unsubscribe send an email to [email protected] >
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
