+1 Text that is shown to end users is "content". DNS is a platform for distributing technical metadata, not content for users.
--Ben Schwartz On Tue, May 26, 2026 at 6:41 AM Martin Thomson <[email protected]> wrote: > > > Please don't. > > I've reviewed the discussion of this and I can't work out who would use > this capability. > > It is sufficient to include a language tag alongside the freeform text > content. A DNS server operator can - at their discretion - provide > freeform diagnostic information for someone on the other end. That's > useful. > > I will observe that other protocols that offer freeform text fields for > diagnostic messages don't bother with the language tag. That's OK because > this text will never be put in front of an end user. So the language tag > is above and beyond. > > We now have translation services if the language chosen by the server > operator turns out to be something the recipient isn't natively able to > handle. Those services are very cheap and very good. But there's also a > good chance they won't be needed: either because no one bothers to read the > text being produced (see Lars' message) or because they understand the > language that is used. > > As Mark pointed out, HTTP and HTML have a bunch of adaptations for > language negotiation. Those aren't pretty, but they are well-used and > proven. If this were intended to be put in front of a human, those would > have a far better chance of successfully delivered language-appropriate > content. Building a parallel negotiation process in the DNS protocol is > most likely to turn into protocol baggage. Baggage that will prevent the > payload of the query option from being used for something else in future. > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
