Subject: [core] asynchronous responses

From: Peter Bigot <[email-masked]>
Date: Fri, 23 Jul 2010 07:37:00 -0500

I've updated coapy's git repository with server and client support for IPv6,
and added a service that uses asynchronous responses.  (No new release, it's
only in the repository but you can fetch it.)

Based on this, the following clarifications are needed (some of which are in
my endpoint-questions mail):

* It is unclear how to indicate that the response will be asynchronous; the
  text references whether the ACK "carries the REST response".  I interpret
  a header code value of zero to indicate absence of REST content in the
  message (section 3.1 is insufficiently clear about this).

  Based on this it should also be made more clear that the payload belongs
  to the REST part of the message, and is absent if the message carries no
  REST content.  The options, on the other hand, are not part of the REST
  message.  (Or, if all that's not true, whatever is truth needs to be
  documented.)

* Where does the server send the asynchronous response?  I sent it to the
  originating sender's envelope source address, where the synchronous
  response went.

* From what local address does the server send the response?  I sent it from
  the endpoint on which the request was received.  Natural in this case, but
  is it required?

* How does a client that has requests for the same URI out to multiple
  servers disambiguate?  Presumably that's the Token option from coap-misc.

* What options must be copied from the request to the asynchronous response?
  Section 2.1.2 says "the URI (and possibly token)".  This would be
  Uri-Scheme, Uri-Authority, and Uri-Path, for now?  I just copied Uri-Path;
  I don't have Token yet, and the others I'd ignore anyway.  If Query-Param
  is added, it'll have to go too.

  This is getting ugly: like multiplicity, there should be a defined feature
  of each option that indicates whether it needs to be copied to an
  asynchronous response.  Behavior for options not recognized by receiver?

* What options must be copied from the request to a synchronous response?
  Is Token one of them, or do we assume the transaction ID is sufficient and
  no options that are not relevant to the REST response need to be copied?
  (Are any options relevant to the REST message, or are they all part of the
  transaction?  See first point above.)

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Jul 2010 15:17:01 +0200

Hi Peter,

I believe these observations are great material for coap-02.

Let me pick some that might need some discussion.

>   message.  (Or, if all that's not true, whatever is truth needs to be

So far, we tried to avoid imposing one form of strict layering here.
It is not clear to me that we have to define exactly which options are transaction layer and which ones are REST layer.
If I had to choose, all would be REST layer.
But maybe you have a different idea of what "REST layer" means here (maybe there are three layers?).

>   originating sender's envelope source address, where the synchronous

Yes, that's the intention.

>   the endpoint on which the request was received.  Natural in this case, but

We have to define that.
I would propose strictly requiring the same transport address, but occasionally people tell me they need more freedom.

>   servers disambiguate?  Presumably that's the Token option from coap-misc.

The idea was that the transport address of the server (source address of response) also goes into the comparison.
A client can (and probably should) also use different TIDs for different requests.

>   asynchronous response.  

Yes!

> Behavior for options not recognized by receiver?

Ignore, I'd say.
(Elective ones.)

>   transaction?  See first point above.)

Token was meant to be implied from the transaction (i.e., you only echo it in an asynchronous response), like the URI components.

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Fri, 23 Jul 2010 09:16:21 -0500

On Fri, Jul 23, 2010 at 8:17 AM, Carsten Bormann <[email-masked]> wrote:

> It is not clear to me that we have to define exactly which options are
> transaction layer and which ones are REST layer.

 I think there are all kinds of layers.

   - The transport layer is below CoAP completely, and is for the purposes
   of CoAP assumed to be UDP.
   - The transaction layer is the one that interprets the transaction type
   (CON, NON, ACK, RST) and transaction id, and carries the code.
   - The REST layer is identified by the code, and carries the options and
   the payload.

I think you're right that all the options belong at the REST layer not the
transaction layer.  This makes things simple, and we just have to make sure
that we can keep that distinction as reality intrudes.

There are two problems.  First, that I conceptualized a transaction-layer
relation between the request and the asynchronous response.  Now, I think
that was a mistake.  See below regarding synchronous responses for a related
issue where REST and transaction interrelate.

Second is the URI.  Uri-Authority is a huge problem, since it couples the
REST layer with the transport layer, bypassing the transaction layer.  This
is the issue that HTTP/1.1 tried to get away from by making Host a required
keyword, so that the complete URI would still be available at the REST
layer.  I don't think we can get away from that: I think Uri-Authority has
to be required whenever a URI is present.  On the other hand, I'm afraid of
having to interpret Uri-Authority on a CoAP node.

(Similarly, why don't we just get rid of Uri-Scheme?  It'll be "coap",
always.  A URI that refers to any other scheme is data, not part of a REST
exchange supported by a CoAP server.  This is, I believe, entirely
consistent with how HTTP treats the scheme.)

> I would propose strictly requiring the same transport address, but
> occasionally people tell me they need more freedom.
>

Multicast destroys this.  The server really shouldn't send its response
using the multicast address as the source address, if it even can (it's so
perverse even I haven't tried it).  The client who multicast a request
(e.g., same Uri-Path to two distinct multicast groups) won't recognize
asynchronous responses.

Ideally, correlation of REST messages should be achievable solely at the
REST layer, with a possible exception to leverage transaction ID from the
transaction-layer for synchronous responses.  I believe requiring
information from the transport layer to correlate REST messages would be a
mistake.

> Token was meant to be implied from the transaction (i.e., you only echo it
> in an asynchronous response), like the URI components.
>

 So:

   - Options are REST features
   - Consequently, in an asynchronous response the transaction should carry
   all and only those options that are relevant to the REST message that serves
   as the response.
   - In a synchronous response, we can optimize this by skipping any options
   from the REST message where the value is identical to that of the same
   option in the request transaction.  In other words, the concept of a
   "default value" for an option in a transaction response incorporates the
   provided values of those options in the transaction request.

It's a little tricky to understand, but on the whole I think it's a clean
conceptualization.  Will it work?

---

From: Olaf Bergmann <[email-masked]>
Date: Sat, 24 Jul 2010 15:27:32 +0200

Peter,

> only in the repository but you can fetch it.)

Thanks. This now runs on coap://ns.tzi.org:61617/ as well.

Gruesse,
Olaf