Could you clarify what you mean by supported vs preferred? I'm not sure I follow what the difference is, in the context of a TLS implementation.
The intention is that you list all the NamedGroups you support, in order of decreasing preference. That gives the client enough information to make a reasonable prediction. On Tue, Sep 24, 2024 at 6:24 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Hiya, > > I read the draft again just now. ISTM overall a fine idea. > > I think the current draft is a bit ambiguous as to whether > the SvcParamKey reflects preferred or supported groups. It > may be better to resolve that before allocating a codepoint. > > However, if the DEs considered a possible later change to the > presentation syntax as being consistent with allocating a > codepoint now, then I'd be fine with going ahead now, but IIRC > DNS folks do also care about presentation syntax stability > when it comes to codepoints. (I could be wrong there or things > could have changed, which could change my conclusion.) > > The quickest way to resolve this might be to rev the draft > and just change the presentation syntax term from supported > to preferred. (Assuming we agree that the HTTPS RR values > will typically reflect overall group preferences for the > target and not everything actually supported by all the > server instances concerned.) > > Cheers, > S. > > On 9/24/24 19:17, Sean Turner wrote: > > Hi! After discussions with the author (David Benjamin) of draft-ietf- > > tls-key-share-prediction [0], I would like to determine whether > > there is consensus to request an “early” * code point request for a > > 'tls-supported-group' entry in the Service Parameter Keys registry; > > see Section 5 of the I-D. The point of this consensus call is to > > determine whether you think this I-D is stable enough to request a > > code point in the Expert Review range [1]. Please let the list know > > by 8 October 2023 if you support this “early" allocation. > > > > * Early is in quotes because, technically, this is not an early IANA > > allocation as defined in [2]; I am just calling it “early" because > > it’s before the I-D is an RFC. I confirmed with the Service > > Parameter Keys DEs (Designated Experts) that we can get a code point > > in the Expert Review space if the I-D is stable; if not, then we > > should be using the Private Use space. > > > > spt > > > > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-key-share- > > prediction/ [1] https://www.iana.org/assignments/dns-svcb/dns- > > svcb.xhtml [2] https://datatracker.ietf.org/doc/rfc7120/ > > _______________________________________________ TLS mailing list -- > > tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
