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

[Eliot Lear <[e-mail]>]

Hi Nico,

On 7/3/13 8:45 AM, Nico Williams wrote:
> 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).

You've got to retain state.  You don't have to retain the value, but you
do have to retain the name.  It's O(k), and knowing you I know you're
smart enough to approach that (because I am and so I'm using inductive
theory ;-).  And I'll bet you a nickel that this is not going to be
anyone's high order bit.
>
>> "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.

That's a fair point about security, but even in THAT context one should
be conservative in what one sends.  And yes we CAN be more exacting, but
at a cost.  What we're debating is the cost of ambiguity.

>
> 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.

Nothing to be done about installed base, as I wrote.  Let's write down
what the right thing to do is.  These are RFCs we're generating, now laws.
>
> 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.
>

WGs often retread.  Sometimes we find ways to get around our blocks.  We
both have no time for blame.

Eliot