Hi, When implementing the IoTivity (I couldn't find a complete specification for this in OIC, so the work used IoTivity as reference) GATT transport in Soletta[1], we found a couple of problems:
* IoTivity uses a few BlueZ D-Bus APIs that have changed upstream, for example, org.bluez.GattManager1.RegisterService() has changed to org.bluez.GattManager1.RegisterApplication() (this API is marked as experimental, so the usual stability guarantees doesn't apply); * Over Bluetooth Low Energy transport, IoTivity uses the same header format as CoAP over TCP, but based on a draft that has already expired, see here: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ (also, the necessity of this header in Bluetooth Low Energy could be discussed, as GATT maps to a reliable datagram based transport) * Performing the fragmentation on IoTivity's side seems unnecessary, if the value to be written is larger than the negotiated MTU, BlueZ will perform the Write Long Characteristic procedure if necessary, then it's just a matter of requiring devices to implement the necessary ATT operations; Cheers, -- Vinicius [1] An initial version of this is being reviewed here: https://github.com/solettaproject/soletta/pull/1436
