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, g...@araneus.fi _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
