Subject: Re: [Ace] End-to-End Scenarios

From: Randy Presuhn <[email-masked]>
Date: Tue, 22 Sep 2015 10:15:19 -0700 (GMT-07:00)

Hi -

>From: Olaf Bergmann <[email-masked]>
>Sent: Sep 22, 2015 4:55 AM
>To: Jim Schaad <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [Ace] End-to-End Scenarios
...
>Thus I completely agree with your split between GET and PUT/DELETE/PATCH
>in that a GET request without a response usually does not make much
>sense. POST is somewhat special in that one possible effect of POST is
>to create a new resource whose URI is returned in the response.

I've been watching this thread for a while, trying to make sense
of it, and would like someone to enlighten me.

In every management protocol I know of, the operations corresponding
to PUT/DELETE/PATCH are confirmed operations for several important
reasons:

   1) the invoker needs to know whether the operation was accepted
      (request not lost or destroyed by some interloper, request
       deemed well-formed by the recipient, the object of the
       operation existed, not blocked by access control or other
       concerns, etc.)

   2) the invoker needs to know whether the operation was completed
      (things like delete and patch in particular may take a long
       time to bring to completion, depending on their side-effects,
       and the invoker may want to defer initiating another operation
       until the target is in a known state, or may need to coordinate
       the state transitions of multiple target systems)

   3) particularly on low-end systems, command-processing queues may
      be subject to seemingly arbitrary constraints, and sending
      too many (where the value of "too many" is generally not
      advertised) operations back-to-back will cause some of them
      to be lost or worse, necessitating a sort of "processing flow
      control"

So you can see why, coming from a management protocol background,
I'm having difficulty making sense of this discussion.  Please
clue me in to whatever it is that I'm missing.

Randy

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 22 Sep 2015 19:45:08 +0200

Hi Randy,

> to PUT/DELETE/PATCH are confirmed operations for several important

You are correct from a management protocol perspective. However, there
are (specifically in the IoT world) usage scenarios where the sender of
that message is not interested in the response for some reasons. One
example are sensors that sleep for most of the time, wake up to take a
measurement, PUT it onto some information broker and then go to sleep
without waiting for the response (under the optimistic assumption that a
large number of messages will reach their goal and is handled
appropriately).

If a sender wants to ensure that the message was received it can send it
as a confirmable message and wait for the acknowledgement which may or
may not be combined with the response for the request (in CoAP -- other
protocols may work differently, of course).

Grüße
Olaf

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Sep 2015 19:49:49 +0200

Randy Presuhn wrote:
> In every management protocol I know of

Right, but this is not a discussion of the management use-case.

In CoAP, we have non-confirmable messages, and now with Option 284, we
even have a way to suppress responses such as a PUT response.

This is mainly useful for cases where the client knows it will be
PUTting another update soon (as in, the next minute), and it doesn't
really care whether any single one made it (or whether they arrive in
the right order, because an old PUT overwriting a new one will soon be
rectified by the next one, as well).

Look for LoRa applications for some typical use cases.

Grüße, Carsten