Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

[Carsten Bormann <[e-mail]>]

Hi Bill,

> On Jun 17, 2017, at 12:07, Bill Silverajan <[e-mail]> wrote:
> 
> Hi,
> 
>>> It would be good to know what the actual assumptions are.
>>> CoAP clients do trial-and-error until they get a response?
>>> All CoAP endpoints are expected to implement all transport and the pick of transport is just because of the middlebox baggage?
> 
> In discouraging the use of several URI schemes for CoAP, one review recommended a series of steps, in which CoAP over UDP is MTI: Always try UDP first, and if no response is forthcoming, to then resort to TCP. Port 80/443 would always default to CoAP over ws or wss without needing to engage UDP initially. Obviously this has repercussions regarding protocol and application logic.

Right.  It also does not work for one of the main applications of CoAP-TCP: traversal of NATs with short UDP binding lifetimes.  The probe will always work through such a NAT, but then the observation relationships won’t, because the UDP binding is gone by the time the notification needs to be transferred.

(Of course, a server can work around this issue by providing a URI with an IP address that listens on TCP only, so the UDP probe fails.  This likely outcome is wrong on so many levels…)

[…]

> Conversely, it must also be recognised that right now, some mechanisms are bound to the "coap" and "coaps" URI schemes, such as using ".well-known/". Minting new CoAP URI schemes would also require extending this to support them.

Not sure I get this point.  We did add well-known support for the new URI schemes in -07.

Grüße, Carsten