On Friday 01 May 2015 06:58:15 Carsten Bormann wrote:
> If JSON must be accommodated, I agree with most of this.
> Exceot:
> 
> Thiago Macieira wrote:
> >     US-ASCII text strings
> 
> You never need to transport user-visible text?

That is a very good question. Do we?

Anyway, after rereading RFC 7159's section 7 (Strings) 
<https://tools.ietf.org/html/rfc7159#section-7>, it says:

        "Any character may be escaped. "
and
        "unescaped = %x20-21 / %x23-5B / %x5D-10FFFF"

So any character except for control characters, the quote and the backslash 
can also be transmitted unescaped, in UTF-8.

> (While JSON escaping is ugly, it's never needed for non-ASCII
> characters.  You only ever need to escape code points U+0000 to U+001F.
>  Of course, you'll need to be prepared for random JSON implementations
> sending you escaped characters that needn't be, so you need a de-escaper
> for everything, including the super-ugly non-BMP encoding.  But you
> never have to escape those yourselves.)

Right.

Anyway, I propose we still have two types of strings in our internal mapping:
        one that cannot contain characters escaped in JSON
        one that can contain arbitrary human text

The implementations never need to parse human text, so if we can restrict 
information that the implementations need to parse to the ones that won't need 
escaping, we save ourselves a great deal of trouble.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

Reply via email to