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

[Nico Williams <[e-mail]>]

On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear <[e-mail]> wrote:
>> In short, for streaming parsers (and generators) there's nothing we can do.
>>
>> What we can do is RECOMMEND that a) generators not produce duplicates
>> (and explain how streaming ones cannot prevent dups), and b) that
>> parsers use the last name (and explain how streaming ones will produce
>> all dups).
>
> To me this isn't strong enough.  I have some sympathy for both the
> existing base and for parsers, but generators as an architectural
> component should generate unambiguous output, streaming or otherwise.
> And that follow's Postel's Law:

How can a streaming generator do that?  The API for one might look like:

ObjectStart(context)
ObjectAdd(context, name, value)
...

There's no way a minimal-state streaming generator (but I repeat
myself; the whole point of a streaming interface is to keep minimal
state :) can detect duplicates with O(1) state (probabilistic
structures with false positives won't be acceptable either).

> "In general, an implementation must be conservative in its sending
> behavior, and liberal in its receiving behavior."

I've seen this maligned too.  How many times have we heard this as a
root cause of security vulnerabilities on receiver sides?  We should
be much more exacting, but in *this* case we can't be.

It's not a question of what is ideal...  If we were starting from
scratch we might forbid O(1) state generators and even parsers.  But
it's too late for that and we have consensus to achieve.

BTW, we're retreading.  We should try not to, but it's difficult to
avoid as no one can have read *every* post since the WG's inception.
I think it's fair to say that on this issue there's no consensus to
ban the bad behavior (duplicate names).  Please don't blame me for
that lack of consensus.

Nico
--