https://www.ietf.org/archive/id/draft-hallambaker-donotissue-04.txt This is what was used to allocate the typecode. Note the MUST NOT. Tag The property identifier, a sequence of ASCII characters. Tag values MAY contain ASCII characters a through z and the numbers 0 through 9. Tag values MUST NOT contain any other characters. Matching of tag values is case insensitive. I don't care what RFC 6844 says here. Once the code point is allocated the code point format is frozen. This is the direct result of changing the specification after the fact. The IESG should have rejected the change. There is zero need for anything other than ASCII here as it is a protocol element. RFC 6844 also has: Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower case. Which makes the RFC 6844 self contradictory. It is either this sequence or it isn't. Mark In message , "Evan Hunt via RT " writes: > On Wed, Mar 09, 2016 at 10:14:48PM +0000, Robert Edmonds via RT wrote: > > In the case where you have to render an unpresentable CAA record (for > > instance because you might be writing a text master file format zone to > > disk), couldn't you just fall back on RFC 3597 generic presentation > > format for the record data? E.g., > > > > caa.example. IN CAA \# 03 00 01 20 > > Very smart suggestion, thank you. > > > > -- > Ticket History: https://bugs.isc.org/Ticket/Display.html?id=41900 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org