Re: [core] 🔔 WGLC draft-ietf-core-coap-tcp-tls

[Brian Raymor <[e-mail]>]

Thanks for the questions and feedback. Partial responses below.



** Questions

> • The bi-directionality of connections is mentioned in the draft. Now suppose a CoAP client on host 1 opens a TCP connection

> (as a TCP client) to a TCP server on host 2, in order to send a CoAP request to it. Now the TCP server (host 2) at some point suddenly

> sends a CoAP request (acting itself as a CoAP client) to the TCP client (host 1). However, there is no CoAP server hosted on host 1.

> What should happen now? E.g. is the request simply ignored or is some kind of error message returned?

> • Same question as above can be stated for TLS and Websockets. Is the behavior the same in these cases?

> • Following the above, should the CSM message have an option to indicate a capability of "being a CoAP server" … ?



Carsten's suggestion on a private thread addresses this set of questions:

    "The intention is for the transport to be bidirectional. If there is a CoAP client, it is easy to have a CoAP server that 4.04s every request. Yes, that is worth making explicit."



> • Page 20: Alternative-Address Option - the semantics of including multiple of these options is not defined. Can the receiver pick any of the addresses?

> Or does it need to try the first address first? And then keep trying all alternatives until one succeeds, or not?



Unless Carsten or Hannes (authors of draft-bormann-core-coap-sig-02) have a preference, I would suggest that the addresses are unordered (pick any).

Tracked in https://github.com/core-wg/coap-tcp-tls/issues/115



> • Page 28, Section 6.5: is it correct to conclude that, for Websocket connections, the default Uri-Port value will be 80 if using "coap+ws" scheme

> with its default TCP port, and 443 if using "coaps+ws" scheme with its default TCP port? Just for my understanding.


It depends on the direction. As stated "The default value of the Uri-Port Option is the destination TCP port."



> • Appendix A: Why is the update of Observe [RFC7641] done in the Appendix and not in a main section?

> There must have been a good reason to place it there; but it looks strange since it formally updates RFC 7641.



There was a desire to have a clean separation between the transport itself and the updates to RFC 7641. Carsten suggested

collecting the changes in an Appendix which was adopted. My original preference was to separately update RFC 7641.