I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-dusseault-http-patch-15.txt
Reviewer: Brian Carpenter
Review Date: 2009-11-12
IETF LC End Date: 2009-11-24
IESG Telechat date:
Summary: Issue with transactional integrity
--------
Comment:
--------
I have not had time to follow all the Last Call comments on the IETF list.
Apologies for any overlap.
Major issues:
-------------
As far as I can tell, the proposal places the burden for ensuring
atomicity entirely on the server. However, PATCH is explicitly not
idempotent. If a client issues a PATCH, and the server executes the PATCH,
but the client then fails to receive an indication of success due to
an extraneous network glitch (and TCP reset?), then what prevents the client
issuing the same PATCH again? In other words, absent a two-phase commit,
there appears to be no transactional integrity.
If I have understood this correctly, PATCH is not only not safe in
the RFC2616 sense, it is not transactionally safe either, so the state
of the resource after {PATCH, lost response code, PATCH} is undefined.
I don't believe that the non-normative words starting "Clients wishing to
apply a patch document to a known entity..." are anything like enough to
fix this problem. I don't know enough to know whether some normative text
using ETag is sufficient (it's clear from the draft that If-Unmodified-Since
is insufficient). This doesn't seem easy to fix without adding a
"ready to commit"/"commit" exchange, which also needs transaction IDs
(perhaps based on strong ETags) and a new state machine at each end.
I'd be glad to learn that I'm missing something._______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf