On a EBCDIC system you need to run the record through ASCII / EBCDIC conversion for display purposes after converting from wire to ASCII. Those values that are not transformable use \DDD for, curly braces if I’m remembering properly. Remember the presentation format is defined in terms of ASCII for its conversion to wire in DNS.
Presenting everything as \DDD is doing a disservice to your EBCDIC users. -- Mark Andrews > On 23 Jul 2020, at 03:27, Dick Franks <rwfra...@gmail.com> wrote: > > > >> On Tue, 21 Jul 2020 at 00:25, Mark Andrews <ma...@isc.org> wrote: >> >> >> > IMHO, tarted up RFC3597 format is easier to read. >> >> Well the presentation form clearly is designed for printable ASCII to be >> rendered as ASCII. > > Except for the inconvenient fact that Net::DNS also works on OS390 which > speaks EBCDIC. > > >> > Example: >> > >> > use Net::DNS; >> > >> > my $rr = new Net::DNS::RR <<'END'; >> > example.net. 300 IN HTTPS 1 target.example.net. >> > mandatory=key0,key1,alpn,no-default-alpn,key99 ; with >> > duplications and other sins >> > alpn=h3-29,h3-28,h3-27,h2 >> > ... > >> Which is a interesting conversion of >> "mandatory=key0,key1,alpn,no-default-alpn,key99”. I would expect the parser >> to reject the record as mandatory contains “key0” in the list. I would also >> expect the parser to reject the record as there is no “key99” in the record. >> I would never expect the parser to strip out keys listed in mandatory just >> because they are not present in the rest of the record. > > Good idea. > I was only raising these exceptions on received packets, but the same tests > are reasonable for freshly created RR. > > --Dick
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
