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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
