Re: [Json] The names within an object SHOULD be unique.

["Matt Miller (mamille2)" <[e-mail]>]

Nico, would you clarify your proposal to indicate place or places in 4627bis-02 your text replace or append to?

With regards to parsers types elsewhere in this, while I also think there might only be two, Paul does raise an interesting point about keeping the extra terms to a minimum.  I think we can further refine the language as long as we're clear where and how this proposal fits.


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.

On Jun 6, 2013, at 4:39 PM, Nico Williams <[e-mail]> wrote:

> On Thu, Jun 6, 2013 at 5:33 PM, Matt Miller (mamille2)
> <[e-mail]> wrote:
>> On Jun 6, 2013, at 4:21 PM, Nico Williams <[e-mail]>
>> wrote:
>>> [...]
>> 
>> Note that so far, the document uses the term "name", not "key".  I think the following needs to substitute "key" with "name" to be consistent.
> 
> Ah, sure.
> 
>>>  Encoders SHOULD NOT send duplicate keys.  Some encoders might not
>>> be able to prevent duplicate keys.  Therefore parsers MUST be prepared
>>> to handle duplicate keys.
>>> 
>>>  Stateful parsers MUST accept [use?] only the last of any set of
>>> duplicate keys.
>>> 
>> 
>> I think this still needs to allow for stateful parsers that reject duplicate keys (for which there are some).
> 
> That's fair.
> 
>> Maybe:
>> 
>> ####
>> 
>> Stateful parsers MAY reject duplicate names. However, if duplicate names are accepted, it MUST accept only the last value of any set of duplicate names.
> 
> Sure.  I think we should define terms like "stateful parser" and
> "streaming parser".
> 
>> ####
>> 
>>>  Some parsers might not be able to detect duplicate keys, much less
>>> pick only the last of them.  Here a "stateful parser" is one that
>>> keeps on hand all of the values it decodes, as it decodes them.  Note
>>> that accepting duplicate keys presents potential security risks.  Note
>>> that sending duplicate keys risks data loss (that is, the loss of all
>>> but the last of a duplicated key's values).
>>> 
>> 
>> Can we describe a couple of specific security risks that are incurred?  I think one would be something like overwriting of the original value by an attacker intercepting the exchange.
> 
> I'm not concerned about MITMs and such.  I'm concerned about attacks
> where we have a validator of some sorts as a filter and then a final
> consumer.  The sender might send JSON that the validator accepts as
> valid, that will be passed on to the final consumer, and where the
> consumer will receive a different document (from it's p.o.v.) than the
> validator saw.
> 
> Nico
> --
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json