Hi Carsten, I wasn't really looking for a defense of the design in the form you just provided, cogent as it was. I want to know what value you get from these extensibility features, not a reiteration (and expansion) of the characteristics of those features.
My operating assumption was that JSON was successful precisely because it was only extensible in one limited direction. In some ways, this is the challenge I wanted to set by writing my review. Can you a) invalidate that theory somehow, and b) motivate the addition of each axis of extensibility. As I said privately, I have no problem with shipping a proposed standard RFC that has a clear set of goals, and I think that you are doing the right thing in that regard. What I really want to do is have is that other conversation. And maybe long review threads are the wrong place for that conversation, I don't know (maybe I'll drop gen-art on my next reply). On 12 August 2013 20:28, Carsten Bormann <[email protected]> wrote: > CBOR maps are intended to be maps, not multimaps. Duplicate keys are > an encoding error. Unfortunately, what should be considered duplicate > is often application dependent (are 0 and 0.0 the same key? "Å" and > "Å"?), so a generic parser will only be able to do part of the work. Ouch, really? Add this to the list of things that a using application/specification needs to worry about. SASLprep anyone? Maybe there should be a list of those somewhere in the draft, which includes: The types to implement (and whether to disallow or ignore others) What map keys to permit and how to compare them (with a special note about IEEE 754 NaN values, which might be bit-exact, but don't compare equal) The extension points to implement (and how to ignore 28-30) Whether to allow tags Which tags to ignore What date format(s) to use What to do about JSON if you are performing translation (see tags) What types to permit indefinite length encoding for ... and I'm sure I've missed something --Martin _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
