Re: [Json] Scope: Wire format or runtime format?

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

Hello Norbert,

On 2013/06/14 7:47, Norbert Lindenberg wrote:
> In looking over older messages on this list, I found a message that made clear to me why we're having this endless discussion about Unicode surrogates -
 >it's because we're not clear whether we're designing a wire format or 
a format that also for use at runtime:
> http://www.ietf.org/mail-archive/web/json/current/msg00355.html

This is kind of the first time I have heard the term "format for use at 
runtime" in this context. Of course there are formats used at runtime 
(internal representations of number and strings, for example), but I 
think the term "runtime format" only confuses our discussion. In my 
understanding, JavaScript does not have or use JSON as a runtime format. 
If that has changed, then please tell us.


> Some people are coming from the runtime point of view, especially ECMAScript, where it's accepted practice to use ill-formed UTF-16 or even non-text in strings.
 >At least the ill-formed UTF-16 is legitimized by section 2.7 of the 
Unicode standard.

"Accepted practice" is probably going a bit too far, and giving the 
wrong impression. My understanding is that the Unicode standard accepts 
this for efficiency reasons, not because it's in anyway inherently 
useful. For ECMAScript, we have to add history to efficiency, but still 
I hope it's considered bad practice to actually use ill-formed UTF-16.

> Other people are coming from the wire protocol point of view, where clean formats are expected,
 > in particular well-formed Unicode code unit sequences according to 
section 3.9 of the Unicode standard.
>
> So which one shall it be?

 > If we adopt the wire protocol point of view

To me, it's very clear that we are describing (we are not designing; 
that has happened a long time ago, and very implicitly) a wire format, 
or something close to a wire format (somebody mentioned JSON embedded in 
an (e.g.) EUC-JP HTML page (*)).


> and require well-formed code unit sequences,

For practical reasons, I think we shouldn't go there. But we should make 
it very clear (in the base spec, not relegated to some "best practices" 
document) that using lone surrogates is a bad idea, and that senders and 
receivers MAY reject such data (e.g. because of security concerns).


> then ECMAScript will have to define its own extension of JSON

I very much hope we can avoid that. I very much hope that ECMAScript can 
tolerate that lone surrogates are often if not always a bad idea, even 
if they may sometimes happen for historical and efficiency reasons.


> (which it has already by allowing JSON values at the top level).

At least on the IETF side, as far as I know, this is still under discussion.

> If we adopt the runtime point of view and allow all code points as in RFC 4627, then there probably should be separate verbiage defining a restricted version for use over the wire.

I'm still at loss about what you mean by "runtime point of view". It 
seems very clear to me that neither the IETF version nor the ECMAScript 
version (in case they end up to differ) will in any way describe 
ECMAScript strings (or other datatypes) at runtime.

Regards,   Martin.

(*) It's not impossible for me to imagine something like JSON embedded 
in an (e.g.) EUC-JP HTML page, but I'm seriously wondering how 
widespread this is in practice. A simple case would be that a script 
says "take the content of this element and interpret it as JSON". But 
how widespread is that? Of course, we have a lot of stuff inside 
ECMAScript, but as soon as I'm in ECMAScript, something like
measurement = { 'unit': 'mm', 'amount': 15 }
is no longer JSON, it's just ECMAScript literal notation.