>> A JSON "message" is explicitly specified to be a UTF-8 encoded string of > >> characters, so anything that tries to convey data outside that encoding > >> should rightly be pushed back by upstream. > > > > That's not the issue. > > > > We aren't talking about the message here, but the values of string fields > > inside the messages. They are supposed to be able to contain arbitrary > > binary data, and JSON even defines escapes (\x##, \U####, \###, etc.) for > > representing such data. > > Not by my reading of RFC 4627 they are not: 2.5 defines a string as a > sequence > of 'char' entities between double-quotes; char has escaped versions of > Unicode > code-points, not arbitrary binary data: > > All Unicode characters may be placed within the quotation marks except > for > the characters that must be escaped: quotation mark, reverse solidus, and > the control characters (U+0000 through U+001F). >
Hmm. You are correct (I was using the mozilla definition, not the RFC which is, to my surprise, far more restrictive). Given that, I'll stop trying to push the fix upstream. This also means that strict JSON doesn't fit our needs. Fortunately, PSON does -- by definition. :) -- Markus ----------------------------------------------------------- The power of accurate observation is commonly called cynicism by those who have not got it. ~George Bernard Shaw ------------------------------------------------------------ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
