- From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Apr 2018 17:03:56 +0000
- To: public-web-bluetooth-log@w3.org
@beaufortfrancois, have you seen other reports of devices that send notifications and indications but don't expose a CCCD to let their clients configure that? I'm reluctant to diverge from the specification, but if this mistake is common, we might have to. If we do this, the specification should be phrased like > If the characteristic has a Client Characteristic Configuration descriptor, use any of the Characteristic Descriptors procedures to ensure that one of the Notification or Indication bits in characteristic’s Client Characteristic Configuration descriptor is set, matching the constraints in characteristic’s properties. The UA SHOULD avoid setting both bits, and MUST deduplicate value-change events if both bits are set. Handle errors as described in §5.7 Error handling. > > Note: Some devices have characteristics whose properties include the Notify or Indicate bit but that don't have a Client Characteristic Configuration descriptor. These non-standard-compliant characteristics tend to send notifications or indications unconditionally, so this specification allows applications to simply subscribe to their messages. That is, the behavior for non-compliant devices should be included in the main flow of the algorithm instead of [COMEFROM](https://en.wikipedia.org/wiki/COMEFROM)ed later. -- GitHub Notification of comment by jyasskin Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/pull/391#issuecomment-381199788 using your GitHub account
Received on Friday, 13 April 2018 17:04:02 UTC