|
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 |