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

[Carsten Bormann <[e-mail]>]

On Jun 16, 2017, at 22:49, Kovatsch Matthias <[e-mail]> wrote:
> 
> Hi all
>  
> To me it feels, we need a special session for this during IETF 99. It is really hard to follow the arguments in the e-mails, as there are so many unspoken assumptions, solutions-in-mind, and misunderstandings. I would guess, I am not the only one who cannot get a clear picture of the (assumed) problem, implications, and possible solutions.
>  
> It would be good to know what “what URI schemes actually mean” means.
> To me, it defines the syntax and semantics of the rest of the URI. Important semantics would be if the port is a UDP or a TCP port.
>  
> It would be good to know how the mess of HTTP 1.x, SPDY1, SPDY2, SPDY3, H2, and QUIC is actually solved.
> To my understanding in particular SPDY and QUIC are solved by out-of-band info patched into the browser (~Chrome knew what gmail.com speaks…~).
>  
> 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?
> 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?
> …
>  
> 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.

http:// and https:// have the same problem, but
1 — it was resolved that the resources under these two schemes are unrelated,
2 — people got used to the pain caused by this.

(We are mirroring this with coap:// and coaps://, and I don’t think this is controversial — it really does make a semantic difference whether there are transport security expectations bound to the resolution of that URI or not.)

With respect to the UDP/TCP/WS decision, we tried to do (1) in -07, but did not have (2), obviously.
(I believe (1) is not so bright for UDP coap vs. TCP coap, so if (1) doesn’t help getting acceptance then we shouldn’t do it.)

The consensus document governing registration of URI schemes is RFC 7595.  I believe we were in full compliance with that with -07.  I don’t want to run process arguments before we have completed the technical discussion, but I actually believe e.g. section 3.3 of that document is less clearly satisfied by -09 than it was by -07.  More importantly than those process issues, my problem is that the issues the IESG members have in mind appear to be undocumented, so I can’t learn about them from a document that exposes them in a detailed manner.

Coap-tcp of course also was done in the knowledge that there are other transports waiting, such as webrtc-dc, SMS or even slipmux.  It seems unlikely these can be done with a URI-Scheme that is common with the IP-address based ones.

We cannot really learn much from the way HTTP solves its transport vagaries because those solutions are based on the ability to put a lot of complexity into implementations.  For HTTP, the URI has a much more user-visible role, and it is likely appropriate to incur this complexity to keep up the fiction that there is only one HTTP.  CoAP is meant to be direct and to the point, without relying on tons of pre-configuration, learning, or indirection, so any happy eyeball style approaches are grossly suboptimal.
(They may still be necessary in certain not so nice cases; cf. the work on Thin ICE.)

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.

Having a meeting about the URI-Scheme issue might indeed be the only way forward remaining.  
It is also a slow way forward.

Grüße, Carsten