- From: Giovanni Ortuño via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Dec 2018 22:42:58 +0000
- To: public-web-bluetooth-log@w3.org
At least in the advertisement bytes there is a difference between an empty UUIDs list and a non existent UUIDs list. In the current spec both of these would result in the same event. Granted I don't think the distinction is that useful, I think we should try to keep the API as low-level as reasonable. Empty UUID list: | Value | Notes | | ------------- |-------------| | 0x02 | Length of this data | | 0x01 | "Flags" Data Type Value | | 0x01 | Flags Value (LE Limited Discoverable Flag set) | | 0x02 | Length of this data| | 0x02 | "Incomplete UUID List" Data Type Value | | 0x05 | Length of this data | | 0x09 | "Name" Data Type Value| | 0x65 | 'f' | | 0x6F | 'o' | | 0x6F | 'o' | No UUID list: | Value | Notes | | ------------- |-------------| | 0x02 | Length of this data | | 0x01 | "Flags" Data Type Value | | 0x01 | Flags Value (LE Limited Discoverable Flag set) | | 0x05 | Length of this data | | 0x09 | "Name" Data Type Value| | 0x65 | 'f' | | 0x6F | 'o' | | 0x6F | 'o' | (That said, the BT spec says to interpret a missing UUID List as an empty incomplete list[1], so the UUIDs list member should be non-optional. The argument still applies to Service Data and Manufacturer Specific Data though.) [1] Supplement to Bluetooth Core Specification | CSSv7, Part A 1.1 Service UUID -- GitHub Notification of comment by g-ortuno Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/pull/421#issuecomment-447147942 using your GitHub account
Received on Thursday, 13 December 2018 22:43:00 UTC