Re: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00)

[Klaus Hartke <[e-mail]>]

Ari Keränen wrote:
> I guess it depends on the use case and how much logic we would have in the client. For many cases just backing-off is probably enough. But for example for a case where shooting measurement data at high speed is causing overload but updating RD registration would be fine, making a difference between C and A&B could be useful.

What about using 5.03 for C and 4.29 for A?

It's perfectly fine that a server tells one client it's overloaded
while continuing to serve other clients.

Alternatively: Define a content-format that provides more detailed information.

>> --> "A server MAY return a 4.29 (Too Many Requests) response if a CoAP
>> client request messages more often than the server is capable or
>> willing to handle."
>
> The SHOULD of course only applies to who ever has implemented this spec.

Right. It therefore sounds a bit like: "You MAY implement the spec. If
you decide to implement the spec, you SHOULD implement the spec."
That's weird :-)

>>>  If a client receives the 4.29 Response Code from a CoAP server to a
>>>  request, it SHOULD NOT send the same request to the server before the
>>>  time indicated in the Max-Age option has passed.
>>
>> Not sure if this can be required. It's more like the client is
>> encouraged to not retry before Max-Age expires.
>
> Do you mean it can't be required for implementations that don't understand the code or in general?

In general, judging by the (lack of) use of KEYWORDS in [1] and [2].

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-5.9.3.4
[2] https://tools.ietf.org/html/rfc6585#section-4