Subject: [core] How to resolve HTTP<->CoAP URI authority?

From: Kerry Lynn <[email-masked]>
Date: Mon, 14 Mar 2011 02:33:44 -0400

I hope to clear up a continuing confusion on my part.

During the last WebEx, while Angelo was describing the HTTP<->CoAP
proxy, I asked on jabber whether the URI syntax was something like the
http://hostA:portA/core/hostB:portB/path syntax that was used in prior
PlugFests.  The answer I heard was "that's appropriate for a gateway,
not a proxy".

A few people (Peter vdS, Angelo, Akbar, & others) gathered on a call
last week to further discuss this and other proxy issues.  The consensus
on URIs was that ideally the proxy would expose resources via HTTP
and would simply change the scheme part of the URI to communicate
with the origin server, keeping the rest of the URI unchanged.

Now first I will say that Section 6.1 of the draft spec seems ambivalent
about the use of DNS for resolving the host part of the URI, whereas
RFC 2616 clearly assumes DNS when it refers to "fully qualified
domain names" in section 3.2.2, "Internet host" in section 14.23, and
"DNS Spoofing" in section 15.3.

Let's assume that we keep all of our options open and allow this proxy
to be placed anywhere on the Internet (I don't think that's a good idea,
but that's another conversation).  I think the consequence is we must
assume that http://host.example.com/path and coap://host.
example.com/path are both legitimate targets for (different) arbitrary
clients.  What then is the resolver strategy for the coap client?

The http client will use DNS and might get back a CNAME and/or
AAAA (or A) record, resulting in a resolution of host to IP address.
Port defaults to 80 unless it is specified, etc. etc.  If the same strategy
is used for coap then doesn't this pretty much imply that the origin
server and proxy are on the same host?  If not, what am I missing?

Now we could consider the scheme as part of the resolver strategy
and look up the coap *service* instead of *host* using DNS-SD.  This
would work as follows:

- Send a query for SRV record named "_coap._udp.host.example.com"
  If this record is defined, AAAA record and port for the service will be
  returned.  A lookup for a TXT record with the same name, if defined,
  will return additional key=value pairs that pertain to the service.

- If the SRV record does not exist, send a query for ANY with the name
  "host.example.com" and resolve to IP address as http does.

If the latter approach is used, I still don't see how http and coap can
use the same URI authority unless the cservices are co-resident on
the same host.  Please adjust my point of view...

TIA, -K-