MQTT 5 handling invalid shared subscription names

[Andrea]

Hi folks,

I've done little search to check if my question was already answered in the past, but haven't found anything.

I'm implementing the broker side of shared subscriptions. The specification at MQTT-4.8.2-1 and at MQTT-4.8.2-2 defines the what should be the format of the shareName part of a subscription:

- A Shared Subscription's Topic Filter...MUST contain a ShareName that is at least one character long

- The ShareName MUST NOT contain the characters "/", "+" or "#"

If the broker receives a SUBSCRIBE packed with $share/{shareName} where the shareName doesn't respect the above rules, what it should do?

Possible paths are:

- send a SUBACK but using reason code "Unspecified Error" in payload, for the offending shareName

- send a DISCONNECT message to the client, specifying an error message

- drop the connection without DISCONNECT

Thanks for reading

  Andrea Selva

[k...@dreamweasel.ca]

Generally, the specification treats packets which don't follow the encoding rules for various elements, such as those rules for share names, as "malformed packets“. Section 4.13 discusses the handling of malformed packets. A server should send a DISCONNECT packet with reason code 0x81 (malformed packet), and must drop the network connection.

A SUBACK with an error code is more appropriate when there was nothing violating the specification in the client's SUBSCRIBE, but the server couldn't process that SUBSCRIBE for some reason (e.g. some server resource limit).

-- 

Ken.