Pseudo-JSON with unquoted property names

David-Sarah Hopwood david-sarah at
Fri Jun 5 19:19:03 PDT 2009

Robert Sayre wrote:
> On Fri, Jun 5, 2009 at 6:57 PM, David-Sarah
> Hopwood<david-sarah at> wrote:
>> Accepting unquoted names is pretty harmless from a security point of view,
>> and does not add signficant specification or implementation complexity
> JSON is a wire format that enjoys good interoperability.
> Allowing unquoted names would result in documents that break many
> implementations on

How? The ES5 JSON emitter would never produce such documents.

The only circumstance under which this could happen is if people test
some other JSON emitter only with the ES5 JSON parser, and therefore
don't notice the nonconformance in that other emitter. But those
people are
a) negligent for only testing with one other implementation, and
   for not paying attention to the JSON spec;
b) just as likely to test only with some other existing JSON parser
   that accepts unquoted property names [*], and still not notice.

If it were not the case both that:
 - a very large proportion of JSON parsers already accept unquoted
   property names,
 - and that there is evidence of pseudo-JSON causing interoperability
   problems in practice,

then I wouldn't be making this proposal. In that situation, one of
the general objections that I have to Postel's liberality rule --
that it can hide nonconformance and so effectively reduce
interoperability due to the testing issue above -- would apply.
(The other objections, that it tends to increase implementation
complexity and can introduce security flaws, do not apply to this
particular set of nonconformant inputs.)

But that objection loses its force when the horse has already bolted
as far as unquoted property names being widely accepted (and "widely"
is sufficient for this argument) by other JSON parsers.

[*] such as the one that we are basing this API on, json2.js, for example.

> And it would break people using eval in
> some other langauages, but don't allow unquoted names. A more liberal
> "parseObjectLiteral" capability might be nice for a future standard.
> This would even break Firefox 3's JSON functionality (used internally
> and available to extensions).

Again, how?

I think I was clear enough in saying "accept but not generate".

David-Sarah Hopwood  ⚥

More information about the es5-discuss mailing list