Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on draft-ietf-json-text-sequence)

["Martin J. Dürst" <[e-mail]>]

On 2014/06/02 08:16, Nico Williams wrote:
> On Sun, Jun 1, 2014 at 6:10 PM, Paul Hoffman <[e-mail]> wrote:
>> On Jun 1, 2014, at 3:35 PM, Nico Williams <[e-mail]> wrote:
>>> On Sun, Jun 1, 2014 at 12:08 AM, Tim Bray <[e-mail]> wrote:
>>>> No. There should be only one way to do things.

I agree with this sentence, but I very strongly disagree with the 
proposal of U+FFFE.

>>> I'm not terribly fond of this.
>>>
>>> It'd be easier if we picked a Unicode whitespace character that's not
>>> used in the JSON whitespace rule and must be escaped in strings,
>>> preferably one that terminals and such generally handle as a
>>> whitespace.
>>
>> What would a whitespace character be "easier" than a character not allowed in Unicode? It seems to me that a character that could not exist in a string and therefore never needs to be escaped is "easier".
>
> Because I want text-based tools to be able to at least display (and
> grep, and...) JSON text sequence contents much as they can JSON text
> contents.

Yes exactly. The Unicode spec says that U+FFFE must never be interpreted 
as an abstract character nor interchanged. While "interpreted as an 
abstract character" leaves quite a bit of room for interpretation 
(sic!), "not interchanged" is very clear. I hope we won't define a 
format that cannot be interchanged.

The reason why Unicode defines things that way is that there may be 
implementations (think editors,...) that use U+FFFE internally, and 
those would be quite confused when receiving it. There will also be 
applications (editors and other tools, including security checkers) that 
will bark on U+FFFE as part of checking for correct UTF-8.

Regards,   Martin.