Subject: [core] 🔔 WG Last Call of draft-ietf-core-etch-01

From: Jaime Jiménez <[email-masked]>
Date: Mon, 27 Jun 2016 17:32:02 +0000

Hi all,

This is the Working Group Last Call for the "Patch and Fetch Methods for Constrained Application Protocol (CoAP)” document.

https://tools.ietf.org/html/draft-ietf-core-etch-01

An HTML version is available at: https://core-wg.github.io/etch/

The call is planned to end by July 11th.

BR,
- - Jaime Jimenez

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 28 Jun 2016 18:40:48 +0200

I've reviewed draft-ietf-core-etch-01.

I'm not convinced that two PATCH methods are needed, because the
idempotency of the request really depends on the idempotency of the
patch and not on the method: if the repeated application of the patch
leads to the same result, then the request is idempotent; otherwise,
it's not. I don't see the benefit of repeating this bit of information
in the request method.

Two methods are a problem when mapping HTTP PATCH to CoAP
PATCH/iPATCH: The proxy would need to analyze the patch in the HTTP
request to determine if the HTTP PATCH can be mapped to CoAP iPATCH of
if CoAP PATCH has to be used. The proxy cannot just map to CoAP PATCH
always, because the CoAP server might only support iPATCH but not
PATCH even if the patch itself is actually idempotent.

Apart from this, I think the draft is ready for publication.

Klaus

---

From: Michel Veillette <[email-masked]>
Date: Tue, 28 Jun 2016 17:32:24 +0000

I agree with Klaus, the Content-Format might be a better indication of the idempotency of the request.

Michel

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: Tuesday, June 28, 2016 12:41 PM
To: Jaime Jiménez <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] 🔔 WG Last Call of draft-ietf-core-etch-01

I'm not convinced that two PATCH methods are needed, because the idempotency of the request really depends on the idempotency of the patch and not on the method: if the repeated application of the patch leads to the same result, then the request is idempotent; otherwise, it's not. I don't see the benefit of repeating this bit of information in the request method.

Two methods are a problem when mapping HTTP PATCH to CoAP
PATCH/iPATCH: The proxy would need to analyze the patch in the HTTP request to determine if the HTTP PATCH can be mapped to CoAP iPATCH of if CoAP PATCH has to be used. The proxy cannot just map to CoAP PATCH always, because the CoAP server might only support iPATCH but not PATCH even if the patch itself is actually idempotent.

Klaus

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Andy Bierman <[email-masked]>
Date: Tue, 28 Jun 2016 12:00:32 -0700

Hi,

I agree is well.
Each patch format will define its own editing mechanisms.
I do not think iPATCH is needed.
The client should use If-Match if it really cares about not applying an
edit more than once.

Andy

On Tue, Jun 28, 2016 at 10:32 AM, Michel Veillette <
[email-masked]> wrote:

> idempotency of the request really depends on the idempotency of the patch
> and not on the method: if the repeated application of the patch leads to
> the same result, then the request is idempotent; otherwise, it's not. I
> don't see the benefit of repeating this bit of information in the request
> method.
>
> request to determine if the HTTP PATCH can be mapped to CoAP iPATCH of if
> CoAP PATCH has to be used. The proxy cannot just map to CoAP PATCH always,
> because the CoAP server might only support iPATCH but not PATCH even if the
> patch itself is actually idempotent.
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 Jun 2016 22:24:03 +0200

> it's not. I don't see the benefit of repeating this bit of information

The request method is an indication of the intent of the client.
The server can make use of the information encoded in this intent.

If you only ever implement less-constrained (and not-so-high-speed)
servers and proxies, that information may not be very useful.  Both for
constrained and high-speed implementations, it is an advantage to know
when a request is intended to be idempotent.

> PATCH/iPATCH: 

It is not really a problem: A HTTP-to-CoAP cross-proxy doesn't know the
intent, so it will have to use PATCH (unless there is some other way to
derive that intent).

> The proxy would need to analyze the patch in the HTTP

The server might not even support iPATCH, either.  I don't think one
should expect a proxy to do method translation.  (Well, it may be a nice
differentiating feature, which is easy to implement if the proxy happens
to know that the media type used in the PATCH request only supports
idempotent operations, e.g. for RFC 7396 merge-patch.)

An obvious way to "solve" this problem would be to require a server that
supports iPATCH to always support PATCH as well.

I think much of the cognitive dissonance here comes from the fact that
the best place to carry this bit of information is the method code, and
REST traditionally has been using only four methods, so adding three
codes in one extension may seem a lot.  (HTTP actually has methods like
HEAD, which is just an optimized variant of GET, so this isn't even new
territory.)

> Apart from this, I think the draft is ready for publication.

Thank you for reviewing this draft.

Grüße, Carsten

---

From: Christian Groves <[email-masked]>
Date: Wed, 29 Jun 2016 12:03:22 +1000

Hello Jaime,

Below are my review comments:

Cl.1.1 Para 2 editorial: ...request body than can comfortably <be> 
transferred....

Cl.2.1: The reference 5.9 seems to point to a non-existing clause in the 
draft.

Cl.2.2.2 Editorial: Extra "." after 5.10.6

Cl.3 Para 2: The hyperlink in the reference to section 5.10.8.1 points 
to an invalid location.

Cl.3.1: "Content-Format: application/json-patch+json" does this need a 
to be formatted "Content-Format: 51 (application/json-patch+json)" as 
per the other examples?

Cl.3.2 and Cl.3.3: The hyperlinks point to the current document rather 
than the referenced RFC7252.

Cl.3.2: Should this indicate that the draft specifies additional 
response codes?

Cl.3.4 Unprocessable request: "," should be "." on the end of the second 
bullet.

Cl.6: Response code "4.22 (Unprocessable Entity) seems to be missing 
from the IANA registrations.

With regards to the use of iPatch I wonder if there is much saving on 
the server if it still needs to check the contents to determine if it is 
indeed idempotent or not (e.g. as per the example in section 3.1)?

Otherwise the draft is OK for me.

Regards, Christian

On 28/06/2016 3:32 AM, Jaime Jiménez wrote:
> Hi all,
>
> This is the Working Group Last Call for the "Patch and Fetch Methods 
> for Constrained Application Protocol (CoAP)” document.
> <https://core-wg.github.io/etch/>
>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 29 Jun 2016 09:39:17 +0200

Hi Christian,

many thanka for a thorough review. See below.

> Cl.1.1 Para 2 editorial: ...request body than can comfortably <be>
absolutely: good catch
> 
> Cl.2.1: The reference 5.9 seems to point to a non-existing clause in 
> the draft.
I checked the html; and you are right; At several places reference to 
7252 is meant and html points to nowhere in the document.
> Cl.2.2.2 Editorial: Extra "." after 5.10.6
Yep; to be adapted.
> Cl.3 Para 2: The hyperlink in the reference to section 5.10.8.1 points
see above
> to be formatted "Content-Format: 51 (application/json-patch+json)" as
indeed; we like consistency.
> than the referenced RFC7252.
see above
> Cl.3.2: Should this indicate that the draft specifies additional 
You refer to 4.22 that is not in coap list. Well seen: this has been 
lost on the way.
> 
> Cl.3.4 Unprocessable request: "," should be "." on the end of the 
> second bullet.
OK.
> from the IANA registrations.
This is an oversight (but duly noted now)
> the server if it still needs to check the contents to determine if it
> is indeed idempotent or not (e.g. as per the example in section 3.1)?

I like to refer to the discussion by Carsten

> Otherwise the draft is OK for me.

Thanks for your work
> Regards, Christian

Greetings, Peter

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jun 2016 09:47:24 +0200

> 7252 is meant and html points to nowhere in the document.

Right.  There is nothing wrong in the draft, though.

The draft contains the text:

   FETCH for CoAP adopts the response codes as specified in sections 5.9
   and 12.1.2 of [RFC7252].

Now, the code at tools.ietf.org that translates that into HTML finds the
"sections 5.9" reference and guesses that this might be a reference into
the present document.  That guess is wrong but the code doesn't know
better right now.  There is also nothing in the text file that goes into
that heuristic that contains the actual link.

(The same is true for a few more external references in the document.)

With the new publishing pipeline coming up as XML2RFCv3, this can all be
done explicitly.  So nobody cares for fixing the heuristic at
tools.ietf.org (well, if anyone goes ahead doing this, I'm sure Henrik
will be receptive to it, because we still need it for all the old
documents).

Now back to the actual bugs in the document...

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jun 2016 10:16:37 +0200

Hi Christian,

thanks for the review.  I've commented on the misleading hyperlinks that
the tools site adds.  A new version with fixes is already at

	https://core-wg.github.io/etch/

> to be formatted "Content-Format: 51 (application/json-patch+json)" as

Yes.  I also added an NNN (and some explanatory text) for the fictional
application/example-map-keys+json media type.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jun 2016 10:20:40 +0200

> The client should use If-Match if it really cares about not applying an

Actually, the CoAP de-duplication mechanisms will already ensure
at-most-once semantics (we cannot completely guarantee exactly once, as
the message may run into a network partition or similar).

What iPATCH is about is relieving the server from the need to even
operate these mechanisms.

But it is true that other clients may be making changes in parallel, so
if your patch format is brittle enough not to be idempotent, adding an
If-Match to protect against races likely is prudent.

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Jun 2016 09:27:13 -0700

Hi,

> operate these mechanisms.
OK -- I can see how it would be useful so the client does not need to
retrieve the ETag first.

> If-Match to protect against races likely is prudent.
I think 2 different issues are being conflated.
If-Match is useful for the client to patch the resource correctly.
Just because the patch is idempotent does not mean it will have the
intended results
if the resources have changed underneath.

Trivial example:

   leaf X { type int32; }
   leaf Y { must "../X"; type int32; }

client A deletes /X.

client B uses iPATCH to do a replace on /Y.

This will fail because client B thinks /X still exists, but client A just
deleted it.
It will fail with iPATCH, PATCH, or PUT.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Jun 2016 09:30:36 -0700

> It will fail with iPATCH, PATCH, or PUT.
Actually, only an ETag on the datastore itself will help here.
If-Match for /Y will be accepted because the ETag for /X changed (not /Y).

Andy

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jun 2016 18:56:22 +0200

Andy Bierman wrote:
> This will fail because client B thinks /X still exists, but client A
> just deleted it.

Right.  That is exactly what we want.

What we don't want is something like "insert $5" to be done repeatedly
when it was intended to be done once.  That's why PATCH (which handles
the most general case) is not idempotent, neither in CoAP nor in HTTP.
But that at-most-once semantics has an implementation cost.

What we add (HTTP doesn't need this as a separate method, because HTTP
servers already consume >> 100 Watt :-), is an idempotent patch.  This
could be used for "set the radio power to +5 dBm", when the radio power
is an element of a structure that is offered as a single resource.  If
somebody removes the radio before the client requests this iPATCH, it
should and will fail.

Grüße, Carsten

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 Jun 2016 09:31:11 +1000

Hello Peter,

No problem.

Just on: "Cl.3.2: Should this indicate that the draft specifies 
additional response codes?
You refer to 4.22 that is not in coap list. Well seen: this has been 
lost on the way"

My point was that this "Response Codes" clause indicates the response 
codes are specified in RFC7252, it doesn't say there are additional 
codes defined in this draft. So I would suggest adding something like 
"In addition this document specifies additional response codes 4.09 and 
4.22."

Regards, Christian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 30 Jun 2016 08:28:17 +0200

Hi Christian,

> So I would suggest adding something like

The editors' draft now says:

3.2. Response Codes
PATCH and iPATCH for CoAP adopt the response codes as specified in
sections 5.9 and 12.1.2 of [RFC7252] and add 4.09 “Conflict” and 4.22
“Unprocessable Entity” with the semantics specified in Section 3.4.

Grüße, Carsten

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 Jun 2016 16:40:14 +1000

Hello Carsten,

Sounds good.

Regards, Christian