Subject: [core] Need WG input: request/response matching

From: Peter Bigot <[email-masked]>
Date: Thu, 25 Nov 2010 13:41:28 -0600

After the telecon yesterday there is a remaining issue in
http://trac.tools.ietf.org/wg/core/trac/ticket/74: whether or not CoAP must
provide a mechanism, such as presence/absence of the Token option in a
request, to influence the server's decision to use an immediate or deferred
response to a specific request.

Carsten and I hold opposing positions, and I don't know which side Zack
ended on.  So, we really need group input on this:

*Should clients be required to support deferred responses to their requests?
*

Carsten's position is "Yes", because this requirement has minimal impact on
the client and so there is no need to provide such a mechanism.  Depending
on the approach, this could reduce message sizes, simplify the client by
eliminating the need to re-transmit a request with "deferred-ok" flag if the
server can't send an immediate response, and simplify the server
implementation.

My position is "No".  While any end-point that can accept incoming requests
should have this machinery, I believe extremely constrained clients might
not want to incorporate that code (e.g., to send acknowledgements for
incoming confirmable messages), or to support any sort of state associated
with unfulfilled requests (e.g., correlating security contexts).  Further,
even if a client has the mechanism in place, there may be temporary reasons
why the client does not want a deferred response for a specific request.
For example, following an observation by Zack, certain schedule-based access
policies might be difficult to implement if deferred responses, as currently
drafted, were allowed.  So, I think it's important to give the client the
ability to prevent deferred responses.

Carsten, please follow up if I've failed to explain your position
adequately.

Comments from anybody else?

(This is a separate issue from a question of whether a client should be able
to provide a deadline by which the server must provide either an immediate
or deferred response, or to influence the retransmission delays e.g. due to
use of a satellite link, although having a mechanism for these issues might
make it a moot question.  I don't expect we'll have such a mechanism defined
within the time by which we expect to submit CoAP to IESG.)

Peter

---

From: Linyi Tian <[email-masked]>
Date: Sat, 27 Nov 2010 17:12:28 +0800

Hi, Peter

My answer is "yes". Here is my observation:

1.       Client will not know whether the server needs time to process the
request. It will be hard for client to decide when to use negotiation
mechanism. 

2.       The server chooses to use deferred message is because the server
needs time to process the request. Even if the client wants to get the
result immediately it may not be realistic. If the server can't do it in
ACK, what the server can do? Simply reject the message?

3.        If the end point can support the complex mechanism like
scheduling, I can't imagine it can't store the state associated with Token
for short of time. 

The main mechanism for the client needs is to store the Token and has a
time-out mechanism. Maybe this is not a big issue for clients. Correct me if
I am wrong. 

Cheers,

Linyi

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Bigot
Sent: Friday, November 26, 2010 3:41 AM
To: core
Subject: [core] Need WG input: request/response matching

Should clients be required to support deferred responses to their requests?

Peter