Subject: Re: [core] Closing coap #53 (new): Token length

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 2 Dec 2010 17:29:52 +0100

+1

I fully agree with you, usefulness and/or use case for increasing the
token length is still not clear to me.

A.

On Sat, Nov 27, 2010 at 09:01, Linyi Tian <[email-masked]> wrote:
> Hi, All
>
> I need some clarification for the token discussion. (sorry for missed the
> call).
>
> 1. Did we decide to put state into token and extend the usage for the token?
> 2. If Token is only used as correlation for deferred message, the current
> length (2 bytes) maybe enough.
> 3. If we want to use token for storing state, what is the use case?
>
> I believe before we make a decision we need to understand in which scenario
> we want to use this mechanism.
>
> Cheers,
> Linyi
>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>>Angelo P. Castellani
>>>Sent: Friday, November 26, 2010 4:23 PM
>>>To: Carsten Bormann
>>>Cc: Nicola Bui; Klaus Hartke; Constrained RESTful Environments WG
>>>Subject: Re: [core] Closing coap #53 (new): Token length
>>>
>>>PROS:
>>>a) you can put more information inside the token
>>>
>>>CONS:
>>>a) soft state information in a CoAP server for every request requires
>>>8 bytes for token option, dynamic memory allocation is usually not
>>>done in these devices, especially for small data objects... so if 8 is
>>>the max, it will also be the allocated size
>>>b) matching a request by doing a search can be more complex (64-bit
>>>comparisons are more complex than 16-bit comparisons, especially
>>>because a lot of these devices have 16bit MCUs like MSP430)
>>>
>>>If Token is still to be used for *request/response matching* purposes
>>>the Pros aren't valuable, because I hardly imagine a 64-bit space of
>>>concurrent requests... If we have advantages in that size, the Cons
>>>can be handled and accepted because we obtain a benefit in having it
>>>that big.
>>>
>>>In my opinion Token with 8 bytes makes sense only if someone want to
>>>stuff some information in it (state), so it will be something similar
>>>to a reverse Cookie for CoAP.
>>>
>>>I currently cannot think any valid reason to believe that stuffing
>>>state in the server is the right approach in a REST protocol, please
>>>point me to some valid case if I'm wrong.
>>>
>>>In HTTP server stateless operation is always preserved, to handle
>>>"stateful" sessions of interaction Cookies have been introduced:
>>>preserving server stateless operation, but allowing to build stateful
>>>applications!
>>>
>>>Can we move to a Cookie approach?
>>>
>>>Letting the server define the "Token", and the client store it?
>>>
>>>There are a number of advantages in this:
>>>i) stateless server operation
>>>ii) HTTP compatibility/mapping
>>>iii) if the response has to be deferred, the server can send an ACK
>>>and a Cookie. The client can request again, or the server can send a
>>>new response with the same Cookie?
>>>
>>>Regards,
>>>Angelo
>>>
>>>On Thu, Nov 25, 2010 at 23:48, Carsten Bormann <[email-masked]> wrote:
>>>> On Nov 25, 2010, at 18:13, core issue tracker wrote:
>>>>
>>>>> There is agreement that 0 to 8 bytes is the right size.
>>>>
>>>> Small clarification: There was agreement about this in Wednesday's phone
>>>call.  But we have to validate this on the list.
>>>> Unless there is new discussion on the mailing list within the next week,
> we'll
>>>consider this issue done.
>>>>
>>>> Gruesse, Carsten
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/core
>>>>
>>>_______________________________________________
>>>core mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/core
>
>

---

From: "core issue tracker" <[email-masked]>
Date: Thu, 02 Dec 2010 21:41:48 -0000

#53: Token length

Changes (by zach@…):

  * owner:  => zach@…

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  zach@…            
     Type:  enhancement         |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  coap                |     Version:                    
 Severity:  -                   |    Keywords:                    
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/53#comment:2>
core <http://tools.ietf.org/core/>