Subject: [core] Tokens -- opaque or maybe better uint?

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Dec 2012 21:18:47 +0100

Offline, I have been asked whether people are happy with the way token values are currently handled.
Right now, you have to store a length *and* a value of up to 8 bytes.
I.e. there are 2**64+2**56+2**48+2**40+2**32+2**24+2**16+2**8+1 = 0x10101010101010101 = 18519084246547628289 token values.

One alternative would be to treat tokens like a uint, i.e. make leading zero bytes insignificant (and SHOULD NOT send).
You could still continue to store length and bytes if that helps your code (e.g., in echoing back a token in a stateless server), but you could also zero-extend the token and just store 8 bytes.
The total token space would drop from 2**64+2**56+2**48+2**40+2**32+2**24+2**16+2**8+1 to just 2**64 = 18446744073709551616 = 0x10000000000000000, so you could store it in a 64-bit long (or long long on C with ILP32 data model).

Personally, I really don't care that much either way, so I wouldn't make the change, but since I also already had the thought that a uint might simplify this, I thought I might want to relay my offline input.  Again, there should be a good reason to make any change at this point, but the breakage might be limited.

(If we do this, we probably also want to think about ETags, the only other opaque structure we have, which also happens to be up to 8-byte.)

Grüße, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Tue, 11 Dec 2012 00:12:38 +0200

No, I really don't think we want to do this. First of all, who has a constrained device that can conveniently store a 64-bit long? Secondly, we have spent a lot of time reinforcing that Token and ETag MUST be treated as opaque. Changing that now is just confusing, not to mention the breaking change. And regarding the storage of Tokens, I don't understand where the unhappiness is coming from. As a server you are just echoing that back (which is even easier now in coap-13) and in a client you decide whether to use a Token in the first place. Even with Observations, you can decide how many to support at one time. 

Zach

On Dec 10, 2012, at 10:18 PM, Carsten Bormann wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 11 Dec 2012 01:21:11 +0000

I agree with Zach. If we added integer semantics to the token, we would still need a token length indication, so it doesn't safe bits in the message.

The only advantage of the integer interpretation would be that you could do native integer comparisons, but given the possible large size of the token and small sizes of the registers this seems not feasible. On architectures that don't support large integers, it would boil down to doing a string comparison but with extra code for omission of possible leading zeros.

Comparing and copying opaque strings is easy enough.

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: 11 December 2012 06:13
To: Carsten Bormann
Cc: [email-masked] WG
Subject: Re: [core] Tokens -- opaque or maybe better uint?

Zach

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 11 Dec 2012 13:20:25 +0000

I would also keep Tokens opaque, as constrained devices usually cannot handle 64-bit ints easily.
Same for ETags to preserve full  freedom on how the values are created.

Ciao
Matthias

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 11 Dec 2012 08:36:49 -0500

+1 for keeping tokens opaque 

(and hopefully we are not all missing something profound that Carsten
wanted to convey with his initial proposal ...)

/Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kovatsch Matthias
Sent: Tuesday, December 11, 2012 8:20 AM
To: Bert Greevenbosch; Zach Shelby; Carsten Bormann
Cc: [email-masked] WG
Subject: Re: [core] Tokens -- opaque or maybe better uint?

I would also keep Tokens opaque, as constrained devices usually cannot
handle 64-bit ints easily.
Same for ETags to preserve full  freedom on how the values are created.

Ciao
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Dec 2012 14:40:02 +0100

OK, my summary is that there is a lot of agreement with continuing to handle Token values (and ETags) as opaque.

Thank you all for reconfirming this!

Grüße, Carsten