On Tue, Sep 24, 2019, at 7:27 AM, Salz, Rich wrote:
>
> * we refactored the HTTPSSVC draft to make it more general. The hope is that
> * it could be an alternative (or replace the need) for a distinct ESNI
> record.
>
> I am strongly opposed to two ways of doing the same thing. I will be
>
On Tue, Sep 24, 2019 at 12:24:15PM -0400, Ben Schwartz wrote:
> On Tue, Sep 24, 2019 at 11:31 AM Ilari Liusvaara
> wrote:
>
> > On Tue, Sep 24, 2019 at 09:21:25AM -0400, Erik Nygren wrote:
> > > Following the discussions in Montreal (as well as with some of the ESNI
> > > authors),
> > > we refac
Thanks Ben, bit more below...
On 24/09/2019 16:15, Ben Schwartz wrote:
>> So I think the basic ESNI case where there's no
>> name changes nor alt-svc etc would be as below in
>> presentation syntax, am I reading that right?
>>
>>example.com. 7200 IN HTTPSSVC 0 . ( esnikeys="/wHrAh..." )
>>
>
On Tue, Sep 24, 2019 at 09:21:25AM -0400, Erik Nygren wrote:
> Following the discussions in Montreal (as well as with some of the ESNI
> authors),
> we refactored the HTTPSSVC draft to make it more general. The hope is that
> it could be an alternative (or replace the need) for a distinct ESNI rec
Hi Erik,
FWIW, if browsers preferred this to an ESNI RR and
we could forget the ESNI RR then I'd be ok with that.
I'm not clear if they do or not though. In the meantime,
assuming this went ahead instead of or in addition
to an ESNI RR, I've a few questions below...
On 24/09/2019 14:21, Erik Nyg
* we refactored the HTTPSSVC draft to make it more general. The hope is
that
* it could be an alternative (or replace the need) for a distinct ESNI
record.
I am strongly opposed to two ways of doing the same thing. I will be taking a
close look at this, but I hope that the folks heavi
