On Jan 29, 2026, at 02:36, Paul Wouters <[email protected]> wrote: > > On Wed, 28 Jan 2026, Ted Lemon wrote: > >>>> But more >>>> importantly, "encoded as a CBOR text string" is too vague to be >>>> interoperable. >>> >>> See https://datatracker.ietf.org/doc/html/rfc8949#name-cbor-data-models >> >> This doesn't address the point I raised at all. I get that there is a >> definition for "CBOR text string"; the problem is that the text does not >> specify how to generate the contents of that string. > > Ok, so perhaps you mean something like "A CBOR text string containg a DNS > presentation format FQDN, using A-label > (punycode) as per RFC5890, without trailing dot" ?
My concern is that a wire-format label can contain any sequence of octets, including NUL characters. I don't think IDN solves this, but maybe I'm mistaken—I will confess to having avoided to the best of my ability actually reading RFC5890, but my understanding is that it talks about the content of wire-format labels, and that its only effect on presentation-format is to talk about how these are translated to unicode. If in fact RC5890 provides a presentation-format encoding for arbitrary label values, then that would address my concern. I also think that there isn't really a use case for random characters in labels, so one way to deal with my objection would be to specifically state that arbitrary binary values can't be represented in labels, and perhaps reference RFC5890 to say what _is_ permitted. I'm not sure RFC5890 is suited to that purpose, but in principle that would work. Another way to deal with this would be to restrict the string to representing "hostnames" and then reference RFC 952, which RFC5890 also references to the same purpose. Since RFC5890 deliberately tries to squeeze IDN into valid hostnames, I think this would suffice. _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
