Does the 16-Bit Espressif BluFi BLE Service UUID 0xFFFF violate the standard?

Question

Espressif markets the ability to send Wi-Fi credentials to a device via BLE as "BluFi". This ability is advertised with the 16-Bit Service UUID 0xFFFF.

My understanding is that all 16-Bit BLE Service UUIDs are reserved for standardized BLE services. Although the BluFi Service UUID doesn't currently cause a conflict, should this still be considered a violation of the BLE standard?

BLE assigned numbers: https://www.bluetooth.com/specifications/an/

BluFi: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/blufi.html

Answer 1

If we look in that Assigned Numbers document you link, we can find this:

3. 16-bit UUIDs

See Bluetooth Core Specification [Vol 3] Part B, Section 2.5.1 [4].

Following that reference, we find:

2.5.1 UUID

A UUID is a universally unique identifier that is expected to be unique across all space and all time (more precisely, the probability of independently-generated UUIDs being the same is negligible). UUIDs can be independently created in a distributed fashion. No central registry of assigned UUIDs is required. A UUID is a 128-bit value.

To reduce the burden of storing and transferring 128-bit UUID values, a range of UUID values has been pre-allocated for assignment to often-used, registered purposes. The first UUID in this pre-allocated range is known as the Bluetooth_Base_UUID and has the value 00000000-0000-1000-8000-00805F9B34FB. UUID values in the pre-allocated range have aliases that are represented as 16-bit or 32-bit values. These aliases are often called 16-bit and 32-bit UUIDs, but each actually represents a 128-bit UUID value.

Note that this section is located in the SDP chapter, which is usually not related to BLE or GATT. However, this section applies to the ATT protocol as well (which is used by GATT), as indicated by the 3.2.1 section in the ATT chapter.

That said, my interpretation is that all 16-bit and 32-bit UUIDs are already allocated to be used for registered purposes. Note that all these UUIDs allocated may not yet have been assigned a purpose and should therefore be reserved for future use.

This is further confirmed in the "Vol 1, Part E: General Terminology and Interpretation" chapter of the Bluetooth Core v5.4 standard:

2.6 ASSIGNED NUMBER REQUIREMENTS

The Bluetooth SIG maintains a published set of assigned numbers on the Bluetooth SIG Assigned Numbers web page. These assigned numbers are grouped in various number spaces. Numbers assigned may overlap with other assigned numbers in different number spaces, but no number within a number space is ever reused. The various number spaces are defined in the specification that defines the usage of the assigned numbers. All assigned numbers within a given number space shall only be designated by the Bluetooth SIG and shall only be used for their intended purposes when used within a field, parameter, or other variable object defined to take on a value within that number space. All values not explicitly assigned within a given number space are Reserved for future use and subject to the requirements in Section 2.4.

All 16-bit and 32-bit UUIDs as defined in [Vol 3] Part B, Section 2.5.1, are considered assigned numbers. All other UUID values may be used in any context where a UUID is permitted provided they are generated according to the recommendations in ITU-T Rec. X.667(10/2012), alternatively known as ISO/IEC 9834.8:2014.

Since a 16-bit service with UUID 0xFFFF is not present in the Assigned Numbers document, it appears they are indeed violating the standard.

Furthermore, according to https://support.bluetooth.com/hc/en-us/articles/360062030092-Requesting-Assigned-Numbers, it is not possible to register a member specific 16-bit Characteristic UUID (only Service UUID). Despite this, BluFi still uses Characteristic UUIDs 0xFF01 and 0xFF02.

My bet is that they used these short UUIDs during internal testing and then forgot to replace them or forgot to purchase their own 16-bit UUIDs at release, and nobody noticed this mistake.