couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kris Zyp <>
Subject Re: JSON Patch Internet Draft 01
Date Fri, 10 Jun 2011 03:23:12 GMT
On 6/9/2011 5:28 PM, Paul C. Bryan wrote:
> On Thu, 2011-06-09 at 17:56 -0400, Paul Davis wrote:
>> >  In the JSON Pointer RFC it states that path components SHOULD be URI
>> >  encoded and that "/" MUST BE uri encoded but in the algorithm
>> >  description for moving the reference pointer there's no language on
>> >  URI-decoding the path component. Also I have no idea how this would
>> >  play with utf-8 or other unicode representations. Perhaps just
>> >  escaping any "/' characters would be enough here though that could get
>> >  confusing as it'd be "\\/" in all the examples.
>> >
>> >  Okay, I think I'll write-up process for encoding and decoding so as to
>> >  clarify. In a nutshell, to decode, break into tokens using "/" separator,
>> >  then URL-decode each fragment. Make sense?
>> My bigger concern is what to do about unicode in JSON strings though.
>> URI encoding is specified at the byte level where as JSON strings are
>> specified as a list of "any unicode character". Plus this is affected
>> by internal representation of unicode. The issue is to figure out how
>> to make the JSON diff not have to do tricky things that would need to
>> extend some major definitions of JSON.
>> This is why I was toying with the idea of using an escaped solidus
>> character at the application level. By not converting characters we
>> neatly avoid the issue of how to transform various types of unicode
>> representations into other types of unicode representations in this
>> spec. The only downfall of this method is that at the transport layer
>> (ie, as JSON) the application level escape reads as "\\/" or "\\//".
>> Another method (though unatractively verbose) would be to list the
>> path as an array of strings and or integers. Which would also nicely
>> disambiguate for cases like {"1": "some stuff"}. Also that brings up
>> an error scenario that might need to be spec'd.
>> Paul Davis
> Ah, I see. A couple of possibilities come to mind (which I note may be 
> combined):
> 1. We specify URL encoding is on UTF-8 encoding of the token.
I believe UTF-8 encoding for URLs is already mandated by RFC 3986.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message