Hello Kevin, Thank you for going through this.
I agree with what Chris mentioned. When I wrote the newtmgr protocol(NMP) in swift for Nordic’s Toolbox app, I had enabled this bit for the newtmgr characteristic. The port is still WIP and hence the incompleteness. I have spoken to Chris about this and will set the notify bit on the newtmgr characteristic. As for the UUIDs, I agree that making the first 16 bits sequential does sound intuitive but then the IDs would not be truely unique and there would be a higher probability of a collision. I have generated the currently assigned IDs using Guid generator <http://www.guidgenerator.com/> which generates the IDs based on an algorithm that is mentioned in RFC4122 <http://www.ietf.org/rfc/rfc4122.txt> and it uses the timestamp and the MAC address of the computer they were generated on. Regards, Vipul Rahane > On Oct 5, 2016, at 7:36 PM, Kevin Townsend <ke...@adafruit.com> wrote: > > >> I think you're right about that - a CCCD should not be set to one unless >> the peer writes to it. What I'm not so sure about is whether it is >> prohibited to send a notification to an unsubscribed peer. I didn't see >> any language in the spec indicating that this is illegal. The ability >> to send unsolicited notifications is useful, and I don't see a reason >> why it shouldn't be allowed. > I agree it's somewhat ambiguous or open to interpretation at present, > but in the case of something as critical as newtmgr over ble (OTA DFU > etc.), it probably makes sense to take the safe approach and add the > CCCD to a characteristic and have the peer explicitly set the notify > bit before the response data is sent??? > > Having the possibility to send unsolicited notifies has some merit, and > personally I don't have any objections to it being included as an option > in nimble, but I wouldn't rely on those assumptions for newtmgr over > BLE. > > Just my opinion though and curious to hear what other people think.
