Subject: [core] Asynchronous Response Correlation

From: Peter Bigot <[email-masked]>
Date: Sat, 20 Nov 2010 04:20:55 -0600

I don't believe there is consensus on this issue, but the discussion in
various threads has stopped.  I don't want this to remain in limbo until
time pressures result in an ad hoc solution in the final document.

I propose that Token be the sole technique used in CoAP to correlate
asynchronous responses with original requests.  This should hold for all
methods, and regardless of the number of responses transmitted
(subscriptions or other situations).

- As a "REST-level" equivalent to the transaction-level TID, uniform
  application of this simple rule repeats an existing practice, decreasing
  the conceptual complexity of the system

- Token permits the client to control whether the server may use
  asynchronous responses, a feature that may be required for severely
  constrained devices or specific applications

The only alternative to this I've seen proposed is to use URI correlation by
providing URI-related options in the response message.  I ask the proponents
of this to:

- Define clearly the steps involved in URI correlation, including which
  options are involved and whether the comparison is as opaque octet
  sequences or semantically-equivalent representations

- Provide a compelling use case where URI correlation is superior to Token
  correlation

- Specify whether they wish URI correlation to be the sole technique for
  asynchronous response correlation, or whether it should co-exist with
  Token correlation

- Describe how the client may control use of asynchronous responses with
  this technique, or provide an argument why such control is unnecessary

Without such a response, we either do not have consensus, or we can assume
that consensus is to use Token uniformly.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 21 Nov 2010 07:46:53 +0100

On Nov 20, 2010, at 11:20, Peter Bigot wrote:

> use Token uniformly

Well, the problem is that Token is an option.

At the last plugfest we were reminded that implementations that require a certain option are the road to interoperability failure, e.g.:

Implementation A happens to not send tokens, as it wants to send minimum size packets.

Implementation B happens to require tokens, as it might want to send asynchronous (delayed) responses.

The approach to try without Token and then add one in a second request after failure adds significant complexity to the state machine.

So what you are proposing makes Token kind of mandatory for every request if you want interoperability.

Indeed, we have no good way to correlate PUT/POST/DELETE delayed responses without a Token, so making them required there appears reasonable.

Not so sure about GET.  Yes, we have to write up the correlation rule, but it should be simpler than a "try without Token and then try again with Token" state machine.

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Sun, 21 Nov 2010 07:19:45 -0600

>
> On Sun, Nov 21, 2010 at 12:46 AM, Carsten Bormann <[email-masked]> wrote:

Well, complexity has to go somewhere, especially if
applications/implementations choose to optimize different things.  It seems
you're considering adding the complexity for this specific case to the
protocol, affecting all implementations, rather than leaving it to the
implementations that make those incompatible choices.

I personally don't see why:

Lookup original request for synchronous reponse
If response.code == TOKEN_REQUIRED:
   request.includeToken = TRUE
   request.transmit()
   return

adds a lot of state machine complexity to a client implementation that
supports asynchronous responses, but of course the details are going to be
specific to the implementation.  It does increase response delay, on at
least one REST transaction, but it should be up to the implementation
whether (a) increasing request message size by two bytes or (b) increasing
the code size to support retransmits and accepting the increased latency is
less desirable.

At any rate, my gut instinct is that URI correlation is not nearly as easy
as you believe.  Somebody needs to write it up and post it here for
discussion so we can find out.  I absolutely don't believe the code space
required to support it will be less than the code space to recognize a
TOKEN_REQUIRED response and invoke transmit again.

I also think it's a bad idea to remove the mechanism by which clients can
influence the server's decision to use or not use asynchronous responses,
i.e. presence or absence of Token in the request.

   - If the client doesn't send Token because wants minimum-sized packets,
   it's rather rude of the server to unilaterally decide to send asynchronous
   responses that have the whole URI encapsulated. Perhaps the client knew that
   the response message would be too big if the URI was included.

   - I don't recall that there's a requirement that clients support
   asynchronous responses.  Without the ability to influence the server, such a
   client cannot communicate with a cooperative server that would make an
   effort to return the response synchronously if the client is not
   async-capable.

That's why I also asked for an alternative solution to the influence
problem, or an argument that it's not important.

Thanks for replying.  Clearly we do not have consensus, and I look forward
to responses to my request so we can resolve this.  I am strongly opposed to
a protocol for constrained devices that solves the same problem in two
incompatible ways.  If Token is going to be the solution for non-GET
methods, there needs to be a really compelling reason why an additional
mechanism should be added for GET.

Peter