On Tuesday 01 December 2015 04:28:36 ASHOKBABU CHANNA wrote:
> Hi Thaigo,
> Here is the Base API for an IoTivity request.
>
> OCStackResult OCDoResource( ... const char *requestUri,const OCDevAddr
> *destination, ...) Request URI + destination device addr uniquely
> identifies the specific endpoint.
> URI : <scheme> ":// IP:PORT or MAC/relative URI
> OCDevAddr : transport + other information.
>
> We need to analyze the alternatives if it deviates from OIC spec otherwise,
> 4013 gerrit need to be merged in master to accommodate BT, BLE transport
> support in IoTivity.
As I said, you may not insert the raw MAC address just like that in a URI.
If you use dashes, however, it's valid:
coap+bt://00-11-22-33-44-55:777
you can use the port number for some other purpose, like interface ID or
Bluetooth endpoint ID.
I insist that the fact that it uses bluetooth must be encoded in the scheme or
in the hostname (such as 001122334455.bt.oic). Think of other protocols that
may use MAC addresses as endpoints.
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/
The resolution of device ID to device address and protocol is left to IoTivity
and should not show up in the API.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
