From 2839c131c0405eb21cc3ff57900f5862acb9e866 Mon Sep 17 00:00:00 2001 From: bluetooth-mdw Date: Thu, 10 Sep 2015 08:01:12 +0100 Subject: [PATCH] Moved D4 to the Profile Testing section and renumbered --- ble_issue_tracker.txt | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/ble_issue_tracker.txt b/ble_issue_tracker.txt index 2e05a88..f0bd091 100644 --- a/ble_issue_tracker.txt +++ b/ble_issue_tracker.txt @@ -11,17 +11,15 @@ D2. Lose the Scrolling State characteristic D3. Simplify the IO Pin Service, possible to expose the edge connector pins only. Possibly drop it to save memory and use the event service to transport pin values in either direction. Needs further thought. -D4. Generic Access Service: Device Name and Appearance are mandatory and so need values +D4. Generic Access Service: Peripheral Privacy Flag is optional and I don’t think we need it. Ditto Reconnection Address, ditto Peripheral Preferred Connection Parameters. -D5. Generic Access Service: Peripheral Privacy Flag is optional and I don’t think we need it. Ditto Reconnection Address, ditto Peripheral Preferred Connection Parameters. +D5. Generic Attribute Service: profile design doc/report doesn’t show it and it’s mandatory (issue with Bluetooth Developer Studio). -D6. Generic Attribute Service: profile design doc/report doesn’t show it and it’s mandatory (issue with Bluetooth Developer Studio). +D6. Device Information Service: All characteristics are optional. Which ones do we really want/need? Save a little memory..... -D7. Device Information Service: All characteristics are optional. Which ones do we really want/need? Save a little memory..... +D7. Why does LED Matrix State support “Write Without Response”? I think this should be plain “Write” so that no further writes are made until there’s been an ACK back from the previous one. -D8. Why does LED Matrix State support “Write Without Response”? I think this should be plain “Write” so that no further writes are made until there’s been an ACK back from the previous one. - -D9. MicroBit Requirements supports Write. This is (ironically and puntastically) wrong. Client should not be able to modify the requirements the MicroBit has. +D8. MicroBit Requirements supports Write. This is (ironically and puntastically) wrong. Client should not be able to modify the requirements the MicroBit has. CLOSED: @@ -41,4 +39,6 @@ T5. Client Requirements characteristic is missing from the Event Service T6. Device Name in advertising packets includes the flash code so anyone could pair to it. Should be removed. +T7. Generic Access Service: Device Name and Appearance are mandatory and so need values + CLOSED: