[core] Asynchronous Response Correlation

Peter Bigot <pab@peoplepowerco.com> Sat, 20 November 2010 10:20 UTC

MIME-Version: 1.0
Date: Sat, 20 Nov 2010 04:20:55 -0600
Message-ID: <AANLkTinn3qSEriM99=hnAGuOT55MbeT1bJThZLVuqxrL@mail.gmail.com>
From: Peter Bigot <pab@peoplepowerco.com>
To: core <core@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [core] Asynchronous Response Correlation
Precedence: list

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

[core] Asynchronous Response Correlation Peter Bigot
Re: [core] Asynchronous Response Correlation Carsten Bormann
Re: [core] Asynchronous Response Correlation Peter Bigot