Subject: [core] draft-ietf-core-coap-06: separate response

From: Thomas Herbst <[email-masked]>
Date: Wed, 11 May 2011 11:26:59 -0700

Two comments -

First, it doesn’t seem to proxy to http cleanly.  If the coap server does not provide a response in bounded time, how is the http proxy to provide a response to its client?

Ignoring the proxy issue for a minute, an open ended response time seems problematic for battery powered radio devices staying on for the response.
Could it either be bounded or give a specific time window in the future when the response might be returned so the battery device might sleep until the server replies?

tom

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 May 2011 21:13:24 +0200

> First, it doesn’t seem to proxy to http cleanly.  If the coap server does not provide a response in bounded time, how is the http proxy to provide a response to its client?

The answer to this question is unrelated to the subject of this message (see PS).

HTTP does not make any promises with respect to the speed of response.  Neither does CoAP.  Maps perfectly.

(Excepting the special case of HTTP long poll, which we don't need in CoAP since we have -observe:)
The assumption, of course, is that the response will come reasonably fast.
Whatever is reasonable for the application.

> Could it either be bounded or give a specific time window in the future when the response might be returned so the battery device might sleep until the server replies?

Kepeng's draft gives a way to provide a bound.  Of course, this is supplied from the client side.
A bound (or time window) supplied from the server side is more interesting for the problem you describe.
However, doing it the way you describe it would require an extension of the simple request-response state machine.

One different way to do this is:

5.9.3.4.  5.03 Service Unavailable

   Like HTTP 503 "Service Unavailable", but using the Max-Age Option in
   place of the "Retry-After" header field.

(This, of course, requires another request after the max-age times out, so it is not exactly what you are asking for.  Extending -observe to be able to catch up after a 5.03 or a special variant of it would solve this.)

Gruesse, Carsten

PS.:
As a protocol designer and spec writer, I find it interesting that all these questions about timing regularly come up in the context of separate responses, which don't really change much in the timing, but just provide a way for the server to forego piggybacking in order to enable the client to stop retransmitting while waiting...  Somebody should write a thesis about what we can learn from this aspect of spec reception.