Hi Spencer, I’m not Yoshi :-), but I just have started working on an update of https://lwig-wg.github.io/coap/#rfc.section.6 with some of the new information that relates to CoAP over reliable; I hope that I will be able to push this during this week. Note that CoAP over TCP/TLS/WS does address application layer acknowledgement beyond the request-response acknowledgement semantics by introducing the custody option of the PING/PONG signaling messages. This may be useful in compensating the decrease of information available to the CoAP application as a result of moving some of the transport functionality into TCP. Grüße, Carsten > On May 8, 2017, at 05:17, Spencer Dawkins at IETF <spencerdawkins.ietf@xxxxxxxxx> wrote: > > Hi, Yoshi, > > On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida <nishida@xxxxxxxxxxxxxx> wrote: > Hello, > As far as I've read -08 draft, I think this point has not been addressed yet. I hope some folks could elaborate a bit more if they think this is not an important point for the draft. > > I've seen the subsequent e-mails in reply to yours, but it's not obvious to me whether you think this point was addressed after reading those e-mails. > > What do you think? > > Thanks, > > Spencer > > -- > Yoshi > > On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor <Brian.Raymor@xxxxxxxxxxxxx> wrote: > I think that I understand your perceptions better. Prior to adoption of coap-tcp-tls and before I was active in the WG, I recall discussions related to the confusion over application vs transport reliability in CoAP especially as related to CON and NON. What was intended? > > > > Tim Carey outlined some concerns in: > > https://tools.ietf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#section-2 > > > > This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf - starting on slide 23. > > > > And in a related thread on the mailing list back in 2015 - https://www.ietf.org/mail-archive/web/core/current/msg06280.html - Carsten responded: > > > > > In any case, CON and NON are about message layer semantics, not about application semantics > > > -- you gave them a meaning they don't have. > > > > By IETF 94, the authors were reporting – “Most of the Confusion around CON/NON was resolved”. > > > > Where relevant, I’ve added clarifications - such as the Appendix related to differences in Observe for reliable transports. > > > > Both Carsten and Hannes could probably offer more context if needed. > > > > From: Yoshifumi Nishida [mailto:nishida@xxxxxxxxxxxxxx] > Sent: Friday, April 21, 2017 2:08 PM > To: Brian Raymor <Brian.Raymor@xxxxxxxxxxxxx> > Cc: Yoshifumi Nishida <nishida@xxxxxxxxxxxxxx>; tsv-art@xxxxxxxx; draft-ietf-core-coap-tcp-tls@xxxxxxxx; core@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07 > > > > Hi Brian, > > > > Just in case, > > Reliable transports only provide reliability at transport level. It doesn't provide reliability in application protocol level. > > > > RFC7252 has reliability mechanisms in it since it uses UDP. This means it has abilities to check both transport and app level reliability. > > This draft only provides transport level reliability and apps will need to detect app protocol failure by themselves. > > This means 7252 and this draft are not totally equivalent from the viewpoint of applications. > > > > I am not saying this is wrong or bad, but I believe app developer should aware this point. > > -- > > Yoshi > > > > On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <Brian.Raymor@xxxxxxxxxxxxx> wrote: > > 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 > > > > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tsv-art > > > _______________________________________________ > core mailing list > core@xxxxxxxx > https://www.ietf.org/mailman/listinfo/core