> On 24 Jul 2020, at 02:43, Alessandro Ghedini wrote:
>
> On Fri, Jul 24, 2020 at 01:20:41AM +1000, Mark Andrews wrote:
>>
>>
>>> On 23 Jul 2020, at 19:50, Alessandro Ghedini wrote:
>>>
>>> On Fri, Jul 17, 2020 at 10:11:33AM +1000, Mark Andrews wrote:
> On 17 Jul 2020, at 03
On Thu, Jul 23, 2020 at 10:31:50AM -0400, Ben Schwartz wrote:
> On Thu, Jul 23, 2020 at 5:57 AM Alessandro Ghedini
> wrote:
>
> >
> > Also btw, currently we always include ipv4hint and ipv6hint in our HTTPS
> > responses, this is to avoid breaking connections in multi-CDN scenarios,
>
>
> Note
On Fri, Jul 24, 2020 at 01:20:41AM +1000, Mark Andrews wrote:
>
>
> > On 23 Jul 2020, at 19:50, Alessandro Ghedini wrote:
> >
> > On Fri, Jul 17, 2020 at 10:11:33AM +1000, Mark Andrews wrote:
> >>
> >>
> >>> On 17 Jul 2020, at 03:26, Alessandro Ghedini
> >>> wrote:
> >>>
> >>> On Fri, Jul
> On 23 Jul 2020, at 19:50, Alessandro Ghedini wrote:
>
> On Fri, Jul 17, 2020 at 10:11:33AM +1000, Mark Andrews wrote:
>>
>>
>>> On 17 Jul 2020, at 03:26, Alessandro Ghedini wrote:
>>>
>>> On Fri, Jul 17, 2020 at 01:37:35AM +1000, Mark Andrews wrote:
Do you have a estimate on when you
Exactly. Mandatory is required except when it's not. I'll think of some
improved text.
Sent from my iCar
> On Jul 22, 2020, at 10:09 PM, Mark Andrews wrote:
>
> mandatory is described thus:
>
> "In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will
> not
> function c
On Thu, Jul 23, 2020 at 10:50:40AM +0100, Alessandro Ghedini wrote:
> On Fri, Jul 17, 2020 at 10:11:33AM +1000, Mark Andrews wrote:
> >
> >
> > > On 17 Jul 2020, at 03:26, Alessandro Ghedini
> > > wrote:
> > >
> > > On Fri, Jul 17, 2020 at 01:37:35AM +1000, Mark Andrews wrote:
> > >> Do you ha
On Thu, Jul 23, 2020 at 10:50:40AM +0100, Alessandro Ghedini wrote:
> On Fri, Jul 17, 2020 at 10:11:33AM +1000, Mark Andrews wrote:
> >
> >
> > > On 17 Jul 2020, at 03:26, Alessandro Ghedini
> > > wrote:
> > >
> > > On Fri, Jul 17, 2020 at 01:37:35AM +1000, Mark Andrews wrote:
> > >> Do you ha
On Fri, Jul 17, 2020 at 10:11:33AM +1000, Mark Andrews wrote:
>
>
> > On 17 Jul 2020, at 03:26, Alessandro Ghedini wrote:
> >
> > On Fri, Jul 17, 2020 at 01:37:35AM +1000, Mark Andrews wrote:
> >> Do you have a estimate on when you will enable additional section
> >> processing for these recor
On Wed, Jul 22, 2020 at 6:41 PM Ben Schwartz wrote:
> On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian 40akamai@dmarc.ietf.org> wrote:
>
>> ok. So, what this means is that keys listed in the “mandatory” parameter
>> must be included as parameters, and are required to be understood by
>> cl
On Thu, 23 Jul 2020 at 08:33, Mark Andrews wrote:
> On 23 Jul 2020, at 16:51, Petr Špaček wrote:
>
>8
>
> > I'm not native English speaker and I personally find confusing that
> sequence of characters "mandatory" is used as verb and also as name of the
> key. "optional mandatory" sounds like a
> On 23 Jul 2020, at 16:51, Petr Špaček wrote:
>
> On 23. 07. 20 3:41, Ben Schwartz wrote:
>> On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian
>> mailto:40akamai@dmarc.ietf.org>>
>> wrote:
>>
>>ok. So, what this means is that keys listed in the “mandatory” parameter
>> must be inc
On 23. 07. 20 3:41, Ben Schwartz wrote:
> On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian
> mailto:40akamai@dmarc.ietf.org>>
> wrote:
>
> ok. So, what this means is that keys listed in the “mandatory” parameter
> must be included as parameters, and are required to be understood by cl
Because the definitions of “mandatory” and “automatically mandatory” are not
all that clear. And “mandatory” is also a word in the English language, with
meanings and connotations (and is the opposite of “optional”).
The spec is internally consistent, but it definitely could be made be more
c
We could change the sentence to start with "This SvcParamKey MUST NOT be
ignored,"
> On 23 Jul 2020, at 12:09, Mark Andrews wrote:
>
> mandatory is described thus:
>
> "In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will
> not
> function correctly for clients that ign
mandatory is described thus:
"In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will
not
function correctly for clients that ignore this SvcParamKey. Each SVCB protocol
mapping SHOULD specify a set of keys that are "automatically mandatory", i.e.
mandatory if they are prese
If your interpretation of this comes down to “mandatory is optional”, then that
shows how confusing this is.
Brian
> On Jul 22, 2020, at 6:45 PM, Mark Andrews wrote:
>
> This is a case of reading a sentence out of context.
>
> The first paragraph describing “mandatory” ends with:
>
> The Svc
This is a case of reading a sentence out of context.
The first paragraph describing “mandatory” ends with:
The SvcParamKey "mandatory" is used to indicate any mandatory keys for this RR,
in addition to any automatically mandatory keys that are present.
It also has:
In presentation format, "man
Brian
I agree on clarity, and their git repo has been more recently updated.
I've been poking the authors on some better examples in the spec as well.
https://github.com/MikeBishop/dns-alt-svc
On Wed, Jul 22, 2020 at 9:20 PM Wellington, Brian wrote:
> ok. So, what this means is that keys lis
ok. So, what this means is that keys listed in the “mandatory” parameter must
be included as parameters, and are required to be understood by clients. The
set of “automatically mandatory” keys are required to be understood by clients,
but are not required in the RR.
I’m a native English speak
> On 23 Jul 2020, at 10:46, Wellington, Brian
> wrote:
>
> I attempted to start implementing support for SVCB and HTTPS, and discovered
> that the data being served by Cloudflare does not conform to the current spec.
>
> Assuming my decoder is correct, the response below decodes to:
>
> 1 .
> On Jul 22, 2020, at 5:46 PM, Wellington, Brian
> wrote:
>
> I attempted to start implementing support for SVCB and HTTPS, and discovered
> that the data being served by Cloudflare does not conform to the current spec.
>
> Assuming my decoder is correct, the response below decodes to:
>
>
I attempted to start implementing support for SVCB and HTTPS, and discovered
that the data being served by Cloudflare does not conform to the current spec.
Assuming my decoder is correct, the response below decodes to:
1 . alpn=h3-29,h3-28,h3-27,h2 echconfig=aBIaLmgSGy4=
ipv6hint=2606:4700::681
Alessandro
Thanks for letting us know about this.
But to follow up on what Mark says. If Cloudflare isn't planning on
returning them, I'd like to understand the reasons why.
tim
On Thu, Jul 16, 2020 at 8:12 PM Mark Andrews wrote:
>
>
> > On 17 Jul 2020, at 03:26, Alessandro Ghedini
> wrote:
> On 17 Jul 2020, at 03:26, Alessandro Ghedini wrote:
>
> On Fri, Jul 17, 2020 at 01:37:35AM +1000, Mark Andrews wrote:
>> Do you have a estimate on when you will enable additional section processing
>> for these records?
>
> Not sure I understand the question. Do you mean authoritative serve
On Fri, Jul 17, 2020 at 01:37:35AM +1000, Mark Andrews wrote:
> Do you have a estimate on when you will enable additional section processing
> for these records?
Not sure I understand the question. Do you mean authoritative servers adding
A/ records to additional section of HTTPS responses?
Do you have a estimate on when you will enable additional section processing
for these records?
> On 17 Jul 2020, at 01:13, Alessandro Ghedini wrote:
>
> Hello,
>
> Just a quick note that we have started serving "HTTPS" DNS records from
> Cloudflare's authoritative DNS servers. Our main use-ca
Hello,
Just a quick note that we have started serving "HTTPS" DNS records from
Cloudflare's authoritative DNS servers. Our main use-case right now is
advertising HTTP/3 support for those customers that enabled that feature (in
addition to using Alt-Svc HTTP headers).
If anyone is interested in tr
27 matches
Mail list logo
