ietf
[Top] [All Lists]

Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

2013-01-07 10:26:41
On Sun, Jan 6, 2013 at 8:15 PM, Robert Sayre <sayrer(_at_)gmail(_dot_)com> 
wrote:

On Sun, Jan 6, 2013 at 4:01 PM, Robert Sayre <sayrer(_at_)gmail(_dot_)com> 
wrote:
On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan <pbryan(_at_)anode(_dot_)ca> 
wrote:


Common concurrent editing algorithms should, in my opinion, use
techniques
to ensure the state of the resource (relative to the edits) is known. In
HTTP, we have ETag and If-Match/If-None-Match preconditions. In JSON
Patch,
we have (a rudimentary) test operation.
...
links to make sure we're not talking past each other:

Actually, let me restate my point in terms of RFC5789 (HTTP PATCH).
That will make it easier to communicate.

RFC 5789 Section 2.2 (Error Handling) defines error conditions which
correspond directly to the point at hand: 'Conflicting state' and
'Conflicting modification'. Section 5 of the JSON Patch document
directly references RFC5789, Section 2.2.

With that in mind, let's note that there are several normative
requirements in the JSON Patch document directed at conflicting state.
One such example is from Section 4.2 'remove'. It reads: "The target
location MUST exist for the operation to be successful.". If a server
received an HTTP JSON Patch request attempting to delete a
non-existent location, this text from RFC5789 would seem to apply:

"Conflicting state:  Can be specified with a 409 (Conflict) status
      code when the request cannot be applied given the state of the
      resource.  For example, if the client attempted to apply a
      structural modification and the structures assumed to exist did
      not exist ..."

The text above wouldn't be necessary in JSON Patch or RFC5789 if
RFC5789 required checking ETags and preconditions for all use cases
(it doesn't). The larger point is that RFC5789, and patch formats in
general, make all sorts of allowances for *non-conflicting* concurrent
edits to a common ancestor. The problem with leaving this JSON Pointer
array ambiguity in the draft is that patch messages which should
trigger '409 Conflict' errors can be mistakenly and 'successfully' (in
the HTTP sense) applied to a different structure than intended.

In summary, the JSON Patch draft allows patch documents to be
formulated that make it impossible to correctly implement RFC5789, a
normative reference.

Here are the questions the IESG focuses on during review:
"Reviews should focus on these questions: 'Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?'"

For JSON Patch, the answer to the first question is 'no', because of a
deficiency in JSON Pointer. The change needed to make these documents
acceptable as part of the Internet infrastructure is to make Arrays
explicit in JSON Pointer syntax.

- Rob


For me the deficiency is not in the pointer, but patch format being
generated.

One approach is to push that *one* test, structure conformity, into the
pointer syntax. Another is via the type operation.

If a vague patch is generated, vague results are to be expected.

Testing for *just* the structure does not really create a verbose patch
either. Which is why I am not overly in favor of a syntax specific to
arrays, with this argument.

For example, if you are replacing a key in a object, the json-pointer to
get there, *and* the value would be required to ensure it is not
vague. Setting /a/b/c to 6 when it was 4, and applying that patch without
such tests to a document where /a/b/c is 13, is also vague.

Without tests, the patch format is optimistic at best, there is no escaping
this fact. Changing the spec for the json-pointer syntax to address
vagueness in json-patch specification seems wrong to me.

If json-pointer is not well suited, because of the desire for a descriptive
path which includes structure and value, perhaps a different specification
is need. One that provides both path, structure, and value confirmation in
the pointer string. Though at that point is more of a query path, so
something like JsonPath (http://goessner.net/articles/JsonPath/)?

I prefer the test/type operations and the json-pointer specification, with
optimistic patches.

-- 
Matthew P. C. Morley
<Prev in Thread] Current Thread [Next in Thread>