[FEATURE REQUEST] Opt-In fallback if broker rejects MQTT ClientID

[erhardeibl]

Product

.NET SDK, Go SDK, Rust SDK

Azure Iot Operations version

No response

What happened?

The MQTT Spec about Client Identifiers specifies:

The Server MUST allow ClientID’s which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters
"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" [MQTT-3.1.3-5].

The Server MAY allow ClientID’s that contain more than 23 encoded bytes. The Server MAY allow ClientID’s that contain characters not included in the list given above.

This may lead to implementation specific issues. For example, if a customer uses a spec-compliant MQTT 5.0 broker that only accepts short ClientIDs, the session client may receive the following error:

Value	Hex	Reason Code name	Description
133	0x85	Client Identifier not valid	The Client Identifier is a valid string but is not allowed by the Server.

In such cases, it may be useful to fall back to a safe, spec-compliant session ID. For example, hashing the original ID to 14 bytes (e.g. with SHAKE128) and encoding them to Base62 should guarantee valid 23 char IDs.¹

I believe the MqttSessionClient should not manipulate the provided ClientID without explicit permission. Therefore, I request an opt-in flag to fall back to a guaranteed spec-compliant ClientID if the supplied one is rejected.

List the steps to reproduce

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Footnotes

1. One Base62 character holds ~5.95 bits of information. Rounded down to 5 bits per character, 23 Base62 characters hold 115 bits (≈14.375 bytes). Hashing to ⌊14.375⌋ = 14 bytes (112 bits) provides a conservative lower bound. More efficient encoding is possible, but the collision probability is already negligible for practically any application. ↩

[cartertinney]

We do not desire to implement this. Our intended design is to report failures from the broker, not try and pre-empt failures. There are many broker-specific variant behaviors allowable under the MQTT spec, and the SDK is not intended to provide built-in solutions for all of them, it is merely intended to be compatible with them, and report failures as appropriate.

You should know which broker you are connecting to and what the rules are for that broker, choosing a client ID accordingly.