Subject: Re: [core] :Re: Draft needs Asynchronous transaction details

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Dec 2010 12:47:26 +0100

On Nov 29, 2010, at 15:54, [email-masked] wrote:

>>> However you didn't answer the question what code should be returned,
>>> 100 or 202?
> 
>> Neither 100 nor 202. Here's an example:
>> C: CON + GET coap://server/resource (token=0x5f)
>> S: ACK
>> S: CON + S_OK (token=0x5f) "Hello World"
>> C: ACK
> 
> But is it allowed for an HTTP/CoAP proxy to translate the first ACK with 
> code 0 into a 202 Accepted response?

I don't think so.

(First of all, there is no 202 in HTTP for GET.  But let's pretend the example is about a POST.)
With a 202 response, the HTTP server makes a "non-commital" (RFC 2616, 10.2.3) final response.  There is no way to send a deferred response later as we can in CoAP.

Here, the ACK means just that: "stop retransmitting, I got the datagram with the request".  It does not mean the request even will be accepted.  The actual response comes back in the form of a deferred response.  It is that which carries the actual response code.  The ACKs have no meaning with respect to the request/response pair; hence they carry "no code" (= 0).

Gruesse, Carsten

---

From: Matthieu VIAL <[email-masked]>
Date: Wed, 1 Dec 2010 17:38:07 +0100

>(First of all, there is no 202 in HTTP for GET.  But let's pretend the 
example is about a POST.)

So if a proxy wants to allow parallel jobs for a batch process it should 
answer with HTTP 202 responses and forward the POST requests as 
non-confirmable CoAP transactions?
And If the proxy thinks the CoAP deferred response takes too much time to 
arrive it must send an HTTP 504 Gateway timeout response and never an HTTP 
202?

>With a 202 response, the HTTP server makes a "non-commital" (RFC 2616, 
10.2.3) final response.  There is no way to send a deferred response later 
as we can in CoAP.

>Here, the ACK means just that: "stop retransmitting, I got the datagram 
with the request".  It does not mean the request even will be accepted. 
The actual response comes back in the form of a deferred response.  It is 
that which carries the actual response code.  The ACKs have no meaning 
with respect to the request/response pair; hence they carry "no code" (= 
0).

>From the HTTP client's perspective I can't see a big difference between 
"It does not mean the request even will be accepted" of CoAP and "[the 
request] it might be disallowed when processing actually takes place" of 
HTTP. The HTTP request may be accepted from the proxy point of view. Then 
the forwarded request may not be accepted by the CoAP server which I can 
also understand as "disallowed when processing". 
Let's take the following example. The proxy wants to answer its HTTP 
clients always within X seconds. After Xs with a "no code" ACK but no 
deferred response from the CoAP server the proxy send a 202 Accepted 
response with the URL to a resource containing the status of the 
outstanding CoAP request. Then the HTTP client can start a new request and 
check the result of the previous one later. Is there something wrong with 
that?

Matthieu

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 2 Dec 2010 00:07:08 +0100

> non-confirmable CoAP transactions?

I'm not sure I understand the scenario, but sending a 202 and then forwarding on a nonconfirmable strikes me as wrong -- 202 at least means "accepted", and there is no way to know whether the NON actually arrived at the origin server.

> arrive it must send an HTTP 504 Gateway timeout response and never an HTTP 

Good question.
A CoAP server that takes a LOOONG time to do a POST maybe is not a very good candidate to map into the HTTP world.
Or maybe it is, if the proxy is just patient enough (and has the resources to be patient, e.g., sockets).

> clients always within X seconds.

That is certainly one way to manage its resources.
This proxy is just not very useful with very slow CoAP servers, unless it has some processing rules like the ones you give below.

(Note that if X < ~32, some processing rules are also required for the case that it simply took a number of retransmissions to get an "immediate" answer.)

> After Xs with a "no code" ACK but no 
> outstanding CoAP request.

That might work quite well for POST.
(What does that resource respond while the POST is in progress?)

> Then the HTTP client can start a new request and 

I don't think there is anything particularly wrong with that mapping.
(It is clearly not the only conceivable mapping.)
I'm not sure that many HTTP clients know what to do with a 202 response, so you may be in somewhat uncharted territory here.

Gruesse, Carsten