Hello Jim, Responses inside.
> > > > On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad <[email protected]> > wrote: > > Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous > session number/ - I think it should be stated that the session number is > provided, which is what the state is associated with. > > > > To the best of my knowledge, and from what I read from the MQTT v5 spec: > > The ClientID MUST be used by Clients and by Servers to identify state that > they hold relating to this MQTT Session between the Client and the Server.. > > I do not think the server uses anything other than the Client ID to look > up the state. > > [JLS] I got the name wrong, the need for the identifier remains. > [CS] I see - I realise I did a shortcut to say MQTT broker keep session state. Actually, I think I should give examples of session state as I need to explain what could be problematic by identifying state only with client-id as discussed in the last IETF meeting. (i.e., The Session State in the Client consists of: · QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged. · QoS 2 messages which have been received from the Server, but have not been completely acknowledged. The Session State in the Server consists of: · The existence of a Session, even if the rest of the Session State is empty. · The Clients subscriptions, including any Subscription Identifiers. · QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged. · QoS 1 and QoS 2 messages pending transmission to the Client and OPTIONALLY QoS 0 messages pending transmission to the Client. · QoS 2 messages which have been received from the Client, but have not been completely acknowledged.The Will Message and the Will Delay Interval · If the Session is currently not connected, the time at which the Session will end and Session State will be discarded. ) > > Section 2.2.4 - Last sentence. There is a difference between the connect > and re-auth flows in that the first and last messages are going to be AUTH > '25', AUTH '0' not CONNECT/CONNACK. Everything else does stay the same. - > Might just want to say a similar flow and point forward. > > Will clarify that this is only for CONNECT as it is under section 2- > Authorizing > Connection Requests. > > Will direct to section 4 for re-authentication. > > > > Section 2.2.6.1 - I am not sure where you got this from: "Note that this is > different in MQTT v5.0, the Broker is allowed to process AUTH packets even > if the Broker rejects the CONNECT)." I think that if the broker rejects > the > connect it must CONNACK and disconnect. > > > > 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. > > > So, the spec allows clients to send AUTH after CONNECT before CONNACK, and > servers to process AUTH after CONNECT (before CONNACK I suppose). > > > > I agree the wording may be confusing: > > What I want to say is that: the servers in our profile do not process > anything after CONNECT before CONNACK. > > So, the AUTH flow is strictly initiated by the server during the > connection handshake. > > After that, the client may do AUTH first, for re-authentication. > > [JLS] Given that a client may only send an AUTH in response to an AUTH, I > don’t know how much this is needed. > > > > [JLS] I think if you just delete the aside (in parens) then it says what > needs to be said and is not confusing. > > > [CS] OK, agreed, less is more in this case. Will delete the parentheses text. > > > > Section 3.1 - Missed a case of "publish_+/topic3" > > Yes, in previous version, example was for publish only for topic3. > > I thought I should give a pub/sub, pub only, and sub only examples. > > Is that OK? > > > > Yes, I was just pointing out that this was using the old syntax. Nothing > more. > [CS] Found it. OK, that was very buggy. Will change to: Following the example in the previous section, a client sending a SUBSCRIBE message to 'a/topic3' would be allowed to subscribe, as the scope includes "["+/topic3",["sub"]]". Thanks again for catching it. --Cigdem > > > Jim > > > > > > Thanks, > > --Cigdem > > > > > > > Jim > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
