On Wed, May 12, 2021 at 9:33 PM Ben Schwartz wrote:
> On Wed, May 12, 2021 at 7:14 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> It is demonstrably more likely that a complex parser will have problems,
>> than something that combines data from simple RRs in simple RRsets will
>>
On 11/05/2021 18.17, Wes Hardaker wrote:
I'd also expect something on limits accepted by secondaries. And some
details are probably up to further discussion (e.g. particular numbers
and SERVFAIL), but I don't think such details would block adoption.
That's certainly an interesting thing to thin
Hi all,
just my comment:
Perhaps complexity is subjective. The important thing is that the
standard be reasonably implementable. I hope that the list of
published implementations [3] will serve as convincing evidence that
the current draft is sufficient in that regard.
--Ben
I agree that
On Thu, May 13, 2021 at 3:56 AM libor.peltan wrote:
> Hi all,
>
> just my comment:
>
> Perhaps complexity is subjective. The important thing is that the
> standard be reasonably implementable. I hope that the list of published
> implementations [3] will serve as convincing evidence that the cur
On Thu, 13 May 2021, Ben Schwartz wrote:
SVCB's key=value zone-file format is borrowed straight from DNS-SD (RFC
6763); it is not new to DNS users.
Hey, wait a minute. DNS-SD just sticks the "key=value" strings as-is into
text fields. Now that I look closer, I see what Brian's objection is a
Pushing text processing onto the client does not reduce the complexity; it
just moves it to people who are less likely to be reading DNSOP. Notably,
it moves that responsibility to a place where typical text processing
errors are far more dangerous, and malicious inputs are far more likely.
I s
