Consider the case where the client wants to offer some capability that the server then responds to with real data, rather than just an acknowledgement.
For instance, supposing the SCT extension from RFC 6962 did not exist, the client would want to indicate support in CH and the server would send the SCT in CERT, but this extension would need to be non-empty and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit uncelar on this point (unless I'm missing it) but I think we should explicitly allow it. Thoughts? -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
