[dns-operations] creeping poorness of judgement

[Viktor Dukhovni]

On Mar 14, 2020, at 4:00 AM, Mark Delany <b9w at charlie.emu.st> wrote:

> Methinks the safest outcome is that TXT substrings should be treated
> as an artifact of the limitations of TXT RRs or a side-effect of
> serialization and should have no semantic value whatsoever.

I largely share the sentiment.  At this point it looks like the above
interpretation would most closely conform to existing practice.

I know of no specifications that concatenate TXT RR strings with spaces.
This makes sense given that TXT RRs are not ASCII natural language
prose, but are rather what we generally call "octet-strings".

There is however at least one counter-example to declaring that TXT
carries just a single concatenated (with an empty joiner) logical
string.  For example, in DNS-SD https://tools.ietf.org/html/rfc6763,
each substring in a TXT RR is a separate "key=value" pair.

The DNS-SD TXT RRs are distinguished from unrelated TXT RRs by
sharing the "_service._protocol" prefixes of the corresponding
SRV RRs, so would not in practice be confused with e.g. SPF or
DKIM where the rules are as proposed by Mark.
 
So while I've found no existing practice of joining with spaces, there
is it seems an expectation that the component substrings can be
separately meaningful in some applications.

So my take is that applications that expect a single string per TXT
record should just join without inserting spaces, while applications
that expect multiple values can use the verbatim substrings without
concatenation.

-- 
    Viktor.