Subject: [core] How is the TOKEN option mapped between HTTP and COAP?

From: Paul Duffy <[email-masked]>
Date: Wed, 04 May 2011 11:34:19 -0400

Ideally this would be carried opaquely, end to end, through a 
request/response exchange.

?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 May 2011 17:45:17 +0200

On May 4, 2011, at 17:34, Paul Duffy wrote:

> Ideally this would be carried opaquely, end to end, through a request/response exchange.

HTTP does not need, nor have, a concept like CoAP's Token option, as HTTP's request/response matching is implicit in the order of messages in the TCP connection.  

CoAP does not have a connection (apart from the ephemeral binding in the message ID of a CON/ACK pair), so it needs Token once a simple CON/ACK pair does not suffice.  But there is no end-to-end significance of the Token.

In summary, there is no need for a HTTP/CoAP mapping of Tokens, as Tokens are always handled fully locally in each CoAP leg.

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Wed, 04 May 2011 11:59:55 -0400

> HTTP does not need, nor have, a concept like CoAP's Token option, as HTTP's request/response matching is implicit in the order of messages in the TCP connection.

Agreed, which is why I'm asking.

>
>
> CoAP does not have a connection (apart from the ephemeral binding in the message ID of a CON/ACK pair), so it needs Token once a simple CON/ACK pair does not suffice.

Agreed, TOKEN conceptually implements an application "session"

> But there is no end-to-end significance of the Token.
>

But there does appear the need for a stateful mapping of the TOKEN to 
HTTP connection, correct?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 May 2011 18:33:36 +0200

On May 4, 2011, at 17:59, Paul Duffy wrote:

> But there does appear the need for a stateful mapping of the TOKEN to HTTP connection, correct?

Yes, but that is an implementation issue.
Once you implement both protocols, there is very little remaining to talk about wrt the mapping aspect.
(Originally, we were trying to have more details about possible implementations in the mapping sections, but that grew out of hand quickly.  It appears to be much better for a spec to say just what needs to be said.  We can always add implementation guidance documents later.)

Gruesse, Carsten