You won't believe what happened next: RFC 6902 comes along and explicitly prohibits multiple keys. Programmers want to reuse JSON parsers, but can't. This is not a good position to be in.
RFC 6902 is not a standard for JSON, it's a standard for "JSON patch", which appears to be another data format layered on top of JSON. It has no descriptive power on JSON in general.
The relevant RFC is 8259, which neither explicitly allows nor prohibits duplicate keys. Instead it says:
> An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.
That isn't a prohibition on duplicate keys, it's just a warning on what will happen in practice if you try to do that.
Thanks! I was commenting just from the perspective of JSON in general, didn't check the JMAP spec.
(Does JMAP require validating that the input is valid I-JSON? Or does it just say that a JMAP endpoint is allowed to assume it's I-JSON, but doesn't need to validate it?)
