Re: [DNSOP] New draft on representing DNS messages in JSON

[Andreas Gustafsson <[e-mail]>]

In draft-hoffman-dns-in-json-01.txt, Section 2.5, Paul Hoffman wrote:
>   Given this, there are many possible choices for how to represent
>   domain names in JSON in a human-readable fashion.  In this list,
>   exampes are given for the label that has six octets 0x4341743A7FB52E
>   under the TLD "example".  Some examples are:
>
>   o  Show the character for all octets that are ASCII displayable
>      characters (0x21 to 0x7E, but not 0x2E), and the RFC 1035 "\DDD"
>      escaping for all other octets: "CAt:\D127\D181\D046.example."

There is no literal D in the \DDD encoding, so the final string should
read "CAt:\127\181\046.example."

>   o  Show the character for all octets that are ASCII displayable
>      characters (0x21 to 0x7E, but not 0x2E), and the normal JSON
>      escaping for all other octets: "CAt:&u007f&u00b5&u002e.example."

The normal JSON escaping uses backslashes, not ampersands, and so
would result in "CAt:\u007f\u00b5\u002e.example.".  But unless you are
actually suggesting a second layer of JSON-like escaping on top of
that applied by the JSON encoder, this will not work.  Firstly, when
using a standard JSON encoder, you do not have control over which
characters get escaped and which do not.  Secondly, even if you did
manage to produce a JSON document where "." and "\u002e" are intended
to mean different things, when that document is read by a standard
JSON decoder, they will result in identical string objects, and the
distinction will be lost.
-- 
Andreas Gustafsson, [e-mail]