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

[Paul Hoffman <[e-mail]>]

Thanks for the comments!

On Sep 6, 2014, at 7:02 AM, Andreas Gustafsson <[e-mail]> wrote:

> 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.".  

You are, of course, right on both of those. Fixed in the next version of the draft.

> 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.  

Fully agree. That's why I used the examples in the paragraph preceding this. It is unlikely that anyone would want to see a string with an unprintable character in it, particularly a DEL character, but that is what you could get if you relied on the JSON encoder. Even if that was OK with you, the other example (turning 0xC2 0xB5 into 0xB5) seems terribly dangerous.

> 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.

Exactly right.

Shane, does this all convince you that \u encoding would be a bad idea?

--Paul Hoffman