Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-15.txt

[Klaus Hartke <[e-mail]>]

Abhijan Bhattacharyya wrote:
> The option should be Unsafe-to-forward. The option definition has been
> modified as below:
>
> "[...] This
> option is Unsafe-to-forward as the intermediary MUST know how to interpret
> this option. [...]"

Unsafe-to-forward does not mean that every intermediary has the
requirement to implement your option. Unsafe-to-forward determines the
behaviour of intermediaries that do *not* implement an option. If an
intermediary receives a request with an unrecognised option that is
unsafe-to-forward, then it must not include that option in its request
towards the origin server.

> Now regarding the other two points:

(Note that these points need to be addressed in the document, not just
on the mailing list.)

>>> What's the impact of the No-Response option on a chain of
> CoAP-to-CoAP proxies?
>
> Since, this option is unsafe-to-forward, the intermediaries must have
> knowledge about the option.

No. See above.

> So, the intermediaries should not wait for any
> responses if the option value is 127.

What do you mean? If an intermediary receives a request with the
No-Response option, should it include the option in its request
towards the origin server? That's a bad idea. See below.

And a client should probably listen to responses even if it suppresses
all responses because a server might still want to send a response,
e.g., to slow down the client. See below.

>>> What's the impact of the No-Response option on caches?
>
> Since the cacheability of the CoAP responses depends on the Response Code so
> the No-Response option should not have any effect on the cacheability.

If a server returns a 4.04 response (or any other cacheable error
response) with Max-Age != 0, then a cache will return that response as
long as Max-Age has not elapsed instead of making a request towards
the origin server. So the caching of error responses protects a server
a bit from clients repeatedly triggering the same error. The
No-Response option destroys this protection. To limit the damage, I
would say that intermediaries MUST NOT include the No-Response option
in their requests.

How does the No-Response option interact with the 4.29 response code
[1]? I would expect that a server is permitted to send this response
even if the client suppresses this response code.

An unrelated nit: Section 2.1 says "To suppress all possible
responses: The maximum reserved response code for CoAP is 7.31". The
range 6.00 to 7.31 is reserved, but not for response codes. The
maximum response code is 5.31.

Klaus

[1] https://tools.ietf.org/html/draft-koster-core-coap-pubsub-04#section-9.3