On Mon, Feb 21, 2022 at 11:21:38AM +1100, Martin Thomson 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.
I think (but don't have a solid recollection) that this may have stemmed from a desire for the sender to know if the recipient supports flags at all. But thinking about it now (and as Ekr's response suggests), so long as we don't allocate flags for existing extensions, there is not much useful to do with that information in cases where the extension semantics of the flag(s) in question don't require a response. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
