From: Cigdem Sengul <[email protected]> Sent: Monday, August 17, 2020 2:25 PM To: Jim Schaad <[email protected]> Cc: [email protected]; Ace Wg <[email protected]> Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 Hello Jim, I understand that it's an optimization to improve message delay. I wonder also if a client then can do CONNECT - PUBLISH - DISCONNECT before receiving a CONNACK as a best-effort publish? assuming CONNECT succeeds... Should we just not cater to those cases? What about stating in 2.2.6.1 - after "the Broker MUST send a CONNACK message to the Client." (or maybe somewhere higher up): -> The client MUST NOT send any packets other than DISCONNECT or an AUTH in response to the broker AUTH's message until it has received a CONNACK. -> The server MUST NOT process any packets other than DISCONNECT or an AUTH in response to its AUTH message before it has sent a CONNACK. --Cigdem [JLS] I think that not catering to these cases is just fine. People who really expect them to work probably shouldn’t. Jim On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad <[email protected] <mailto:[email protected]> > wrote: From: Cigdem Sengul <[email protected] <mailto:[email protected]> > Sent: Monday, August 17, 2020 10:45 AM To: Jim Schaad <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> ; Ace Wg <[email protected] <mailto:[email protected]> > Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 I've got that from MQTT v5 spec: If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it has received a CONNACK packet [MQTT-3.1.2-30]. and: If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. [JLS] I read this as the following would not do the publish CONNECT --> PUBLISH --> <-- AUTH AUTH --> <-- CONNACK fail The PUBLISH can be received but is not processed unless the CONNACK is going to be a success. [/JLS] [CS] I think this sequence should not happen, as Client MUST NOT send PUBLISH before CONNACK. I did not know what brokers do if they receive PUBLISH (and still processing a CONNECT) - drop or buffer until process. I quickly browsed mosquitto src. It looks like the broker sets a context flag to mark the session active after CONNECT is processed and accepted. If this flag is not set when processing publish, it goes to an error state and doesn't look like it keeps the packet. [JLS] No, Clients are allowed to send further MQTT Control Packets immediately after sending a CONNECT packet; Clients need not wait for a CONNACK packet to arrive from the Server. – this is the preceding two sentences to requirement MQTT-3.1.4-6. I would agree that this is going to be server specific. The following paragraph suggests that clients SHOULD wait for the CONNACK but it is non-normative. I think that I would write my client code to wait. I would have to work really hard to figure out what my code base would do for this as I know it does queue packets for later processing but I am not sure what it would do for this case. [CS] Ok, this is confusing. I assumed that sentence regarding clients about not having to wait was when no Authentication Method set. Because there is: If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it has received a CONNACK packet [MQTT-3.1.2-30]. In the profile, we do set an authentication method in connect to "ace". [JLS] Looks like there might be some conflicting statements here. I don’t know the best way to resolve it. Jim --Cigdem
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
