Subject: [core] Draft needs Asynchronous transaction details

From: Talal Butt <[email-masked]>
Date: Fri, 26 Nov 2010 03:37:12 +0000

I am actively following the list and working on a coap implementation for our large scale sensinode network. I have implemented the basic coap with reliable UDP as defined by the coap ID.

Currently, I am planning to add the Asynchronous Logic into my implementation but have noticed that ID is not explaining any Asynchronous scenario in detail. 

As defined in the draft

  Client             Server
      |                 |
      |   CON tid=48    |
      |   TOKEN = 3a    |
      |  GET http://n.. |
      +---------------->|
      |                 |
      |   ACK tid=48    |------------> What code should be returned here???
      |<----------------+
      |                 |
      ... Time Passes ...
      |                 |
      |   CON tid=783   |
      |   TOKEN = 3a    |
      |   200 "<html..  |
      |<----------------+
      |                 |
      |   ACK tid=783   |
      +---------------->|
      |                 |

                 Figure 3: An asynchronous GET transaction

So the client should keep the asynchronous waiting list, to match the received token with the waiting request. However, the question is what code in the ACK, will point out to wait? 
 In this scenario if we can use code=100 -> CONTINUE. This can be a solution, but again this is not mentioned in the internet draft.

Talal Ashraf Butt
Research Student
Loughborough University

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 26 Nov 2010 04:51:36 +0100

Talal Butt wrote:
> So the client should keep the asynchronous waiting list, to match the received token with the waiting request.

We've just changed the terminology to refer to "immediate" and
"deferred" responses, and updated how tokens a are used to correlate
responses with requests.

Immediate and deferred responses are very similar: In either case, the
response contains the token that the client specified in the request.
The difference is how they arrive.

An immediate responses coincides with the ACK that signals that the
CON request was received.

A deferred responses arrives as an CON, separately from the ACK. The
CON needs to be ACK'd by the client.

> However, the question is what code in the ACK, will point out to wait?

If the response arrives separately from the ACK (deferred response),
the Code field in the header of the ACK is set to 0.

Klaus

---

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

Hi, Talal Ashraf Butt

I believe the status code in ACK should be 202 "Accepted" instead of 100
"continue. Status code 100 is to allow a client that is sending a request
message with a request body to determine if the origin server is willing to
accept the request before the client send the request body. I hope this
helps.

The group is working on how to include status code description into R04
draft. You can read the emails with tile " [core] coap #77 (new): Response
code semantics ". 

I quote the following description from HTTP 1.1 Part 2
(http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/):
8.2.3. 202 Accepted
The request has been accepted for processing, but the processing has
not been completed. The request might or might not eventually be
acted upon, as it might be disallowed when processing actually takes
place. There is no facility for re-sending a status code from an
asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
Fielding, et al. requiring that the user agent's connection to the server
persist
until the process is completed. The representation returned with
this response SHOULD include an indication of the request's current
status and either a pointer to a status monitor or some estimate of
when the user can expect the request to be fulfilled.

You can refer to 7.2.3 of HTTP 1.1 Part 1
(http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/)
7.2.3. Use of the 100 (Continue) Status
The purpose of the 100 (Continue) status code (see Section 8.1.1 of
[Part2]) is to allow a client that is sending a request message with
a request body to determine if the origin server is willing to accept
the request (based on the request header fields) before the client
sends the request body. In some cases, it might either be
inappropriate or highly inefficient for the client to send the body
if the server will reject the message without looking at the body.
Requirements for HTTP/1.1 clients:
o If a client will wait for a 100 (Continue) response before sending
the request body, it MUST send an Expect request-header field
(Section 9.2 of [Part2]) with the "100-continue" expectation.
o A client MUST NOT send an Expect request-header field (Section 9.2
of [Part2]) with the "100-continue" expectation if it does not
intend to send a request body.

Cheers,
Linyi

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>Talal Butt
>>Sent: Friday, November 26, 2010 11:37 AM
>>To: [email-masked]
>>Subject: [core] Draft needs Asynchronous transaction details
>>
>>I am actively following the list and working on a coap implementation for
our
>>large scale sensinode network. I have implemented the basic coap with
reliable
>>UDP as defined by the coap ID.
>>
>>Currently, I am planning to add the Asynchronous Logic into my
implementation
>>but have noticed that ID is not explaining any Asynchronous scenario in
detail.
>>So the client should keep the asynchronous waiting list, to match the
received
>>token with the waiting request. However, the question is what code in the
ACK,
>>will point out to wait?
>> In this scenario if we can use code=100 -> CONTINUE. This can be a
solution,
>>but again this is not mentioned in the internet draft.
>>
>>Talal Ashraf Butt
>>Research Student
>>Loughborough University
>>
>>_______________________________________________
>>core mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/core

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 27 Nov 2010 22:03:33 +0100

Linyi Tian wrote:
> I believe the status code in ACK should be 202 "Accepted"

No.

When a client sends a confirmable message with a request to a server,
two things happen:

1. The server acknowledges that it received the confirmable message,
so the client can stop retransmitting.

2. The server processes the request and sends a response.

These two things are separate and not coupled in any way. But they can
happen at the same time ("immediate response") or at different times
("deferred response").

If acknowledgement and response happen at different times, the
acknowledgement does not carry a response.

Message that carry neither request nor response have Code 0, no
options and no payload.

Klaus

---

From: tianlinyi 00175029 <[email-masked]>
Date: Mon, 29 Nov 2010 17:37:13 +0800

Hi, Klaus

I fully understand the difference between purpose of Transaction ID and Token. I also understand the sync and async responses.

However you didn't answer the question what code should be returned, 100 or 202?

I noticed that 202 was not defined in CoAP. There is also no discription what 100 means. So that's why i refer to HTTP spec. If we follow the same definition, it looks like 100 is not appropriate and 202 should be used in first ACK (acknowledge the arriavl of the request and indication a seperate response will be sent later).

Cheers,
Linyi

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 29 Nov 2010 14:42:06 +0100

> However you didn't answer the question what code should be returned,

 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

 Both ACKs in this example do not carry a response. So the Code is 0.

 The messages are in detail:

 C: CON + GET coap://server/resource (token=0x5f)

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1 | 0 |   3   |    GET = 1    |           TID=1234            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   5   |   6   |         "server" (6 Octets) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   4   |   8   |        "resource" (8 Octets) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   2   |   1   |     0x5f      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 S: ACK

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1 | 2 |   0   |       0       |           TID=1234            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 S: CON + S_OK (token=0x5f) "Hello World"

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1 | 0 |   1   |   S_OK = 80   |           TID=5068            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   11  |   1   |     0x5f      | "Hello World" (11 Octets) ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 C: ACK

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1 | 2 |   0   |       0       |           TID=5068            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 I agree this should be clarified in the draft, and the draft
 should have more examples for deferred responses.

 Klaus

---

From: [email-masked]
Date: Mon, 29 Nov 2010 15:54:44 +0100

>S: CON + S_OK (token=0x5f) "Hello World"

But is it allowed for an HTTP/CoAP proxy to translate the first ACK with 
code 0 into a 202 Accepted response?
If the answer is yes then code 0 should appear in the translation table 
for CoAP-HTTP codes.

Matthieu

---

From: tianlinyi 00175029 <[email-masked]>
Date: Tue, 30 Nov 2010 01:02:11 +0800

Hi, Klaus

Then what is 100? Is it same with HTTP 100? Why not use well understood code 202 instead of 0? What is the benefit to do so?

Cheers,
Linyi

> >> However you didn't answer the question what code should be 
> returned,>> 100 or 202?
>