I think it would probably be better to require it to be sent even if empty. Then you could measure how often it was implemented.
On Mon, Feb 21, 2022 at 9:36 PM 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 > > 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> 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 > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
