Hi. I have merged the PR following review and proposed changes by Chris and Martin Thomson.
The only point that remains open is Ekr’a suggestion to allow (require?) sending the extension when empty. Yoav > On 22 Feb 2022, at 7:35, Yoav Nir <ynir.i...@gmail.com> wrote: > > I have just submitted PR #20 to allow unacknowledged flags. It is a rewrite > of section 3 (rules) > > https://github.com/tlswg/tls-flags/pull/20 > <https://github.com/tlswg/tls-flags/pull/20> > > It still requires that the flag extension not be sent when empty. Let me > know if that’s a problem as well. > > Yoav > >> On 21 Feb 2022, at 2:21, Martin Thomson <m...@lowentropy.net >> <mailto:m...@lowentropy.net>> wrote: >> >> I missed this text in draft-ietf-tls-tlsflags: >> >> A server that supports this extension and also supports at least one >> of the flag-type features that use this extension and that were >> declared by the ClientHello extension SHALL send this extension with >> the intersection of the flags it supports with the flags declared by >> the client. >> >> While sloppy on my part [1], I want to make it clear that this is a >> show-stopper for me. Requiring an echo prevents a flag extension from >> attaching semantics to a "response". >> >> I agree with Ilari's earlier point that these should work just like >> extensions. If the server has no need to echo a flag, it should not be >> required to do that. That allows the flag value in a "response" to carry >> semantics. >> >> Cheers, >> Martin >> >> [1] I missed this in the second WGLC, though in my defense, I don't think >> the resolution and changes resulting from the first WGLC were very clearly >> communicated. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org <mailto:TLS@ietf.org> >> https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
