I'm quite happy for the subject matter experts to decide between
these two approaches.
Thanks
Brian
On 2009-11-27 01:46, Julian Reschke wrote:
Roy T. Fielding wrote:
On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote:
These are the sort of changes that would, I believe, give
Roy T. Fielding wrote:
On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote:
These are the sort of changes that would, I believe, give
sufficient indication to a would-be user of PATCH of how
to make it somewhat safe. Personally I'd prefer to see it
made more prominent by starting with
I've added extra explanatory text in section 2 as well as the Security
Considerations section. It's normative, but dependent on the use case
being appropriate, which gives emphasis to the implementor but still
allows the right thing to be done.
Lisa
On Fri, Nov 13, 2009 at 4:16 PM, Brian E
I agree that a mechanism for atomicity would be nice.
I also agree that POST is in a sense a superset of PATCH.
So if I want a mechanism such as 2-phase commit I really would want it
for POST as well as PATCH, more so really. So I don't want to see the
issue addressed in PATCH if it is addressed
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-i...@jck.com wrote:
--On Sunday, November 15, 2009 14:54 -0800 Roy T. Fielding
field...@gbiv.com wrote:
On Nov 15, 2009, at
Roy,
At this point I think we're arguing in a circle, so I will
simply wait to see what the authors and Area Director want to
do next. A Gen-ART review has no more standing than any other
Last Call comment.
Regards
Brian Carpenter
On 2009-11-18 15:18, Roy T. Fielding wrote:
On Nov 17, 2009,
John C Klensin wrote:
...
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
--On Tuesday, November 17, 2009 15:27 +0100 Julian Reschke
julian.resc...@gmx.de wrote:
John C Klensin wrote:
...
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
John C Klensin wrote:
...
1) the client can't control whether the etag will be strong,
and weak etags may work just fine in certain instances, so
just be silent about the type
Silent, no. But saying can't control... certain instances
explicitly would be fine. I'd be even happier with an
These are the sort of changes that would, I believe, give
sufficient indication to a would-be user of PATCH of how
to make it somewhat safe. Personally I'd prefer to see it
made more prominent by starting with something like:
Clients requiring to verify the consistent application of a
patch
On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote:
These are the sort of changes that would, I believe, give
sufficient indication to a would-be user of PATCH of how
to make it somewhat safe. Personally I'd prefer to see it
made more prominent by starting with something like:
Clients
--On Sunday, November 15, 2009 14:54 -0800 Roy T. Fielding
field...@gbiv.com 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
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,
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
On 11/15/09 11:54 PM, Roy T. Fielding wrote:
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
Brian,
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
On 2009-11-13 20:19, Julian Reschke wrote:
Brian E Carpenter wrote:
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
Brian E Carpenter wrote:
On 2009-11-13 20:19, Julian Reschke wrote:
Brian E Carpenter wrote:
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
Julian,
On 2009-11-13 23:35, Julian Reschke wrote:
Brian E Carpenter wrote:
On 2009-11-13 20:19, Julian Reschke wrote:
Brian E Carpenter wrote:
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
On Nov 13, 2009, at 2:26 PM, Brian E Carpenter wrote:
On 2009-11-13 23:35, Julian Reschke wrote:
Brian E Carpenter wrote:
On 2009-11-13 20:19, Julian Reschke wrote:
Brian E Carpenter wrote:
As far as I can tell, the proposal places the burden for ensuring
atomicity entirely on the server.
Roy,
Just a couple more comments below, and then I will have
said all I can usefully say.
On 2009-11-14 12:57, Roy T. Fielding wrote:
On Nov 13, 2009, at 2:26 PM, Brian E Carpenter wrote:
On 2009-11-13 23:35, Julian Reschke wrote:
Brian E Carpenter wrote:
On 2009-11-13 20:19, Julian Reschke
On Nov 13, 2009, at 4:16 PM, Brian E Carpenter wrote:
On 2009-11-14 12:57, Roy T. Fielding wrote:
On Nov 13, 2009, at 2:26 PM, Brian E Carpenter wrote:
I wasn't involved in reviewing RFC2616 (or in the original design of POST,
even though it happened about 20 metres from my office at that
On Fri, 13 Nov 2009, Roy T. Fielding wrote:
Yes, and that is exactly what would happen even if HTTP supported
full two-phase commit, with all of its painful consequences, if the
response to commit was lost. This is an application problem, not
a protocol requirement. It can be fixed (to the
Brian E Carpenter wrote:
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
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:
25 matches
Mail list logo
