Christian Amsüss
2017-07-19 12:42:24 UTC
Hello working group,
going over the notes from the morning session and reading Dave's
multi-transport-uris, it didn't become completely clear to me why we can
not use DNS-SD for resolution of coap+at URIs, or why Dave's 3.4 is
not already the way to go. (For URIs like coap+at://[2001:db8::1]/, this
would not do anything).
Suppose we specify for coap+at that when the operating system is looking
up the reg-name, it needs to go through SRV lookup. The client could
then obtain host and port from a direct lookup if it has a or a few
particular transport(s) in mind (_coap._tcp.hostname,
_coap+ws._tcp.hostname with Hostname and Path being transported in TXT)
or ask for all transports using _services._dns-sd._udp.hostname.
As said, that'd only be for coap+at lookups of things that are DNS names
(in which case the client needs to have DNS anyway, and can probably
afford doing that via SRV just as well as using any other mechanism).
If a constrained device that can not do DNS lookup is passed a link, it
could receive it with target attributes like
<coap+at://my-device.example.com/my/path>;at="udp6:[fd00::1234]:56830
udp4:10.0.12.34:56830"
(possibly with some lifetime information as well), and forego that
lookup, or a device with a DNS stack could still use that information to
save the roundtrips.
This sounds like a relatively simple solution to me, so I probably
missed something (possibly also Dave already suggesting that with
different words) -- but what?
Thanks
Christian
going over the notes from the morning session and reading Dave's
multi-transport-uris, it didn't become completely clear to me why we can
not use DNS-SD for resolution of coap+at URIs, or why Dave's 3.4 is
not already the way to go. (For URIs like coap+at://[2001:db8::1]/, this
would not do anything).
Suppose we specify for coap+at that when the operating system is looking
up the reg-name, it needs to go through SRV lookup. The client could
then obtain host and port from a direct lookup if it has a or a few
particular transport(s) in mind (_coap._tcp.hostname,
_coap+ws._tcp.hostname with Hostname and Path being transported in TXT)
or ask for all transports using _services._dns-sd._udp.hostname.
As said, that'd only be for coap+at lookups of things that are DNS names
(in which case the client needs to have DNS anyway, and can probably
afford doing that via SRV just as well as using any other mechanism).
If a constrained device that can not do DNS lookup is passed a link, it
could receive it with target attributes like
<coap+at://my-device.example.com/my/path>;at="udp6:[fd00::1234]:56830
udp4:10.0.12.34:56830"
(possibly with some lifetime information as well), and forego that
lookup, or a device with a DNS stack could still use that information to
save the roundtrips.
This sounds like a relatively simple solution to me, so I probably
missed something (possibly also Dave already suggesting that with
different words) -- but what?
Thanks
Christian
--
We are dreamers, shapers, singers, and makers.
-- Elric
We are dreamers, shapers, singers, and makers.
-- Elric