Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Eric Orth <[e-mail]>]

A big selling point behind why we have client implementers planning to
query HTTPS records is the expectation that this will be the only query
type we will need to add and that it can be extended to handle any future
information we need for establishing HTTPS connections (and we want
mechanisms to be able to add stuff in the future to keep improving HTTPS
connection behavior).  It is not practical to add too many additional DNS
queries to make web requests, and nobody wants a
deprecation/new-SVCB-based-record-type cycle every time we need to add
something.  So in the end, I do not expect HTTPS would see much adoption
without the extensibility.

On Thu, May 20, 2021 at 6:37 AM Ralf Weber <[e-mail]> wrote:

> Moin!
>
> On 20 May 2021, at 3:32, Brian Dickson wrote:
> > (There's a reason I'm not suggesting making SVCB non-extensible, or
> > touching any aspect of the SVCB thing itself.)
> >
> > Note that more ALPN values are supported, and how those are
> > defined/used/etc are really not relevant to the structure (wire format)
> of
> > the records (HTTPS or SVCB).
> >
> > HTTPS needs transport, port number, name, and maybe some hints for IP
> > addresses, plus the new encrypted SNI.
> Well if we created HTTPS five years ago we would not have known about
> encrypted client helo. The point of an extensible format is that you
> can extend it beyond what you know now. And I am pretty sure there will
> be development in the HTTPS arena.
>
> For me mentally HTTPS is just a shortcut for
>         _https.name IN SVCB …
> so on the right side HTTPS and SVCB are the same and we should keep it
> that way IMHO.
>
> So long
> -Ralf
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>