Dear Mike,The ECH Draft (draft-ietf-tls-esni-18) refers to draft-ietf-tls-svcb-ech for "specifics about how ECH configurations are advertised in HTTPS records", and acknowledges there may be other ways of distributing the ECHConfig (e.g. preconfiguration). Since my point was focused on how clients should look up configs, I do agree with you that mandating the name construction is not appropriate here.
I'll raise the point separately on the TLS list. Regards, Raghu Saxena On 6/25/24 4:35 AM, Mike Bishop wrote:
RFC 9460 says this:Protocol mapping documents MAY specify additional underscore-prefixed labels to be prepended. For schemes that specify a port (Section 3.2.3 of [URI]), one reasonable possibility is to prepend the indicated port number if a non-default port number is specified. This document terms this behavior "Port Prefix Naming" and uses it in the examples throughout.As this document is not a protocol mapping, but simply the definition of a SvcParam which could be used by any protocol mapping, I don’t believe mandating anything about how mappings construct their names is appropriate here.RFC 9460 does use Port Prefix Naming for HTTPS records when accessing an origin on a non-default port; that doesn’t use MUST, but it’s a definition of how the HTTP origin maps to the HTTPS query name. Another protocol mapping might choose a different construction, and that wouldn’t affect anything about how this SvcParam works.
OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
