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

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Sep 2014 16:06:35 -0700

I have revised the draft to add some name types to make domain names with just a few non-ASCII characters easier to read. However, I would really like to hear from application developers who intend to represent DNS messages in JSON whether or not the new name forms are useful and, if not, what they would want to use in their applications.

--Paul Hoffman

> A new version of I-D, draft-hoffman-dns-in-json-01.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Name:		draft-hoffman-dns-in-json
> Revision:	01
> Title:		Representing DNS Messages in JSON
> Document date:	2014-09-01
> Group:		Individual Submission
> Pages:		18
> URL:            http://www.ietf.org/internet-drafts/draft-hoffman-dns-in-json-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/
> Htmlized:       http://tools.ietf.org/html/draft-hoffman-dns-in-json-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-in-json-01

---

From: Andreas Gustafsson <[email-masked]>
Date: Sat, 6 Sep 2014 17:02:48 +0300

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, [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Sep 2014 09:02:02 -0700

Thanks for the comments!

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

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

Exactly right.

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

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Sep 2014 19:28:02 -0700

Or, we could use an actual standards-track RFC: 4343. I take it no one remembers this one...

--Paul Hoffman

---

From: Andreas Gustafsson <[email-masked]>
Date: Sun, 7 Sep 2014 15:19:55 +0300

Paul Hoffman wrote:
> Or, we could use an actual standards-track RFC: 4343.

That's a good find.  Works for me.

> I take it no one remembers this one...

I must have mentally filed it under "Case Insensitivity" and
forgotten that it also discussed this issue.
-- 
Andreas Gustafsson, [email-masked]