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

[Carsten Bormann]

I have generate a first editors’ draft of what might become draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
(This draft addresses DISCUSSes, but almost no COMMENTS; see https://github.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done.)

This has a bit of Brownian motion (default ports etc.), but also one important change:

IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Please see:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-coap-tcp-tls&url2=https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-ietf-core-coap-tcp-tls.txt

for the changes from -08, and

https://core-wg.github.io/coap-tcp-tls/iesg/

for a full document.

For example,

https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8

is a new section, but many other sections concerned with URIs and URI schemes have received changes.

It is important if the WG can live with this change, or whether we need to incur further delay pushing back on this change.
Please let us know!

Grüße, Carsten

[Kraus Achim (INST/ECS4)]

Hi Carsten,

Post by Carsten Bormann
IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Assuming a system, which supports CoAP over UDP and over TCP, how should such a system select, if UDP or TCP is intended to be used for a given destination?

Mit freundlichen Grüßen / Best regards

Achim Kraus

(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn



-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Carsten Bormann
Sent: Montag, 15. Mai 2017 16:32
To: core <***@ietf.org>
Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

I have generate a first editors’ draft of what might become draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
(This draft addresses DISCUSSes, but almost no COMMENTS; see https://github.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done.)

This has a bit of Brownian motion (default ports etc.), but also one important change:

IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Please see:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-coap-tcp-tls&url2=https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-ietf-core-coap-tcp-tls.txt

for the changes from -08, and

https://core-wg.github.io/coap-tcp-tls/iesg/

for a full document.

For example,

https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8

is a new section, but many other sections concerned with URIs and URI schemes have received changes.

It is important if the WG can live with this change, or whether we need to incur further delay pushing back on this change.
Please let us know!

Grüße, Carsten

_______________________________________________
core mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/core

[Klaus Hartke]

Post by Kraus Achim (INST/ECS4)
Assuming a system, which supports CoAP over UDP and over TCP, how should such a system select, if UDP or TCP is intended to be used for a given destination?

This one is even more fun:

coap://2259499800/path/to/resource

Is this CoAP over UDP or TCP to a server with IP address 134.173.59.24
(there are URI parsers that accept "dotless" IPv4 addresses) or CoAP
over SMS to a server with phone number [phone]?

Klaus

[Carsten Bormann]

Post by Klaus Hartke

Post by Kraus Achim (INST/ECS4)
Assuming a system, which supports CoAP over UDP and over TCP, how should such a system select, if UDP or TCP is intended to be used for a given destination?

coap://2259499800/path/to/resource
Is this CoAP over UDP or TCP to a server with IP address 134.173.59.24

Answer: No. RFC 3986 says:

IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet

dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255

Post by Klaus Hartke
(there are URI parsers that accept "dotless" IPv4 addresses)

That may have been an amusing quirk for a while, but is not supported by the URI standard.
I hope people don’t start doing in the CoAP space what has been deprecated in the HTTP space for a long time...

Post by Klaus Hartke
or CoAP over SMS to a server with phone number [phone]?

I don’t think we will be able to address CoAP over SMS with the same Authority (RFC 3986) construct that we use for CoAP over IP-based transports. The latter all are based on IP addresses and port numbers (even if the port numbers may be for different transport protocols). But the CoAP over SMS document is not before the IESG at this point in time. By the way, we are still looking for reviews for the latter (https://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-06) so we can adopt it as a WG document.

Grüße, Carsten

[Carsten Bormann]

Well, I just tried to realize what the IESG thought was right. But I can't fail to notice that the existing solution didn't really address the situation very well either, except where the server (or other entity supplying the link) knew exactly what the client should be doing. Section 7.8 is trying to give some guidance, but it will hardly ever be good enough to propose solutions for all possible situations.

Sent from mobile

Post by Kraus Achim (INST/ECS4)
Hi Carsten,

Post by Carsten Bormann
IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Assuming a system, which supports CoAP over UDP and over TCP, how should such a system select, if UDP or TCP is intended to be used for a given destination?
Mit freundlichen GrÌßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
GeschÀftsfÌhrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
-----Original Message-----
Sent: Montag, 15. Mai 2017 16:32
Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
I have generate a first editors’ draft of what might become draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
(This draft addresses DISCUSSes, but almost no COMMENTS; see https://github.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done.)
IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-coap-tcp-tls&url2=https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-ietf-core-coap-tcp-tls.txt
for the changes from -08, and
https://core-wg.github.io/coap-tcp-tls/iesg/
for a full document.
For example,
https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8
is a new section, but many other sections concerned with URIs and URI schemes have received changes.
It is important if the WG can live with this change, or whether we need to incur further delay pushing back on this change.
Please let us know!
GrÌße, Carsten
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Dave Thaler]

I haven’t seen any response to my WG post about resource directory so I’ll add onto Carsten’s response here which I agree with.
Specifically draft -09 says:
7.1<https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09#section-7.1>. Use of the "coap" URI scheme with TCP

The "coap" URI scheme defined in Section 6.1 of [RFC7252]<https://tools.ietf.org/html/rfc7252#section-6.1> can also be

used to identify CoAP resources that are intended to be accessible

using CoAP over TCP.



The syntax defined in Section 6.1 of [RFC7252]<https://tools.ietf.org/html/rfc7252#section-6.1> applies to this

transport, with the following change:



o The port subcomponent indicates the TCP port at which the CoAP

server is located. (If it is empty or not given, then the default
port 5683 is assumed, as with UDP.)

The problem I have with the above text is that it makes the meaning of the port in the URI be ambiguous, which is problematic.
You cannot assume (since no such requirement is stated in the doc) that the UDP port number and TCP port number are the same.
So let’s say the server uses ephemeral ports for a given resource that is accessible over both UDP and TCP, and it got given
UDP port 50000 and TCP port 51000. Does it have two URIs for that resource? i.e.
coap://hostname:50000/resource/path
coap://hostname:51000/resource/path

If a client gets either or both of those, it has no idea whether the port number is a UDP or a TCP port number, and if it guesses wrong,
it’s a completely different resource (e.g., /resource/path on UDP port 51000 might be a different app with a different resource).
As such, there is no guarantee of interoperability. Indeed an RFC 7252 compliant client will treat both as UDP port numbers,
and can end up accessing the wrong resource as a result. That breaks backwards compatibility.

Hence unless someone can explain why this doesn’t break backwards compatibility, I think section 7.1 in draft-09 is broken.

Dave

From: core [mailto:core-***@ietf.org] On Behalf Of Carsten Bormann
Sent: Monday, May 15, 2017 8:45 AM
To: Kraus Achim (INST/ECS4) <***@bosch-si.com>
Cc: ***@ietf.org
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

Well, I just tried to realize what the IESG thought was right. But I can't fail to notice that the existing solution didn't really address the situation very well either, except where the server (or other entity supplying the link) knew exactly what the client should be doing. Section 7.8 is trying to give some guidance, but it will hardly ever be good enough to propose solutions for all possible situations.

Sent from mobile

On 15. May 2017, at 16:52, Kraus Achim (INST/ECS4) <***@bosch-si.com<mailto:***@bosch-si.com>> wrote:
Hi Carsten,


IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Assuming a system, which supports CoAP over UDP and over TCP, how should such a system select, if UDP or TCP is intended to be used for a given destination?

Mit freundlichen GrÌßen / Best regards

Achim Kraus

(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com<http://www.bosch-si.com>

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
GeschÀftsfÌhrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn



-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Carsten Bormann
Sent: Montag, 15. Mai 2017 16:32
To: core <***@ietf.org<mailto:***@ietf.org>>
Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

I have generate a first editors’ draft of what might become draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
(This draft addresses DISCUSSes, but almost no COMMENTS; see https://github.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done.)

This has a bit of Brownian motion (default ports etc.), but also one important change:

IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Please see:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-coap-tcp-tls&url2=https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-ietf-core-coap-tcp-tls.txt

for the changes from -08, and

https://core-wg.github.io/coap-tcp-tls/iesg/

for a full document.

For example,

https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8

is a new section, but many other sections concerned with URIs and URI schemes have received changes.

It is important if the WG can live with this change, or whether we need to incur further delay pushing back on this change.
Please let us know!

GrÌße, Carsten

_______________________________________________
core mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/core

[Kovatsch Matthias]

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?

Ciao,
Matthias


From: core [mailto:core-***@ietf.org] On Behalf Of Dave Thaler
Sent: Thursday, 15 June 2017 20:08
To: Carsten Bormann <***@tzi.org>; Kraus Achim (INST/ECS4) <***@bosch-si.com>
Cc: ***@ietf.org
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

I haven’t seen any response to my WG post about resource directory so I’ll add onto Carsten’s response here which I agree with.
Specifically draft -09 says:
7.1<https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09#section-7.1>. Use of the "coap" URI scheme with TCP

The "coap" URI scheme defined in Section 6.1 of [RFC7252]<https://tools.ietf.org/html/rfc7252#section-6.1> can also be

used to identify CoAP resources that are intended to be accessible

using CoAP over TCP.



The syntax defined in Section 6.1 of [RFC7252]<https://tools.ietf.org/html/rfc7252#section-6.1> applies to this

transport, with the following change:



o The port subcomponent indicates the TCP port at which the CoAP

server is located. (If it is empty or not given, then the default
port 5683 is assumed, as with UDP.)

The problem I have with the above text is that it makes the meaning of the port in the URI be ambiguous, which is problematic.
You cannot assume (since no such requirement is stated in the doc) that the UDP port number and TCP port number are the same.
So let’s say the server uses ephemeral ports for a given resource that is accessible over both UDP and TCP, and it got given
UDP port 50000 and TCP port 51000. Does it have two URIs for that resource? i.e.
coap://hostname:50000/resource/path
coap://hostname:51000/resource/path

If a client gets either or both of those, it has no idea whether the port number is a UDP or a TCP port number, and if it guesses wrong,
it’s a completely different resource (e.g., /resource/path on UDP port 51000 might be a different app with a different resource).
As such, there is no guarantee of interoperability. Indeed an RFC 7252 compliant client will treat both as UDP port numbers,
and can end up accessing the wrong resource as a result. That breaks backwards compatibility.

Hence unless someone can explain why this doesn’t break backwards compatibility, I think section 7.1 in draft-09 is broken.

Dave

From: core [mailto:core-***@ietf.org] On Behalf Of Carsten Bormann
Sent: Monday, May 15, 2017 8:45 AM
To: Kraus Achim (INST/ECS4) <***@bosch-si.com<mailto:***@bosch-si.com>>
Cc: ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

Well, I just tried to realize what the IESG thought was right. But I can't fail to notice that the existing solution didn't really address the situation very well either, except where the server (or other entity supplying the link) knew exactly what the client should be doing. Section 7.8 is trying to give some guidance, but it will hardly ever be good enough to propose solutions for all possible situations.

Sent from mobile

On 15. May 2017, at 16:52, Kraus Achim (INST/ECS4) <***@bosch-si.com<mailto:***@bosch-si.com>> wrote:
Hi Carsten,

IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Assuming a system, which supports CoAP over UDP and over TCP, how should such a system select, if UDP or TCP is intended to be used for a given destination?

Mit freundlichen GrÌßen / Best regards

Achim Kraus

(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com<http://www.bosch-si.com>

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
GeschÀftsfÌhrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn



-----Original Message-----
From: core [mailto:core-***@ietf.org] On Behalf Of Carsten Bormann
Sent: Montag, 15. Mai 2017 16:32
To: core <***@ietf.org<mailto:***@ietf.org>>
Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

I have generate a first editors’ draft of what might become draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
(This draft addresses DISCUSSes, but almost no COMMENTS; see https://github.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done.)

This has a bit of Brownian motion (default ports etc.), but also one important change:

IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Please see:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-coap-tcp-tls&url2=https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-ietf-core-coap-tcp-tls.txt

for the changes from -08, and

https://core-wg.github.io/coap-tcp-tls/iesg/

for a full document.

For example,

https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8

is a new section, but many other sections concerned with URIs and URI schemes have received changes.

It is important if the WG can live with this change, or whether we need to incur further delay pushing back on this change.
Please let us know!

GrÌße, Carsten

_______________________________________________
core mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/core

[Carsten Bormann]

Post by Kovatsch Matthias
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

[Bill Silverajan]

Hi,

Post by Carsten Bormann

Post by Kovatsch Matthias
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.

Post by Carsten Bormann

Post by Kovatsch Matthias
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].

Post by Carsten Bormann

Post by Kovatsch Matthias
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.

Post by Carsten Bormann
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

[Carsten Bormann]

Hi Bill,

Hi,

Post by Kovatsch Matthias
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

[Dave Thaler]

Agree with Carsten. Also, Adam Roach pointed out that some protocols solve the port number
discovery problem by using SRV record lookups. So I can see a couple possible ways forward
that could work, with different tradeoffs:

1) Use separate URI schemes, as draft -07 did, and simply accept the fact that two URIs
(e.g., coap: and coap+tcp: URIs) might refer to the same resource. Indeed RFC 3986 section 6.1

Even though it is possible to determine that two URIs are equivalent,
URI comparison is not sufficient to determine whether two URIs
identify different resources. For example, an owner of two different
domain names could decide to serve the same resource from both,
resulting in two different URIs. Therefore, comparison methods are
designed to minimize false negatives while strictly avoiding false
positives.

2) Specify that the port number in a coap URI, if present, is specifically a UDP port number.
Port numbers for any other transports must be resolved using SRV record lookups,
and the choice of transport protocol must be done by some algorithm by which the
client can try various ones until one works. The downside is extra complexity in the
client, and extra traffic on the network (both of which might be significant downsides
in a constrained network or a constrained client).

3) Specify a mechanism whereby lower-layer identifiers (e.g., transport specific URIs like the
wss: URI shown in the coap-tcp draft -09) can be resolved for a given coap URI. E.g., via a
resource directory or similar functionality built into a server. The downside is extra
complexity in both clients and servers, and extra specification work for the WG that the
coap-tcp draft would be blocked on before it would be usable. This also requires a way
to discovery TCP endpoint information either by defining a URI format or by making the
discovery mechanism be capable of passing something other than URIs.

Obviously I'm in favor of approach #1 (which is also the approach OCF already took for its
standard), but any of the above would be possible. Maybe there's other variations too.
But I think we have to pick one before coap-tcp is usable.

Also to Carsten's point about the IETF's issues with #1 not being in any document, I agree.
As the editor of RFC 7595, I am willing to co-edit a (not coap-specific) document on this general
topic to ensure it's fair and applicable to a wide variety of scenarios including our constrained
node/network scenarios.

Dave

-----Original Message-----
Sent: Saturday, June 17, 2017 5:32 AM
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08
after IESG input
Hi Bill,

Post by Bill Silverajan
Hi,

Post by Kovatsch Matthias
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?

Post by Bill Silverajan
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.
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…)
[…]

Post by Bill Silverajan
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
_______________________________________________
core mailing list
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
etf.org%2Fmailman%2Flistinfo%2Fcore&data=02%7C01%7Cdthaler%40micro
soft.com%7C1ad8529c19f343d5017908d4b57ce883%7C72f988bf86f141af91ab
2d7cd011db47%7C1%7C0%7C636332995469085604&sdata=6rpivhUTBq5mJ2C
biutiISXwkLW3g9FLQfboOq5zj5g%3D&reserved=0

[Bill Silverajan]

Hi Carsten,

Post by Carsten Bormann
Hi Bill,

Hi,

Post by Kovatsch Matthias
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…)
[…]

As a sort of last-resort measure, I can envisage working out a
server-initiated protocol negotiation mechanism requiring the client to
switch transports, or to a lesser extent, presenting a preference order
for the alternate transport that should be subsequently used.

Post by Carsten Bormann

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.

Yes, -07 did support it. My (fairly trivial) point was aimed at possible
provisional registrations made by implementers for convenience.

Regards,
Bill

[weigengyu]

Hi,

Post by Carsten Bormann
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: ***@ietf.org
Subject: Re: [core] Editors' draft of changes to
draft-ietf-core-coap-tcp-tls-08 after IESG input

Post by Carsten Bormann
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
***@ietf.org
https://www.ietf.org/mailman/listinfo/core

[Carsten Bormann]

And the flip answer is "happy bearing balls" (we don't have eyeballs in things)...

Sent from mobile

Post by Kraus Achim (INST/ECS4)
Hi Carsten,

Post by Carsten Bormann
IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.

Assuming a system, which supports CoAP over UDP and over TCP, how should such a system select, if UDP or TCP is intended to be used for a given destination?
Mit freundlichen GrÌßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
GeschÀftsfÌhrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
-----Original Message-----
Sent: Montag, 15. Mai 2017 16:32
Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
I have generate a first editors’ draft of what might become draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
(This draft addresses DISCUSSes, but almost no COMMENTS; see https://github.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done.)
IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-coap-tcp-tls&url2=https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-ietf-core-coap-tcp-tls.txt
for the changes from -08, and
https://core-wg.github.io/coap-tcp-tls/iesg/
for a full document.
For example,
https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8
is a new section, but many other sections concerned with URIs and URI schemes have received changes.
It is important if the WG can live with this change, or whether we need to incur further delay pushing back on this change.
Please let us know!
GrÌße, Carsten
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Carsten Bormann]

I just pushed a couple more commits, this time addressing some input from the IESG that the ADs downgraded from DISCUSS to COMMENT.

In particular the text I generated on cipher suites needs attention from implementers and TLS experts.
(The gist is that CoAP over WebSockets should use what is available in browsers and secure [JavaScript code may not have a lot of influence on the cipher suites anyway], while CoAP over TLS should use what is available in constrained devices, i.e. the cipher suites recommended in RFC 7925 — even though any back-end usage of CoAP over TLS may want to use RFC 7525 cipher suites instead.)

Please use the links below, which now include the changes for these last two commits.

Grüße, Carsten

Post by Carsten Bormann
I have generate a first editors’ draft of what might become draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
(This draft addresses DISCUSSes, but almost no COMMENTS; see https://github.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done.)
IESG members have asked us to stop proliferating URI schemes, and as a result the draft remains with coap:// and coaps:// for all new transports.
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-coap-tcp-tls&url2=https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-ietf-core-coap-tcp-tls.txt
for the changes from -08, and
https://core-wg.github.io/coap-tcp-tls/iesg/
for a full document.
For example,
https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8
is a new section, but many other sections concerned with URIs and URI schemes have received changes.
It is important if the WG can live with this change, or whether we need to incur further delay pushing back on this change.
Please let us know!
Grüße, Carsten