spec needs to clarify behavior in the case of duplicate JSON keys

In section 2.2 of RFC 4627 (http://www.ietf.org/rfc/rfc4627.txt) it states that :

"An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique."

The SHOULD in the last sentence means that "if implementations think they have a valid reason, they can have duplicate names in an object". If you search the net you can find a number of different strategies for dealing with duplicate names/keys. To improve interoperability, CAMP needs to clarify its position with respect to duplicate keys.

High-level proposal: CAMP should further constrain RFC 4627 by saying that clients and the servers MUST NOT send JSON that contains duplicate keys. The clients or servers response to a message containing multiple keys should be left undefined - i.e. CAMP should not require servers to send an error response if/when they detect multiple keys.