Re: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft)

[Henri Sivonen <[e-mail]>]

On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren <[e-mail]> wrote:
> XHR's responseType = "json" only supports UTF-8 (optionally with a
> leading BOM), across the board.

Good point. I wrote the code that enforces that constraint, but I forgot.

Well, there's an interoperability reason against UTF-16, too, then.

On Thu, Nov 21, 2013 at 6:56 PM, John Cowan <[e-mail]> wrote:
> Henri Sivonen scripsit:
>
>> Why not? Surely existing still deployed producers should be what
>> matters when deciding what needs to be ingested--not previous specs.
>> That is, compatibility should be considered in terms of what's out
>> there--not in terms of what unreasonable things were written down in a
>> previous RFC.
>
> In principle, maybe.  But testing a dozen browsers isn't enough here.
> We simply don't know how much non-browser traffic involves JSON (though
> we know there are many such interactions), or what representations they
> are using.  We have therefore decided in the 4627bis effort not to say
> that anything that was previously valid is now invalid.  At least, that
> is what I understand us to be doing.

Even if no one or approximately no one (outside test cases) actually
emits JSON in UTF-32?

>> UTF-32 harms JSON interchange, because Gecko removed all UTF-32
>> support throughout the engine (other engines probably did, too, but
>> I'm too busy to check) and, therefore, XHR responseType = "json"
>> doesn't support UTF-32.
>
> That has about as much weight as "XYZ implementation only supports
> ASCII, so the use of non-ASCII characters harms JSON interchange" or "ABC
> implementation only supports 32-bit integers, so the use of decimal points
> harms JSON interchange."  An implementation's self-imposed limitations
> don't affect the standard.

Well, what (broadly deployed) running code does affects
interoperability regardless of who imposed the behavior. (In this
case, the behavior is imposed by a spec: the XHR spec requires that
JSON be always treated as UTF-8.)

On Thu, Nov 21, 2013 at 7:11 PM, Joe Hildebrand (jhildebr)
<[e-mail]> wrote:
> Specifically, the charter (http://datatracker.ietf.org/wg/json/charter/)
> says:
>
> "Any changes that break compatibility with existing implementations of
> either RFC 4627 or the ECMAScript specification will need to have very
> strong justification and broad support."

"existing implementations" ≠ "existing specs"

I think you should have to show an existing implementation with
substantial deployment that in its substantially deployed
configuration emits JSON in UTF-32 to have a justification for keeping
UTF-32 in the spec.

(I have to wonder what kind of theorizing was the cause of putting
UTF-32 in the spec in the first place. I also have to wonder if the
IETF JSON spec would have supported UTF-64 for completeness if someone
had written an April 1st RFC for UTF-64.)

-- 
Henri Sivonen
[e-mail]
http://hsivonen.fi/