Hi, I was looking through the quite lengthy discussion at https://github.com/WebBluetoothCG/web-bluetooth/issues/238 on the issue that in Web-Bluetooth, only a single "write value" API is available, causing Web-Bluetooth to decide on its own if Write With Response or Write Without Response should be used, in case both are supported by the characteristic. But in the Bluetooth spec about Write Without Response: "This sub-procedure is used to write a Characteristic Value to a server when the client knows the Characteristic Value Handle and the client does not need an acknowledgement that the write was successfully performed." Basically, it says it's up to the client/application to decide if an acknowledgement is needed or not, and hence it's the app that should decide if Write With or Without Response should be used. The "client" can't mean a bluetooth stack here since it can of course not know if an acknowledgement is needed or not. I noticed that according to gatt-api.txt, BlueZ has the same limitation in the WriteValue method, in that the stack chooses the write type "arbitrarily" if both write types are supported (or really the Write With Response is chosen, which might cause unwanted latency). Therefore I suggest that an option should be added to the WriteValue method, for example "write-without-response" (bool) to force Write Without Response. Note how iOS has a write type parameter to the write method, and Android has a write type property you set before you execute the write. I see that it might be possible to achieve the same result with AcquireWrite -> write to socket -> release but that wouldn't be a good solution for bluetooth stacks built on top of BlueZ that would like to differentiate between the two write types (such as Web-Bluetooth) since AcquireWrite can fail, for example if two apps write the value at the same time (I guess the lock is exclusive?). It also seems like unnecessary overhead to open and close sockets. /Emil
