I agree with John on this one.
We do not need to provide the mechanism, we do need to provide the warning.
On Mon, Nov 16, 2009 at 10:24 AM, John C Klensin <john-ietf@xxxxxxx> wrote:
>
>
> --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
>
--
--
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf