Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

> On May 10, 2017, at 3:20 AM, Carsten Bormann <[e-mail]> wrote:
> 
> Hi Ben,
> 
> thank your for your review.
> 
> Before I start working on it in more detail, let me pick this one DISCUSS out because I think it is the most momentous issue that needs to be discussed:
> 
>> On May 10, 2017, at 04:27, Ben Campbell <[e-mail]> wrote:
>> 
>> 2) It seems problematic to encode the transport choice in the URI
>> scheme.
>> Section 7 says "They are hosted
>> in distinct namespaces because each URI scheme implies a distinct
>> origin
>> server." IIUC, this means any given resource can only be reached over a
>> specific transport. That seems to break the idea of cross-transport
>> proxies
>> as discussed in section 7.
>> 
>> It also does not seem to fit with a primary motivation for this draft.
>> That
>> is, one might want to use TCP because of local NAT/FW issues. But if
>> there is
>> a resource with a "coap" scheme, I cannot switch to TCP when I'm behind
>> a
>> problematic middlebox, and have an expectation of reaching the same
>> resource.
> 
> 
> I would rephrase the issue as:
> URIs don’t have a good place to put in transport hints.
> 
> (The definition of a transport hint in a URI would be information that lets me set up specific transports without creating a separate resource each time the values of that transport hint differ.)
> 
> Note that the main use case for the document at hand is one where the client may not be able to reach the server on the “main” transport (CoAP over UDP), so negotiation/upgrade(*) mechanisms are not solving the problem.

That’s exactly what I mean by “a primary motivation”. As defined, the name of a resource declares the transport. So if I have a “coap” scheme resource that I cannot reach over UDP, I cannot simply switch to TCP and reach that same resource, even if the server supports both UDP and TCP. I suppose the server could treat the two resources as aliases, but the client cannot know that without some out-of-band agreement. (but see next comment)

So is it expected that people have to decide in advance which transport will be use for any given resource? The middlebox-traversal use case would seem to favor approaches where the client gets to decide what transport to use on the fly.

> 
> The solutions that people are talking about in our domain are about carrying transport alternatives around together.
> E.g., see draft-silverajan-core-coap-protocol-negotiation-05.txt, which provides a way to find out about links from a set of links (the resource directory) while specifying a transport type. [It may be instructive to go through previous versions of this document just to see what we also have tried to do.]

So from an admittedly very quick scan, am I correct to assume that the directory described in that draft could be as “out-of-band” mechanism to declare resource aliases as I mentioned above? So why not use that sort of mechanism to advertise the available transports for an authority, and at least allow the transport selection to be completely decoupled from the scheme?

If people really want to bind transport selection to the resource name, then some such mechanism seems to be a requirement to make the solution in this draft fit for purpose. But the transport-negotiation draft is not yet adopted by CORE. Does it make sense to publish this before that is well on it’s way to ready?


> 
> What we have right now in draft-ietf-core-coap-tcp-tls is what we think is the least ugly way to solve the problem.
> The WG is well aware about its problems.
> We’d rather have a mechanism like transport hints, but we did not find a solution that would not need to update the web architecture.

At least some other protocols do this with DNS NAPTR records. I realize that may not be realistic for constrained devices (and I gather the protocol-negotiation draft attacks that same problem.) SIP, for example, can specify the transport with a URI parameter, which allows a URI to either specify a transport or to be transport-independent (by leaving off the parameter.)

Thanks!

Ben.