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.
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]
