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. -----Original Message----- From: Raghu Saxena <poiasdpoi...@live.com> Sent: Wednesday, June 12, 2024 11:31 PM To: tls@ietf.org Subject: [TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings I had one comment earlier that seems to have been missed [0]. Basically I was wondering if it may be useful to use stronger language in the draft to indicate a client MUST use Port Prefix Naming when looking up the SVCB record. Regards, Raghu Saxena [0] https://mailarchive.ietf.org/arch/msg/tls/ynRkX60dGq-ofmSW4POhppQcgkY/ On 6/13/24 2:10 AM, Sean Turner wrote: > This email starts the working group last call for "Bootstrapping TLS > Encrypted ClientHello with DNS Service Bindings” I-D, located here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ > > The WG Last Call will end 26 June 2024 @ 2359 UTC. > > Please review the I-D and submit issues and pull requests via the GitHub > repository that can be found at: > > https://github.com/tlswg/draft-ietf-tls-svcb-ech > > Alternatively, you can also send your comments to > tls@ietf.org<mailto:tls@ietf.org>. > > Thanks, > spt > _______________________________________________ > TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> > To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
