Markus Roberts <[email protected]> writes:
>> >> 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. :)
The great thing about standards is there are so many to choose from, and they
all still suck. :)
Daniel
If there is a custom hack on the PSON encoder then it is probably worth filing
a "one day" ticket to make it ship data without encoding anything outside
ASCII, since that isn't actually necessary and is much less efficient.
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
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.
