Hi,

I think it would be nice to do one more API refactoring before 1.0 release
and simplify using BLE device address in API.

The current state here is similar to what we had with UUIDs in ATT code,
i.e. addresses are passed as pair of address type and address value and
there is no common way to e.g. compare or copy them. What more, with
Privacy enabled things are even more complicated since application needs to
chose which address to use when advertising or scanning and can use
different addresses for the same peer device.

So I propose few changes:

1. Application does not specify own_addr_type in APIs
This should be selected automatically by host. By this I mean that
application tells host somehow at startup which address to use (public or
random static) and host will set parameters accordingly depending on
whether Privacy is enabled (IRK is provided) or disabled (no IRK provided).

2. Application should always use peer identity address, if possible
Since host manages resolving list in controller already, address resolving
will be done automatically anyway. We can then assume that for any known
device, the address we use in API is identity address (assuming our IRK is
provided and thus Privacy is enabled) and honestly it does not need to know
so-called OTA address, because this is what host and controller take care
of. The only exception here would be for new devices for which application
will have random (RPA) address at first, but as soon as we are paired host
should notify application about identity address of such device - for this
new event shall be added.

3. And finally, of course, we need nice type and helpers to store and
handle device address in uniform way:
typedef struct {
    uint8_t type; // 0 = public, 1 = random
    uint8_t address[6];
} ble_address_t;

This is what I have in mind now. It may some time to fix all the internals,
but before release we would just need external APIs redefined. Then we can
work more on optimizing the internals.

Open points:
- selecting own address type could be automatic, i.e. host reads public
address from controller, if not available tries to read static random from
storage, if not available generates new one and stores it
- the same for IRK, i.e. read from storage, if not available randomize new
one
This can be however added later and old APIs can be just marked as
deprecated.

Comments?

BR,
Andrzej

Reply via email to