- From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Jul 2016 23:11:18 +0000
- To: public-web-bluetooth-log@w3.org
> 2) @jyasskin I agree that the API should not form such a tight association to "advertisement" packets. I believe that the LE Bluetooth spec does not restrict contents of scan response and advertisement indication. Though likely rare, for example, a device may have manufacturer data in scan response and service data in advertisement indication. I think that the events should be called "scan responses" (as in: response to user's request to scan for devices) or "scan events" in order to avoid this coupling. I believe the spec consistently refers to [advertising events](https://rawgit.com/jyasskin/web-bluetooth-1/scanning/scanning.html#advertising-events) instead of either advertising packets or scan responses, which comes from BT4.2 1.A.1.2 saying that an advertising event comprises an advertising packet and resulting scan requests and responses, on each of the three advertising channels. So I think this is ok as-is, and that using "scan events" would diverge too much from the Bluetooth spec. -- GitHub Notification of comment by jyasskin Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/pull/239#issuecomment-235749434 using your GitHub account
Received on Wednesday, 27 July 2016 23:11:25 UTC