request with serialized state as tokenWhat does that actually mean? Surely the client needs to keep some information to map that token to the coming response later on?
message transmission stateis,
Extended Tokens and Stateless Clients n the Constrained Application Protocol (CoAP)
The draft provides considerations for CoAP endpoints and intermediaries in order to reduce the amount of state that needs to be kept.
To begin with, it explains that current CoAP eps need to keep some state in the form of a token, which is needed to to identify the request and the response.
The current token length is 8 bytes, which does not leave a lot of space to add state. Thus the draft proposes to extend it and thus it updates RFC7252 and RFC8323.
The new extension field is called Extended Token Length and extends the Token Lenght field (TKL). The new max length is 65804 bytes , it contains a new parameter to indicate its size. It requires a discovery mechanism, which can be done with the Capabilities and Settings Messages (CSMs) or with trial and error by means of a new Capability option specified in the draft (Extended-Token-Lengths Capability Option).
Trial and error works by sending a message with a size larger than the usual 8 bytes, which the server simply rejects if it doesn't support it. It thus requires no mandatory support in the server.
Intermediaries may support this option too and store some of the state in the token. Some state is presumably origin IP and things like that. On a chain of intermediaries, presumably they would all have to support eTKL.
The eTKL needs to be identity protected. When using application security encryption is also mandatory.
TBD
The document has IANA updates. The document is intended for Standards Track.
TBD
[ ] If this is a bis
document, have all of the errata been considered?
IANA Considerations: