First, I need to apologize for being largely checked out the
past while - I've been down with a particularly virulent flu
and am still largely flattened by it.  I'll do better.

Second, taking my chair hat off, a couple of comments on the
syntax question: I'm not sure that there have been any
technical arguments made for why either approach must be
excluded, which would be the first place to start, I think.
5246 definitely does not say that that syntax must not be used
for anything else, ever.  What it says is:

"The purpose of this presentation language is to document TLS only; it
has no general application beyond that particular goal."

Because you've wanted to treat this legalistically I think it's
reasonable to point out that the phrase "has no general application"
does not exclude the use of the same syntax to describe what
are TLS-coupled data structures, unless you're arguing that
CT logging of TLS certs would be a "general application."  Even so,
you don't have to look through many IETF specifications to find
instances of later protocols violating some of the constraints written
into earlier specifications - for example, in RSVP-TE extensions to
RSVP.  So, I think that's a tough path to follow.

Frankly, in the absence of compelling technical arguments either
way, my personal inclination is to privilege implementation.  Again,
that's my *personal* inclination.  In the meantime, if there's a
compelling technical argument against this encoding, it's definitely
time to make it.  We do need to make progress and not keep
going over the same ground and arriving at same outcomes.

Melinda

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Reply via email to