On Thursday 03 December 2015 02:49:35 ASHOKBABU CHANNA wrote:
> >>That's not a valid URI. You cannot use ':' in the hostname without []. And
> >>you can only use [] for IPv6 and IPvFuture.
>
>
> This leads to only solution to use dashes form MAC and update the document
> accordingly. coap://00-11-22-33-44-55/uri
Thanks.
> bt is not required with CoAP address as it is delivered with transport.
What happens if the context is lost? If you create a URI, someone may place it
elsewhere and then you don't know whether "coap://00-11-22-33-44-55" is
supposed to be transmitted via Bluetooth to MAC address 00:11:22:33:44:55 or
with UDP to hostname "00-11-22-33-44-55".
> >> Explain the use-case: how do you know the device address, without a
> >> discovery?
> We can create resource object directly in IoTivity without discovery
> (use-case: if the absolute URI is already known by out of band mechanism)
Then your out-of-band discovery may have discovered multiple device addresses
for this resource. Please make the API in such a way that you can provide
multiple addresses to be attempted.
In other words, not in the URI of the resource.
> > >In any case, please see the discussion going on inside the SWG about the
> > >use of fully qualified URIs. The proposed solution is to encode the
> > >device
> > >ID in the hostname, in which case you can't put the MAC address there.
> > >The
> > >URI would be of the form:
> > >
> > >oic://bf3718fa-3ba4-4898-b9e9-cb88a681cc4a/
>
> With UUID, how we can confirm it is unique if the device supports multiple
> transports?
I'm not sure I understand. The UUID is unique because the device verified that
no one else has that UUID before joining the network. That's like IPv6
Duplicate Address Detection (DAD), but is done only once at onboarding time.
>From the UUID, like with a hostname and DNS, you have to make a lookup to
discover the address of the device. That turns up one or more device addresses
and IoTivity must heuristically choose one (or more, cf. Happy Eyeballs) to
send the packet to. It may also turn up zero addresses, which means the device
is not present in the network right now.
Your out-of-band discovery mechanism that you mentioned above is like I've
just described. Since it may turn up more than one address, the API that takes
network addresses discovered out-of-band must accept a list of addresses, not
just one.
Right now, it would be an array of OCDevAddr. But you could use an URI list
for that. For example (pseudo-code):
address_list =
out_of_band_discover("bf3718fa-3ba4-4898-b9e9-cb88a681cc4a")
log(address_list)
// prints:
// "coap://[fd88:372f:4327:1:adec:54ff:fe47:8f30]:41031"
// "coap+bt://8d-ec-54-47-8f-30"
// "coap+tcp://[fd88:372f:4327:1:adec:54ff:fe47:8f30]:41031"
// "http://[fd88:372f:4327:1:adec:54ff:fe47:8f30]:41032";
// "coap+unix:///var/run/2971_unix_socket"
// "coap://192.168.1.108"
// "xmpp://192.168.1.1/remote/192.0.2.2?cookie=vzcY-jukSJi56cuIpoHMSg"
do_resource("GET",
"oic://bf3718fa-3ba4-4898-b9e9-cb88a681cc4a/a/light",
address_list, callback_function)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
