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

**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?

No file, test, or entry point is named. Compare MQTT 5 rules for Request Response Information and Request Problem Information with MQTTnet Server behavior, then document whether MQTTnet enforces them or leaves the responsibility to broker developers; done means both responsibilities are answered clearly.

Written by the indexing model from the issue text.