Re: [Json] What are we trying to do?

Excellent points, Tim! I support this.

Sent from my iPad

On 3 Jul 2013, at 07:01, Tim Bray <tbray@textuality.com> wrote:

> I’m having trouble dealing with the recent proposals from our co-chairs because I don’t think I understand what they’re trying to achieve.  Just to refresh, our charter says 
> 
> “The work is essentially a reclassification in place, with minimal changes. The working group will   eview errata and update the document as needed to incorporate those, and will correct significant  errors and inconsistencies, but will keep changes to a minimum.
> 
> It is acknowledged that there are differences between RFC 4627 and the ECMAScript specification  in the rules for parsing JSON. Any changes that break compatibility with existing implementations of  either RFC 4627 or the ECMAScript specification will need to have very strong justification and broad support. ”
> 
> The changes proposed by the chairs are pretty big. Maybe the problem is that any change which would actually CORRECT the two biggest errors/inconsistencies in 4267 would necessarily be pretty significant. When your charter is self-contradictory, you can either re-charter or decide to ignore one of the two contradictory directives.
> 
> I was getting really comfortable with the minimal proposal, which noted that while the spec more or less means what it says (strings should be Unicode, objects should have unique keys), there are other standards with different interpretations.  Also, there is variation among observed behavior in software, when the JSON RFC’s high-level directives are contravened.
> 
> What the industry really needs is a document normatively describing JSON-as-best-practiced, with an RFC number.  It would say that senders MUST NOT do X and Y, and that receivers, upon encountering X OR Y, MUST DO Z.  Thus  other spec writers can say “Do what RFCXXXX says” and not have to resort to the sort of drafting pain that the people in Jose are experiencing right now in order to avoid attacks on cryptographically signed protocol elements by exploiting variation in dupe-key handling.
> 
> Is it the sense of the WG that such a document is within our mandate?  -T
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json