> -----Original Message----- > From: Thiago Macieira [mailto:thiago.macieira at intel.com] > Sent: Thursday, August 4, 2016 9:25 AM > To: Dave Thaler <dthaler at microsoft.com> > Cc: iotivity-dev at lists.iotivity.org; jihwan.seo at samsung.com; JinHyeock > Choi > <jinchoe at gmail.com> > Subject: Re: [dev] OCF Endpoint Implement on iotivity > > And, indeed, 6lo-over-BLE is now available as an RFC: > https://tools.ietf.org/html/rfc7668 - IPv6 over BLUETOOTH(R) Low Energy > > The idea of non-IP BLE support was to fill in the gap until the above was > available. It was intended to connect to edge devices that were already in > the market or in development and were being retrofitted with OCF support. I > guess that was more interesting to us developers, rather than OEMs. > > The question is whether OEMs that opt into BLE will want to bear the > complexity of 6lo/IPv6 on their OS.
Some yes, some no. > If they're not, does it still make sense to > talk about OCF payloads? How about security? Not that I know of. Those who don't want 6lo/IPv6 already do Bluetooth SIG profiles today. There is no need to add the complexity of OCF protocols when there's already an ecosystem of Bluetooth profiles and devices supporting them today. > And if it does, is OCF interested in standardising that kind of protocol? I would say no. BTW, ASA went through this same argument a year ago and came to the same conclusion. The other two approaches were sufficient and there is no need to add yet a third alternative. Dave > > On quinta-feira, 4 de agosto de 2016 14:52:18 PDT Dave Thaler wrote: > > Windows also has address-to-string conversion routines when using > > Bluetooth sockets. > > > That said, BLE is not an "OCF" supported transport, and personally I > > see no need for it to be, given there's two other alternatives that > > already exist > > today: > > a) run OCF protocols over IP over BLE > > b) use a bridge to map to existing Bluetooth profiles > > > > > > > -----Original Message----- > > > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > > > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > > > Sent: Wednesday, August 3, 2016 11:36 PM > > > To: iotivity-dev at lists.iotivity.org; jihwan.seo at samsung.com; > > > JinHyeock Choi > <jinchoe at gmail.com> > > > Subject: Re: [dev] OCF Endpoint Implement on iotivity > > > > > > On quinta-feira, 4 de agosto de 2016 04:04:59 PDT ??? wrote: > > > > > > > I understand that reason. > > > > but when BLE is defined in the near future. > > > > some problem will be caused because there is no public API like > > > > getAddress() in any Bluetooth Platform. > > > > > > > > > On Linux, the hciconfig can display the address. That implies that > > > it can be > obtained from the kernel. strace identifies these operations: > > > > > > socket(AF_BLUETOOTH, SOCK_RAW, 1) = 3 > > > ioctl(3, HCIGETDEVLIST, 0x55e18eaca010) = 0 ioctl(3, HCIGETDEVINFO, > > > 0x55e18cc3bac0) = 0 > > > > > > Can't you use that to get the device's own address? > > > > > > -- > > > Thiago Macieira - thiago.macieira (AT) intel.com > > > > > > Software Architect - Intel Open Source Technology Center > > > > > > > > > _______________________________________________ > > > iotivity-dev mailing list > > > iotivity-dev at lists.iotivity.org > > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center
