--On Sunday, November 15, 2009 14:54 -0800 "Roy T. Fielding"
<fielding@xxxxxxxx> wrote:
> On Nov 15, 2009, at 12:03 PM, John C Klensin wrote:
>...
>> We should not be adopting a "patch" protocol that lacks both
>> the tools for, or a serious discussion of, transactional
>> integrity.
>
> John, HTTP is not SQL. The transactional integrity is inside
> the resource implementation. The entire transaction consists
> of a single request message and a single response message.
> HTTP is responsible for the communication interface, not the
> implementation of specific resources, and cannot proscribe a
> specific transaction semantic because it is NOT WANTED by
> many resources.
Roy, I certainly agree with the first part of this. HTTP is not
SQL. If it were, I (at least) would be loudly insisting on an
integrity mechanism. However, normal IETF practice includes
being explicit about issues and traps with specifications. So,
while it is plausible to take the position you express above,
that just about requires that the specification explicitly
indicate that verifying transactional integrity is the
responsibility of the calling application. I'm also suggesting
that it should at least point to ways to do that. The
paragraph in Security Considerations (Section 5) that reads:
"A document that is patched might be more likely to be
corrupted than a document that is overridden in
entirety, but that concern can be addressed through the
use of mechanisms such as conditional requests using
ETags and the If-Match request header."
is not, IMO, adequate in that regard, at least absent a
normative reference. It is also the key to the issue as I see
it: while POST can be used to simulate PATCH, the normal and
obvious use of POST is to supply some information to the server
or to replace ("override") an entire document, PATCH would seem
to have, well, patching as its primary purpose.
> For example, a collaborative whiteboard in which many people
> are patching at once, the patches consisting of context diffs
> that are internally capable of distinguishing conflicts, would
> be impossible to implement via standard etag behavior.
Sure. So say that in the document. My problem is _not_ with
the mechanism, it is with what you apparently assume people will
figure out for themselves or learn through oral tradition.
> Standard etag conflict resolution is not required because
> it is not desirable for many applications of PATCH. For
> other applications of PATCH, it is already defined by HTTP
> and does not need to be reiterated here.
We disagree. I believe it does "need to be reiterated here",
either in-line or by an explicit, normative, pointer to the
relevant portion of the HTTP spec.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf