Represent names as their compontents

[miri64]

During the mailing list discussions of -03, @chrysn proposed to represent names as their components instead of tstr, similar to how it is done in draft-ietf-core-href:

host-name   = (*text) ; lowercase, NFC labels

That is, rather than expressing some.hostname.example.com as "some.hostname.example.com", it goes for "some", "hostname", "example", "com"

There are several advantages to that representation:

• If not put in their own array, but just verbatim into the arrays already used in the spec, we safe the list specifier, i.e, one byte at least
• Dots (".") can be expressed as part of a name component without extra encoding (I don't think that is legal in DNS domain names; @chrysn says they can occur in DNS-SD service names though)
• It would be more in line with how DNS encodes names (delimiter identifies the length of the following name component)
  • This would have the additional advantage that we could use a DNS-like name compression (i.e. an int to refer to an offset in the CBOR binary). The only thing we need to do to make names also encodeable as uints is to swap ttl in RR. This way, the first int in a CBOR array that potentially could contain names always would be identifiable as the name (questions always contain a name, so the first uint would just be the name).

The only disadvantage we found so far is that there is no straightforward way to use the value or inverted references for names with this... But maybe, if we have DNS-like name compression, this wouldn't be needed anyways.

[chrysn]

I don't think that is legal in DNS domain names

AIU it is perfectly legal in DNS, it's just that URIs can not (due to their interesting escaping rules) express that dot, not even with percent encoding (maybe punycode though?) -- so it works only where DNS names are never put into a URI.

[miri64]

It is legal, but strongly discouraged: https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1

[miri64]

Addressed in the two most recent versions