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

From: Carsten Bormann <[email-masked]>
Date: Mon, 14 Nov 2016 10:37:57 +0900

Hi Spencer,

please see my comment to Alissa, as well as the new text

   It is RECOMMENDED that any discovery method that allows a client to
   find out that the server supports one of PATCH and iPATCH also
   provides information what patch payload media types are applicable
   and which of the two methods are implemented by the server for each
   of these media types.

   Servers that do not rely on the idempotency of iPATCH can easily
   support both PATCH and iPATCH, and it is RECOMMENDED they do so.
   This is inexpensive to do, as, for iPATCH, there is no requirement on
   the server to check that the client's intention that the request be
   idempotent is fulfilled (although there is diagnostic value in that
   check, so a less-constrained implementation may want to perform it).

I think that this should give the guidance that is needed here.  Do you agree?

Grüße, Carsten

> On 13 Oct 2016, at 20:15, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Peter,
> 
> On Oct 13, 2016 06:05, "Alexey Melnikov" <[email-masked]> wrote:
> >
> > Hi Peter,
> >
> > On Thu, Oct 13, 2016, at 11:43 AM, peter van der Stok wrote:
> > > 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.
> 
> This all makes sense to me, and I'm not challenging it.
> 
> > > 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?
> >
> > 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?
> 
> 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
> 
> > > Greetings,
> > >
> > > peter
> > >
> > >
> > > Spencer Dawkins schreef op 2016-10-12 18:00:
> > > > 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.
> > > >
> > > >
> > > > _______________________________________________
> > > > core mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/core
> > >
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 15 Nov 2016 12:52:36 +0900

Carsten,

> I think that this should give the guidance that is needed here.  Do you

I do, and I'll clear.

Spencer