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

This feels like a no-brainer to me, but that’s probably because (as I’ve
said before) I’m an API guy, and the only use for JSON objects in my world
is to transfer a hash table or database record or whatever from here to
there, and there, and in such a situation dupes can never be useful or
intended and can only be a symptom of breakage (or, in the JOSE case, a
symptom of a malicious attack on my crypto).

-Tim

On Sat, Jul 6, 2013 at 6:20 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Sat, Jul 6, 2013 at 7:13 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> > Tim is not the only person saying this.  The JOSE working group has this
> as
> > a requirement to be enforced in the documents it is producing.
> > Specification that JOSE objects MUST fail validation if there are
> duplicate
> > names in an object.
>
> But does it follow (did you even mean to say) that since JOSE wants
> requirement X (no dup names here) JSON should have it itself?
>
> One might argue that otherwise JOSE implementations would have to use
> JSON parsers that implement JOSE's requirement even though JSON
> doesn't have the same requirement.  But then. JOSE implementations
> also could use streaming JSON parsers and check for dup names
> themselves.  So I don't think JOSE's requirement adds anything new to
> the discussion.
>
> We still need to decide (directly or indirectly) whether to impose dup
> name checking on all JSON parsers, even minimal-state streaming
> parsers, whether we want to impose a requirement on the parser and the
> application (so we need not mention streaming), or on the parser if
> it's not a streaming parser *and* the application if the parser is
> streaming.
>
> My view (for whatever it counts) is that we don't have consensus [yet]
> for imposing a requirement on parsers to reject objects with dup
> names.  We've had at least a number of examples of streaming parsers
> that cannot implement such a requirement -- the whole point of
> streaming being nullified by state-keeping requirements like this one.
>  So we'd have to explicitly decide that we don't want to allow minimal
> state streaming parsers.  Might as well call for consensus on that.
>
> Nico
> --
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>