MQTT 5.0 WD13 - CONNECT Response

[Boris Verkhovykh <b_a_v@mail.ru>]

Hello!

I have two remarks regarding section "3.1.4 CONNECT Response"

1. Paragraph with [MQTT-3.1.4-1] says

1325   2. The Server MUST validate that the CONNECT packet conforms to section 3.1 and close the
1326   Network Connection if it does not conform [MQTT-3.1.4-1]. The Server MAY send a
1327   DISCONNECT with a Return Code of 128 or greater as described in section 4.13 before closing
1328   the Network Connection.

But, is it allowed to send DISCONNECT packet before accepting the connection?
I guess it should say "The Server MAY send a CONNACK..." packet as in the paragraph "3." later.
Actually paragraphs "2." and "3." should have similar wording to avoid confusion.



2. Paragraph with [MQTT-3.1.4-3] says

1337   1. If the ClientID represents a Client already connected to the Server, the Server sends a
1338   DISCONNECT packet to the existing Client with Return Code of 0x8E (Session taken over) as
1339   described in section 4.13 and MUST close the Network Connection of the existing Client [MQTT-
1340   3.1.4-3]. If the existing Client has a Will Message, that Will Message is published as described in
1341   section 3.1.2.5.

What is the purpose of sending Will Message in case of the session takeover? What is the expected scenario?
I would say a new connection with the existing ClientID is a very special case and should be treated accordingly!
First of all, such simple logic may allow a DoS attack (even if not intended), when multiple "identical" clients try to work with the same Server.
Second, if a Client developer has plans for the legitimate "session takeover" - switching from one client instance to another - it is better to allow some level of control over it.
For example, special CONNECT option, which tells the Server to deny "duplicate ClientID" connection or even instructs it to somehow query the existing client if it allows a take over.
I understand that it may be technically difficult to implement, so

switching from my phantasies back to Will Message.
My understanding of the Will Message is to indicate (to the interested parties) that a service from the specific Client is no longer available.
I think, that the Will Message MUST not be published in situations when the Client reconnects after detecting network errors, but the Server does not (yet) recognize the loss of connection. Even if it is a completely different new Client instance, the same ClientID, especially when the session is preserved, indicates that the service is still available.

What do you think?


Best regards,

Boris Verkhovykh
Software Architect
 RTSoft