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

["weigengyu" <[e-mail]>]

Hi,

> 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.

As the problem described, the upper layer protocol (application layer, http 
or DNS) generally adopts
the lower layer protcoal(transport layer, TCP or UDP) by default or by 
manually configuration
to bind the selected protocols when deliver messages.

Could the upper layer protocol to define an explicit attribute to indicatie 
a selected lower layer protocol
when there are some lower layer protocols to choose?
It is expected that CoAP will be tranferred over UDP, TCP, SMS, or WS.
So, for CoAP protocol and the stacks, besides defining a URL sheme to 
indicate a selected transport protocol,
is it required or possible to define some CoAP facility, such as a CoAP 
option, to inform this indication?


Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carsten Bormann
Sent: Saturday, June 17, 2017 5:25 AM
To: Kovatsch Matthias
Cc: [e-mail]
Subject: Re: [core] Editors' draft of changes to 
draft-ietf-core-coap-tcp-tls-08 after IESG input

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

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core