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

From: "Peter A. Bigot" <[email-masked]>
Date: Tue, 29 Oct 2013 07:22:08 -0500

This doesn't show up in the archives; since it's a basis for what I did 
in http://www.ietf.org/mail-archive/web/core/current/msg05038.html I 
thought it worth making a second attempt.

-------- Original Message --------
Subject: Re: [core] Stepping back: what is a CoAP REST transaction?
Date: Fri, 25 Oct 2013 13:39:54 -0500
From: Peter A. Bigot <[email-masked]>
To: Carsten Bormann <[email-masked]>
CC: core <[email-masked]>

As I hinted in my response to Matthias regarding canceling observe
transactions, I don't think this really answers the question: it's too
high-level and vague.  Nor does it convince me that the domain concepts
drive the specification, rather than being documented in an attempt to
support the decisions made for a particular situation.

Here's the sort of questions I think should be answerable by reference
to RFCs or working documents, either because they describe entities that
are intrinsically important to the domain because they provide names for
things that are manipulated to support the domain concepts:

What is the name for a CON or NON message identified by the sender
through a specific message ID?  I don't know; but I do call the ACK or
RST that such a message may invoke the "reply" to whatever that message
is.

What is the name for the process of sending a CON or NON message with a
request code and receiving a message with a response code either
piggy-backed on the reply or as a separate message?  (Or, receiving a
rejection of the request message.)  This, I think, could acceptably be
called an "exchange".

What is the name for the process of sending a request (not message)
identified by a the client through a specific Token and receiving (zero
or more) responses (not messages) also identified by the token?  This,
I think, is a "transaction".

What is the impact on a transaction involving multiple exchanges if a
message in an exchange evokes RST as a reply?

What is the impact on a transaction involving multiple exchanges if a
message in an exchange is rejected (this is NOT necessarily the same
thing)?

What is the impact on a transaction involving multiple exchanges if one
(but not all) of the exchanges evokes an error response?

What does it mean to cancel a transaction?  How is this initiated by a
by client or server?  How is the cancellation confirmed or synchronized
among endpoints participating in the transaction?

Regarding groupcomm, as I said back in 2010 I think what a URI with
a multicast authority means should not be defined by CoAP: the concept
has generic applicability and should be agreed upon by everybody who
uses URIs.  Your perception that a GET using such a URI initiates
multiple simultaneous transactions is one approach.  From a REST
perspective, it could have others.  Two obvious interpretations are:

* The resource identified is distributed, and its constituent
    representations must be aggregated in some fashion to form the
    representation of the resource as a whole;

* The resource identified is replicated, and (assuming consistency) any
    holder of the resource may respond to a read, and all must be involved
    in a write.

The interpretation really needs to be determined by the specific
resource.  I haven't kept up with groupcomm's plans since my comments on
this issue back in 2010, but certainly GET is not the only method that
could be applied to such a resource, so the concept really needs to be
well-defined for other operations too.

Peter

On 10/24/2013 08:07 AM, Carsten Bormann wrote:
> 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
>