Hi Yoshi,
OK. I also think we should state that the protocol should notify the failure
events to applications.
Since errors can happen not only in TCP, but also TLS and websocket level,
mentioning only TCP close or reset might not
be enough.
After reviewing with the authors, an additional clarification was appended to
3.4 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files
The opinion of the authors (and Gengyu WEI’s recent response -
https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that
RFC6455 covers the WebSocket case and does not need to be repeated here.
When we use 7252, I think applications basically don't need to implement
timeouts or retry mechanisms as the protocol
provides such things.
RFC7252 provides timeouts and retries because it's implementing a TCP-like
reliability mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1
However, when we use this one, it seems applications will need to have such
mechanisms. Isn't it a bit confusing? I am thinking that
there need to be some guidance here.
BTW, PONG is one example.
For coap-tcp-tls, there are multiple early implementations. This has never been
reported as a source of confusion.
My sense is that we should treat this as an update to RFC7959 based on the
original language:
I don't have a strong opinion here. Updating 7959 is fine for me if it's
clearer to CoAP people.
I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files
Thanks again for helping us to improve the quality of the draft,
…Brian