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

Henri Sivonen scripsit:

> > I think it's fair to object to requiring sniffing, and I support not
> > requiring it.  I don't see anything wrong with leaving those in for
> > those who want to include support for it.
> 
> Optional features are a trap. 

No doubt.  But what's stated in the RFC is given as a matter of fact,
with no MUST, SHOULD, or even MAY.  Since we have adopted a change
which makes it no longer factual, we should IMO revise it so it is
again factual, and leave it at that.

> The notion that in theory, maybe, someone might use a non-UTF-8
> encoding for something, 

Not "might use", but "may already be using".

>  * Accepting your analogy leads not only to supporting UTF-32 but also
> to supporting various non-UTF encodings, which would be even worse
> than suggesting that UTF-16 and UTF-32 be supported in addition to
> UTF-8.

They are already banned by the SHALL in section 3.

> Of course, such testing takes work, so banning UTF-16 and UTF-32 would
> avoid such work. :-)

Banning unpaired surrogates, non-integers, etc. etc. would have saved
us work too.

-- 
John Cowan  <cowan@ccil.org>  http://ccil.org/~cowan
Micropayment advocates mistakenly believe that efficient allocation of
resources is the purpose of markets.  Efficiency is a byproduct of market
systems, not their goal.  The reasons markets work are not because users
have embraced efficiency but because markets are the best place to allow
users to maximize their preferences, and very often their preferences are
not for conservation of cheap resources.  --Clay Shirky

Received on Wednesday, 27 November 2013 17:23:15 UTC