Subject: [core] Spencer Dawkins' Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 12 Oct 2016 09:00:24 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-core-etch-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-etch/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm following most of your reasoning behind having the twin methods PATCH
and iPATCH, but I'm struggling a bit that there's nothing that I saw that
prevents a problem when the client implements only PATCH and the server
implements only iPATCH. 

The only text I saw that provides guidance about which method to
implement is

   A client can mark a request as idempotent by using the iPATCH method
   instead of the PATCH method.  This is the only difference between the
   two.  The indication of idempotence may enable the server to keep
   less state about the interaction; some constrained servers may only
   implement the iPATCH variant for this reason.
   
Maybe I missed something? 

If not, I saw

   There is no guarantee that a resource can be modified with PATCH or
   iPATCH.
   
so, maybe that mismatch isn't going to be a problem in practice, but it
seems sad that you might have a patchable resource, that can't be patched
because of that mismatch.

I'm not asking for "clients MUST implement iPATCH if you implement PATCH"
(which would accommodate servers that only implement iPATCH), but I
wonder if the working group talked about a way to avoid this mismatch?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I was a bit uneasy with the "nearly" in 

   The security considerations for PATCH or iPATCH are nearly identical
   to the security considerations for PUT ([RFC7252]).  
   
with no explanation of any differences, but I'll leave that for the SEC
ADs to pick up on if it matters.

---

From: peter van der Stok <[email-masked]>
Date: Thu, 13 Oct 2016 12:43:32 +0200

Hi Spencer,

Thanks for your DISCUSS; I will try to respond to it.

There have been discussions in the WG about the utility of PATCH next to 
iPATCH.
Good reasons were put forward to maintain both.
Also the wish was expressed to only allow idem-potent requests and be 
able to implement iPATCH without the PATCH counterpart.

Sending a PATCH request to an iPATCH only server will result in a CoAP 
error 4.05 method not allowed

If I understand correctly, your concern is a non-idempotent request sent 
to an iPATCH server.

In section 3.4 there is text about server reactions to inappropriate 
payloads.
In particular the response code: Unprocessable request applies:
when processing the request makes the resource invalid.
We might add (e.g. non idem-potent request to iPATCH)

Does this answer your concern?

Greetings,

peter

Spencer Dawkins schreef op 2016-10-12 18:00:
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Oct 2016 12:05:14 +0100

Hi Peter,

> Does this answer your concern?

Does this mean that a client that wants doesn't care about idempotency
of its request might need to try PATCH, then discover that it is not
supported and then retry iPATCH?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Oct 2016 13:16:03 +0200

> supported and then retry iPATCH?

How does it know that the server supports one of these methods (PATCH,
iPATCH) in the first place, and what media types to use with one of
these?  This is usually found out using discovery (for an example, see
the form relations concept introduced in draft-hartke-core-apps).  This
discovery would also tell the client which specific method to use, so
there is no need for trial and error.

What we could add is a recommendation for servers to always support both
methods (that is not hard to do, because what follows), and emphasize
that there is no particular onus *on the server* to check the client's
intention that the request be idempotent.

Grüße, Carsten

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 13 Oct 2016 06:15:40 -0500

Hi, Peter,

> > able to implement iPATCH without the PATCH counterpart.

This all makes sense to me, and I'm not challenging it.

> supported and then retry iPATCH?

What Alexey said, plus "and because we expect some servers will only
support iPATCH, if a client doesn't retry with iPATCH, the client may fail
to modify a resource that can be modified, but only using iPATCH".

Is that clearer?

Spencer

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Oct 2016 12:18:51 +0100

Hi Carsten,

> there is no need for trial and error.
This would be a useful text to add.
> intention that the request be idempotent.
Sound good to me!