Hello Jim, Responses inside. On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad <i...@augustcellars.com> 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. > 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]. 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. > 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? Thanks, --Cigdem > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
