Anders Rundgren added the comment: > 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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23123> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com