On Sun, Jan 6, 2013 at 4:01 PM, Robert Sayre <sayrer@xxxxxxxxx> wrote:
> On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan <pbryan@xxxxxxxx> 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