Re: [Json] Proposed minimal change for duplicate names in objects

[Bjoern Hoehrmann <[e-mail]>]

* Matthew Morley wrote:
>#1 I guess. Duplicate keys *SHOULD* fail, IMHO.
>
>I feel like I am being disruptive by posting this, but I really think we
>are going down a path of splitting hairs and missing the broader point of
>this issue. All the same, I'm posting as a reply to the initial thread
>post, instead of all along the chain of replies.

The broader point here is that the Working Group is supposed to document
the JSON format based on running code and rough consensus and changes to
what is in RFC 4627 require very strong justification and support. That
means duplicate names in objects will be permitted and parsers will not
be required to detect and report duplicate names.

Relying on duplicated names is a bad practise, and for parsers that
report only one of the names, it is a good practise to pick the last in-
stance, and of course parsers are always free to reject any content for
security reasons as they see fit, this's all largely agreed in the group
and people do not care terribly much how the specification conveys this.

I for instance would prefer telling people that picking the last value
is the logical and typical choice and the behavior of standard APIs like
JSON.parse and picking the first one or a random one instead is sure to
cause interoperability, security, migration, and other headaches -- over
fiddling with RFC 2119 keywords, but in the end it does not really have
an effect on how people are going to use and implement JSON in the wild.

We know all the open questions, as far as I am concerned we could just
write them all down and survey the Working Group; one implied question
above, as an example, is

  JSON parsers that treat objects with duplicate keys as malformed
  for security reasons should be made non-conforming in JSONbis.

I would strongly disagree with that and am quite sure other participants
would do the same; in studying the survey results the chairs might find
there is indeed a rough consensus JSON parsers should be allowed to re-
ject such JSON documents for security reasons, and then task editors or
whoever volunteers with implementing that in the specification prose.
Same for all the other issues, say

  Allow Unicode Signature in UTF-8 encoded application/json entities.

  Allow Strings at the top level.

  ...

Then we would be getting somewhere...
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/