Time to wrap this up: Based on two "yes", one "no", and several dozen
abstaining, I think the consensus of the WG is that clients must support
deferred responses.  The rationale is an assumption that "constrained" is
loose enough that this is a not burden to any implementation.  An implicit
consequence is that there is no need for a client to be able to influence
the server's selection of immediate or deferred response.  The impact of
this on sleeping nodes is not a concern; presumably it can be handled by
proxies/reverse proxies.

This allows an entirely new conceptualization of CoAP transactions.  I had
thought of immediate response as the normal situation, with deferred a
special case to allow for long-duration operations.  With deferred response
support required, I can simplify my server by having it immediately transmit
a CoAP-layer acknowledgement of every request, and allow the REST layer to
provide the actual response at whatever time is most convenient.
Technically, given the previous consensus that the server is entitled to
change the contents of a CoAP-layer response to a retransmitted (same TID)
request, if the REST layer responds in time I still could bundle the
response into the ack in that situation.

Interesting.

Peter

On Sat, Nov 27, 2010 at 3:12 AM, Linyi Tian <tianlinyi@huawei.com> wrote:

>  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:* core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf Of
> *Peter Bigot
> *Sent:* Friday, November 26, 2010 3:41 AM
> *To:* core
> *Subject:* [core] Need WG input: request/response matching
>
>
>
> 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
>