[apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00

[Mike Acar <[e-mail]>]

Hi,

I've been asked to review the JSON Pointer and Patch draft RFCs. I've 
had some discussion about them off-list, and have been advised to bring 
my issues to the list. And so, I am. :)

I've scanned the archived list discussion of the patch and pointer RFCs, 
so I don't think these issues have come up here already. Let me know if 
they have.

The first issue is comparing Unicode strings. Section 4 of 
http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00 says

       If the currently referenced value is a JSON object, the new
       referenced value is the object member with the name identified by
       the reference token.

That is, if the reference token equals the name of some value within the 
object, move to that value. However, the tokens and values are Unicode 
strings; I'm not an expert in Unicode, but my impression is that testing 
Unicode strings for equality is not as simple as comparing sequences of 
bytes. For example, there are linguistic considerations: I believe 
German ö and oe are considered identical.

There's also the question of JSON documents with different encodings; 
UTF8 is the default, but UTF-16 and -32 with both endiannesses are also 
supported. Presumably this question will disappear in practice, since 
implementations will operate on deserialized data structures, not on 
JSON texts.

Could somebody with more expertise in this area comment? Perhaps this is 
all a solved problem, and the Pointer RFC simply needs to pick a 
normalization method and equality definition - or perhaps it's all so 
well-settled I'm seeing a problem where there is none.

Another issue is that the evaluation scheme implies some application 
semantics. Again, section 4:

    If a reference token is being evaluated against a concrete JSON
    document, the implementation MAY evaluate each token against a
    concrete value, and terminate evaluation with an error condition if a
    evaluation fails to resolve a concrete value.

It's easy to imagine a case where a Pointer refers to a deep hierarchy, 
e.g. /a/b/c/d, and the application semantics of following it are to 
create automatically any non-existent intermediate objects.

My initial thought was that the Pointer RFC should explicitly say that 
specs which use it (e.g. Patch) should define semantics for ambiguous 
cases (non-unique or non-existent member names, array index out of 
bounds, etc). That can still result in a user of Pointer having to 
implement it himself, if there are no implementations which offer him 
precisely what he needs.

Is it preferrable to explicitly say "You must make these decisions for 
your use case" instead of "Behavior in these cases is undefined"?

-- 
Mike Acar -                                 - macar at cloudmark dot com