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
Hello,
I've read through RFC 8499, and found some things I considered odd.
Particularly page 14 and 19 which describe the "master files" and the
"primary" and "secondary" servers.
In most of the DNS-related documentation I've read so far, the "master
files" are often called zone files. I fin
On a EBCDIC system you need to run the record through ASCII / EBCDIC
conversion for display purposes after converting from wire to ASCII. Those
values that are not transformable use \DDD for, curly braces if I’m remembering
properly. Remember the presentation format is defined in terms of ASCI
On Mon, 20 Jul 2020 at 22:54, Ben Schwartz wrote:
The unknown-key format is designed more for authoring than reading. As an
> author, it works somewhat better than your example. For instance, your
> key1 could be written as
>
> key1=\005h3-29\005h3-28\005h3-27\002h2
>
It is not as easy as you
We have a very incomplete list of work-in-progress SVCB/HTTPS RR
implementations here
for people who wish to do interop testing:
https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md
Feel free to submit PRs to add to that list. At some point we may convert
it to something
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 Tue, 21 Jul 2020 at 00:25, Mark Andrews wrote:
> > IMHO, tarted up RFC3597 format is easier to read.
>
> Well the presentation form clearly is designed for printable ASCII to be
> rendered as ASCII.
>
Except for the inconvenient fact that Net::DNS also works on OS390 which
speaks EBCDIC.
>
17 matches
Mail list logo
