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

[Vinny A <[e-mail]>]

On Jul 7, 2013, at 1:09 PM, Stephan Beal <[e-mail]> wrote:

>  Streaming or not, enforcing the implied level of infrastructure and potential performance hits which MUST  implies is not something i plan on doing, even if it means not being fully compliant. "Duplicate keys lead to unspecified behaviour," end of story.
> 

The TL;DR of this discussion seems to be that MUST is too restrictive for some (streaming parsers, overhead, etc) yet SHOULD leaves too much space for ambiguity (as it does in the current  RFC 4627).

I'd like to point this list's attention to a post Eliot made a while ago, where he suggested wording that 1) expresses heavy disapproval on an implementation, 2) still allows for an alternative implementation if (1) is not acceptable, 3) is relatively minimal wording (which seems to be a priority given last week's discussions), and 4) has been used in previous RFCs. Here's the relevant comment:

On Jun 5, 2013, at 3:08 PM, Eliot Lear <[e-mail]> wrote:
> Demonstrating my age, an old trick we've done that goes back to RFC-1123
> is to say MUST NOT send, and then implementations MAY NOT process, and
> if they do MUST process thusly...

Could people come to a consensus on this if the proposed wording was similar to the above? I.e "Implementations MUST NOT send duplicate names; if received, parsers MAY NOT process the JSON, instead issuing an error. If implementations insist on supporting duplicated names, they MUST process in the following manner (insert boilerplate warnings about undesirable behavior)." 

-----------------
Vinny
www.jsontest.com