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.
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.
(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.
(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.
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.
regards,
john
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
