On Nov 15, 2009, at 12:03 PM, John C Klensin wrote: > Hi. > > fwiw, I find myself strongly agreeing with what I believe is > Brian's main point, although what I infer from it may be a > little different from what he does (or may not... I'm not sure): > > 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. 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. A non-HTTP example of that would be a Google wave resource and its ability to compose a tree of wavelets. 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. > The fact that existing mechanisms lack such provisions is not an > excuse when new mechanisms are specified (or even when older > ones are clarified). As a look forward, the comments in this > note are intended as suggested requirements about revisions to > HTTP as well. > > It seems to me that this general goal can be accomplished in any > of the following ways: > > (1) Add an explicit confirmation-handshake mechanism to > PATCH. I don't know what you mean by that. If you mean that the server needs to provide the client with a way to confirm that the PATCH has been applied (or not), then the mechanism already exists. Perhaps the draft just needs to make it obvious that GET on the same URI (with Cache-Control: max-age=0) will do that. If you mean that HTTP should implement 2PC, then forget it. The confirmation of commit is just as likely to be lost as the previous message saying it is okay to commit, so all we would accomplish is doubling the chance of failure. > (2) Add an explicit discussion of how ETAG, or some > other mechanism (such as refetching the page and > checking whether the patch was applied), can be used to > accomplish the purpose of a confirmation handshake. I think you mean "add a discussion of error-handling when the response message is lost due to server or connection failure" to section 2.2. > (3) Add an explicit Security Considerations discussion > about the risks associated with either assuming a patch > has properly occurred without verifying that fact in > some way or of re-issuing a PATCH command without > verifying that it had not been applied. This discussion > must including a discussion of proxies and caches to be > sufficient. How is that a security consideration? > Note that the third is not exclusive of the other two; it would > probably still be desirable and might be necessary. > > Whatever is done, it must be in the document itself and must be > explicit: comments on the mailing list about mechanisms that > might be usable for the purpose are not, IMO, sufficient for a > standards-track document. Perhaps we should add these for discussion in HTTPbis, part 4. Regarding future versions of HTTP, there is no general solution to the lost-confirmation-message problem in distributed networks. The one I described (providing a status URI before the action is attempted) can be done using a standard Link relation in HTTP, HTML, or by using dynamic javascript within the HTML. All of those can be done right now, without changing HTTP. Note that those are more applicable for POST, however, since PATCH is confirmed via GET on the same URI, by definition. If the IESG wants to add such a link relation to Mark's draft currently in last call (I think) or within the link relation registry it defines, I'm all for it. ....Roy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf