> Antoine Pitrou added the comment:
> 
> "To cope with this potential problem, compliant parsers must preserve the original textual representation of properties internally in order to support JCS normalization requirements"
> 
> That sounds ridiculous. Did someone try to reason the "IETF guys"?:)

The alternative is either doing what Bob suggested which is almost the same as writing a new parser or take the IETF route and shroud the message payload in base64.

So all solutions are "by definition" baaaaaaaaaaaaaaaad :-)

FWIW my super-bad solution has the following compatibility issues:
- Whitespace: None, all parsers can "stringify", right?
- Escaping: None, all parsers MUST do it to follow the JSON spec.
- Property order: A problem in some parsers.  If you take a look on stackoverflow lots of folks request that insertion/reader order should be honored since computers <> humans.  Fixed in Python. Works in browsers as well.
- Floating point: an almost useless JSON feature anyway, it doesn't work for crypto-numbers or money.  It is "only" a validation problem though.  Now fixed in Python.

http://www.ietf.org/mail-archive/web/acme/current/msg00200.html