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 On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad <i...@augustcellars.com> wrote: > > > > > *From:* Cigdem Sengul <cigdem.sen...@gmail.com> > *Sent:* Monday, August 17, 2020 10:45 AM > *To:* Jim Schaad <i...@augustcellars.com> > *Cc:* draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg <ace@ietf.org> > *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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace