[core] draft-ietf-core-resource-directory: discovering transport identifiers

[Dave Thaler <[e-mail]>]

Let's say a resource server exposes a "/sensors/temperature" resource it wants to publish in an RD.
That resource is accessible over (say) the OCF protocol at the app layer.
The server supports the OCF protocol over (say) some or all of: coap, coaps, http,
and https (and I note that the draft explicitly allows for http in the last sentence of section 1).
The server supports coap over some or all of: udp, tcp, and websockets.
The server supports each of those over both IPv4 and IPv6.
The server has multiple IPv4 and IPv6 addresses, e.g., on two different subnets,
(and let's say the server has no resolvable DNS name, so it cannot put a hostname in a URI).
So presumably everything needed to learn the protocol stack and endpoint identifier (e.g.,
port number, path, whatever) at each layer must be published in the RD.

But the draft only mentions application/link-format and a single "con" URI
which section 5.4.1 fills in with a coap URI.  In contrast,
draft-ietf-core-coap-tcp-tls-09 sections 7.3 and 7.4 implies that ws(s) URIs
are required in addition in order to express that the coap URI is reachable via
websockets.   Section 7.2 of that draft doesn't even say how to express that
it's reachable over TCP, nor does it explain how to know whether the port number
is the UDP or the TCP port number (since they could be different), when the
server supports both.

As such, the RD draft doesn't seem to be sufficient to support multiple transports.
And the same argument for why draft-ietf-core-coap-tcp-tls changed to not put the
transport in the scheme would argue for the main "con" parameter to be, in my
example, the "ocf:" URI (not "coap:") since coap and http are simply two transports
that get to the exact same resource.

It seems to me that to really solve the RD problem, you need a tree of con URIs,
since it seems the approach is to have a URI for each layer of the stack, and a
client has to be able to discover the entire stack.

Am I missing something?   It would be helpful to add a full example into the RD
draft to show a registration for resource over multiple transport stacks.

Dave