[core] draft-ietf-core-stateless-03.txt: very constrained servers

[Carsten Bormann <[e-mail]>]

On Oct 29, 2019, at 19:46, [e-mail] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Constrained RESTful Environments WG of the IETF.
> 
>        Title           : Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
>        Author          : Klaus Hartke
> 	Filename        : draft-ietf-core-stateless-03.txt

Thank you, Klaus.

While I haven’t completed by chair’s review of the new version yet, one issue stands out, as it cannot really be solved beautifully, and it is hard to give advice that properly covers all the situations.

   If a server supports extended token lengths but receives a request
   with a token of a length it is unwilling or unable to handle, it MUST
   NOT reject the message, as that would imply that extended token
   lengths are not supported at all.  Instead, if the server cannot
   handle the request at the time, it SHOULD return a 5.03 (Service
   Unavailable) response; if the server will never be able to handle
   (e.g., because the token is too large), it SHOULD return a 4.00 (Bad
   Request) response.

(…followed by a few design notes that are useful to read.)

The situation that may not be properly covered here is a constrained server that doesn’t have resources to handle a full-size IP packet, e.g. for performing outward adaptation layer fragmentation of the response.

So far, we haven’t really had a “you must be this tall to play” on CoAP, and that includes message size.  We do have recommendations (1152 bytes, Section 4.6 of RFC 7252), but these are more for guiding a client.  A server might have resources that genuine never need large requests, and it has control over the response size (e.g., using block-wise where needed).  With an incoming token of essentially unlimited length (dreaming up a random limit doesn’t help, either), this situation changes.

So what can a constrained server that is limited to, say, 256-byte packets, do?

* It can reject all extended token lengths.  Safe, but makes it less useful for stateless proxying.

* It can accept, say, extended token lengths up to 37 bytes.  Great.  Now, the above means:

If a client sends a request with a 999 byte token, the server

* cannot send a response, because that would need to copy the full token

* cannot send a Reject, because that has a MUST NOT in the text above

So it seems the current text requires it to remain silent.  That sure works, and is easy to implement, but makes for a slow and wasteful discovery process.

Grüße, Carsten