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

[Bill Silverajan <[e-mail]>]

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.
>> Web Linking will always include transport hints in the future?
>> It is just a hint even when the publisher of a link knows for sure what transports are implemented in the origin server?
I think it is important to have mechanisms to allow transport hints, 
regardless [1].
>>   
>> How come we still need https and http?
> Right.
>
> I believe we had the best possible solution for this “Gemengelage” (untranslatable German word for a situation where a number of unrelated issues collide and create something utterly complicated to resolve) in -07.
>
> The IESG has a number of people who have the scars from SIP, which ran into a superficially similar, but actually mostly unrelated issue and resolved it by attaching a transport hint to an otherwise identical URI.  We cannot do this as easily as SIP could, but got stuck with the idea that we have to use the same URI scheme for the different transports.
What we learnt from the CoAP Alternative Transport URI work [2] is:

A) Embedding the transport hint in the URI path, fragment or query 
component is a bad idea
B) Placing it in the host in the URI authority component can become 
easily complicated. Moreover, RFC 7320 forbids this.
> Given that URI-Schemes are a dime a dozen (with provisional registrations being easy), I’m not sure that implementers (or downstream SDOs) won’t go the way of registering (or even squatting on) their own transport-specific URI-Schemes to return to sanity.
This is correct. Extending the CoAP application logic instead to support 
a new transport, without using a new URI format, would be more complex. 
It also complicates RD registrations and lookups.

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.

Regards,
Bill

[1] 
https://datatracker.ietf.org/doc/draft-silverajan-core-coap-protocol-negotiation/
[2] 
https://tools.ietf.org/html/draft-silverajan-core-coap-alternative-transports-09#appendix-A