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]
