Subject: [core] Stepping back: what is a CoAP REST transaction?

From: "Peter A. Bigot" <[email-masked]>
Date: Thu, 24 Oct 2013 07:39:03 -0500

When trying to understand a specification I find it most useful to start
with the underlying domain model of the problem it addresses.  I do this
by identifying key concepts and operations that compose to more complex
concepts and operations until the whole system can be approached at
different levels of abstraction.

For example, a CoAP endpoint is, to a first approximation, is a triple
of an IP address, a port, and a security context.  Messages are
transmitted from a source endpoint to a destination endpoint.

A CoAP message is pretty well defined, though its taxonomy is missing
some layers.  Request messages and response messages are also fairly
clear: they are simply messages with codes in specific classes.

But what is a REST transaction in the eyes of this protocol?  What are
its constituent elements, the events that transition it through the
stages of its lifecycle, and the limits on what it can express?

For CoAP-18 in isolation the answer clearly has something to do with a
request message and a response message which are coupled by a token, but
even in base CoAP a REST request is not a request message and a REST
response is not a response message.  Message retransmissions,
piggy-backed versus separate responses, and message duplication and
rejection all add complexity to the concept of a REST transaction.

Even if CoAP-18 could be taken as providing an operational definition of
a REST transaction, this stops working once observe, block, and
groupcomm remove constraints along orthogonal axes.  Observe introduces
a sequence of responses to one request.  Block introduces fragmented
requests and responses.  At one point groupcomm introduced multiple
responses that must be aggregated in some way to form the response.
(Here confusion comes in part from the lack of an underlying model for a
resource with a URI that uses a multicast address in its authority,
a construct that should be discussed in a wider community than CoAP.)

Recent issues raised here have included how to reliably cancel an
observe transaction and how to detect and resolve errors within the
block transfer of a request or response.  The answers would be informed
by a clear model of exactly what a REST transaction is within CoAP.
Done at the right level of abstraction this allows reasoning about what
new proposed capabilities mean by comparison to simpler and better
understood capabilities.

If the working group has such a model that is used to drive evolution of
new capabilities, I have been unable to extract it from the current
drafts.  To help CoAP be adopted by people other than those who are
actively developing it in parallel with their implementations to whom
the answers to "what does this mean" are obvious, this really needs to
be addressed.

If there is no such model, the consequence is ad hoc solutions to common
problems.  The resulting complexity is a serious impediment to adoption
of CoAP by anybody who doesn't have three years of sunk costs to justify
the necessary effort.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Oct 2013 15:07:36 +0200

Hi Peter,

thanks for trying to step out from all that dazzling detail and getting a bigger picture.

Indeed, a base CoAP exchange (a word that I prefer over the loaded word “transaction” here) is a pair of request and response messages.  The fact that they may need to be retransmitted or might be duplicated in the network is handled at the message layer and no longer is of interest at the request/response layer.

Observe extends the exchange by notifications, which can come as additional responses to the original GET request.  The cancel discussion is really about how to tear down such an extended exchange without creating lots more mechanism just for that.  (Since we already are using the token as a handle on the extended exchange to renew it, maybe we want to use that for proactive teardown.  But maybe the current reactive teardown is good enough.)

Block uses the exchange abstraction and layers essentially the same abstraction again on top of it, where the latter allows larger bodies than the base CoAP protocol (or UDP messages of comfortable sizes) do.

The groupcomm issue is indeed interesting; in my mind it works best by considering the multicast request a solicitation to begin an exchange, which instantiates once in each peer sending a response.  So in the end, you have many exchanges (each of which might be continued in a Block2 blockwise transfer).  But that is something that maybe is in the eye of the beholder — the protocol does not have to dictate the implementation model.  We certainly haven’t completed discussing this.

The above discussion becomes really interesting once you add proxies to the picture.
The HTTP model of a proxy fits very well with the base CoAP protocol.
Observation relationship (extended exchanges) not defined beyond proxies — observing a proxy may cause that to establish an observation relationship at the next hop, or it may not.  Inversely, a proxy may decide to observe a resource if it detects significant interest in it by its clients.
Block is also intended to implementable hop-by-hop, but a simple CoAP-CoAP proxy may even be able to hand through each of the blocks without keeping the state.
Proxying group communication is something we don’t really know how to do very well yet (section 2.9 of groupcomm).

Thanks again — asking questions like these on the list is really useful.  
We may want to document more of this bigger picture in documents such as the CoRE roadmap.

Grüße, Carsten