[DNSOP] Re: AD review of draft-ietf-dnsop-structured-dns-error-19

["Eric Vyncke (evyncke)" <[e-mail]>]

If this is the case (and I am trusting you on this statement and understanding the reasoning), then what is the reason for adding a human-readable string in the SDE ?

I.e., if 'j' and 'l' names won't ever be used, then why not keeping only 'c' (and even...),  's', 'o' names in the JSON ?

Regards

-puzzled-éric

From: Mark Nottingham <[e-mail]>
Date: Sunday, 10 May 2026 at 03:48
To: Mukund Sivaraman <[e-mail]>
Cc: Eric Vyncke (evyncke) <[e-mail]>; tirumal reddy <[e-mail]>; [e-mail] WG <[e-mail]>; Dan Wing <[e-mail]>; [e-mail] <[e-mail]>; Mohamed Boucadair <[e-mail]>; Benno Overeinder <[e-mail]>
Subject: Re: [DNSOP] AD review of draft-ietf-dnsop-structured-dns-error-19

There's been pretty consistent feedback from browsers that they're reluctant to directly display textual strings from DNS responses to users.


> On 10 May 2026, at 12:39 pm, Mukund Sivaraman <[e-mail]> wrote:
>
> On Sun, May 10, 2026 at 10:19:07AM +1000, Mark Nottingham wrote:
>> I'd be concerned if we started rebuilding HTTP semantics inside
>> DNS. The merit of putting links instead of strings inside the response
>> is that you can then use language negotiation (etc.) for a richer
>> experience when called for without burdening DNS.
>
> Indeed a URL that provides localized information seems better than
> localizing in DNS.
>
> I think Eric is pushing for localizing the justification string which is
> meant to be displayed to a human in a browser.
>
>> Emitting another bit of fingerprinting data on all DNS requests is
>> likely to be controversial, and also will require significant
>> implementation effort.
>
> For example, if the new structured-dns-error EDNS option in a query,
> instead of being empty, includes the requested language, a nameserver
> could ignore it and deliver text for whatever locale it wants to as is
> currently specified in the draft.  The extra implementation effort would
> be for nameservers that want to deliver localized strings, and that need
> not be much work. For example, for one kind of implementation, it would
> involve wrapping justification messages in _(), providing po
> translations, specification of organization translations in
> configuration with a map.  Just responding to the point that this isn't
> necessarily a lot of development work.
>
> I prefer the URL approach you've mentioned above and to leave
> localization out. The language field would be just an indicator of what
> language the justification and organization name are delivered in.
>
> Mukund

--
Mark Nottingham   https://www.mnot.net/