Ambiguity in MQTTnet’s Support for MQTT 5 “Request Response Information” and “Request Problem Information

[hadilbenmoussa]

Which project is your question related to?

• Server

Describe your question

While upgrading my MQTT broker implementation to MQTT 5, I found ambiguity in the MQTTnet Server regarding how it handles two CONNECT properties:

• Request Response Information (0x19)
• Request Problem Information (0x17)

The MQTT 5 specification defines clear rules for these fields, but it is not clear whether MQTTnet automatically enforces these requirements or whether broker developers must implement additional logic manually.

WHY?

1. Request Response Information

According to the spec:

If the client sets this to 0 → Server MUST NOT include Response Information in CONNACK.

If the client sets it to 1 → Server MAY include Response Information, but it is optional.

My question:

I could not determine whether MQTTnet has built-in logic for populating or omitting this field, or whether it is entirely the broker developer's responsibility.

2. Request Problem Information

Spec states:

Default value = 1 (if absent).

If the client sets it to 0:

Server may include Reason String or User Properties only in PUBLISH, CONNACK, or DISCONNECT.

Server must not include them in any other packet types.

My question:

Does MQTTnet enforce these restrictions automatically?

Or should the broker developer ensure that Reason Strings / User Properties are not included in packets where the spec forbids them?

[chkr1011]

1. Right now there is no way to set the "ResponseInformation" in an CONNACK packet. This can be added including the mentioned rules.

2. There is no verification yet which will check when you manipulate packages in the events of the MQTTnet server.