On Wed, Nov 19, 2025 at 07:09:13PM -0500, Marco Davids (IETF) wrote:
That said, I prefer not to pre-emptively include such guidance in my draft.
The current text seems sufficient and in line with the style and
intent of other I-Ds and RFCs:
It includes a paragraph ensuring interoperability (e.g., input from a
sender such as 'この美しいドメイン名を購入してください。' is correctly
interpreted by the receiver) and cautions in Security Considerations
on careful parsing.
The advice is inadequate, if you're going to require people to interpret a series of
octets as octets in a UTF-8-encoded string. At the very least, you need to specify
whether automatic processing of any kind of that content is permitted. If it _is_
permitted (and it would appear to me that it is, given what you say llater about
careful parsing &c.) , then it seems to me you're going to have to specify limits
on what code points may or may not be included, normalization forms, &c. If you
don't specify all of that, then attempting to interpret the octets in the RDATA as
being UTF-8-encoded strings will be at least fragile.
It is not clear from the rest of the document whether the "use UTF-8" principle
is in effect for all the subtypes possible in the record, or only in the ftxt subtype.
For instance, is the host part of an furi entry required to be an ASCII string (i.e. if
it's an IDN, must it be the A-label form?) or may it include UTF-8 strings beyond the
ASCII-equivalent range? It seems to me it would be valuable to specify which is meant.
Best regards,
A
--
Andrew Sullivan
[email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
