On Fri, Apr 30, 2021, Martin Thomson wrote: > An existing application protocol might not have been assigned an > ALPN identifier. For other protocols the ALPN identifier might > not have been part of the original protocol definition, or use of > ALPN might have been defined originally as being optional.
Sorry for this stupid/simple question but I cannot find a way for a client to determine whether a server 1. does not support ALPN. 2. supports ALPN but did not select a protocol. It seems it is only possible to return a selected protocol, not am "empty" protocol to indicate case 2, correct? IMHO this would be useful for backwards compatibility/ migrating a protocol to support ALPN. RFC 7301 states the server "SHALL" abort in this case: 3.2. Protocol Selection ... In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert. but that might not be a good way to support migration, which probably is why is just "SHALL" not "MUST"? Maybe it would be useful to specify an "empty"/"dummy" protocol, which just states case 2, e.g., "NOMATCH"? -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
