Martin's I-D template toolchain might complain about trailing spaces at some point. But there is make fix-lint

If suite becomes a bitmap, I'd rename it to suite-selection.

What are the intended semantics here? "Requesting one thing at a time"?

Maybe suite-selection. Also, I am not sure, if a bitmap is the best way to do this. How many options do we expect in the foreseeable future? And how many selected suites can be expected, typically?

In general, this should work. Again, just checking.

Using the same size as EAT.
? nonce => bytes .size (8..64),

Good catch. Thanks. I knew that, but forgot it :-)

I prefer token: uint .size 4, to have constant size rather than variable size to make it easier to parse.

Any CBOR parser should take care of that, I think. There might be other benefits provided by fixed length to specific post-processing, but parsing the CBOR data item will not become more difficult with variable length, in practice

Note that the ".size" declaration in the CDDL does not have an influence on the representation size that will be chosen by the encoder. It just limits the range of the number. The encoder most likely will choose "preferred serialization" https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#rfc.section.4.1, i.e. shortest form.

Oh, and if you really want to limit the token to 0..4294967295, you do need the .size 4 or need to use the range 0..4294967295 — is that the intention?

@cabo Yes, my intention was to limit the token to 0..4294967295, so the binary size for the token will not change other than 32bits/4 bytes.
As @henkbirkholz has mentioned having variable size should not be a problem if everybody use the reasonable CBOR parser.
The one of cbor package of python looks really good.
https://bitbucket.org/bodhisnarkva/cbor/src/default/py/cbor/cbor.py

I have seen so many implementation something similar that just reading the first 4 bytes of the member even the size was 8bytes, ignoring the half of the value, ignoring the network byte order, and so on. The issue is that those implementation will work for most of the time, and some few years later, suddenly stops working when the TAM starts to handle more Devices, and then they have untrusted feeling for using the protocol.
In other protocol I have seen ignoring all the valuable information in the header of the packets and skipping of reading the header by just read 20 bytes offset to get the content.

I may be worrying too much, but since the type and token are the mandatory members of array of the teep protocol, I felt limiting the both members to be constant binary size would make things easier in the world.

However, this is just my preference. I am fine with both ways.