Hello Hannes, Thank you very much for your comments. My responses are inside.
> > From the text you cited regarding MQTT v5 it is not backwards compatible > to version 3.1.1. The exact impact of working between two devices of > different versions has not been described in the spec either. The follow > sentence in your introduction can easily give readers the impression that > the two versions are backwards compatible. Here is the sentence: > > " It is expected that MQTT > deployments will retain backward compatibility for MQTT v3.1.1 > clients, and therefore, this document also describes a reduced set of > protocol interactions for MQTT v3.1.1 - the OASIS Standard > [MQTT-OASIS-Standard]. > " > Maybe you want to change the wording a little bit. I think the reason why > you want to describe a solution for v3.1.1 is that this is the widely > deployed version. > > I see where I am creating confusion. I should distinguish better that I expect solution providers to still support MQTT v3.1 clients by implementing both MQTT v5 and MQTT v3.1.1 servers, as you said because 3.1.1 is widely deployed. I was not meaning spec backward compatibility. > Regarding the broker term: It is probably a matter of taste but I would > refer to the terms used in the spec and would not replicate the terminology > from the OASIS MQTT specs in the draft. Someone who implements the draft will have to become familiar with MQTT > anyway. But that’s just me. For example, I often see people using the term > “certificate authorities (CA)” in their write-ups. RFC 5280 defines and > uses the term “certification authority (CA)". While the two sound and look > similar only one is actually correct. > OK, you suggest we use MQTT server. I expect broker is more widely-used in practice, and it is not a misspelling of another term either. I would want to keep it, but I would like to see if others prefer MQTT server rather. > > I noticed you have put a normative dependency on > [I-D.palombini-ace-coap-pubsub-profile]. I don't think it is necessary > because it is not a requirement to implement the spec. You could use it on top of it -- or you could use something else as well. I > would move it to the informative part. The added benefit of doing that is > that you do not block your spec till that draft becomes RFC. True. Will fix. > On the other hand, RFC 6749, RFC 7800, and > I-D.ietf-ace-cwt-proof-of-possession cannot be informative references when > you use PoP tokens in your solution. > > Yes, indeed. Will fix. > You might be interesting to hear that there is currently no way to obtain > the keys for a PoP token over HTTP, which your solution requires. The > virtual interim meeting in the OAuth group should probably be of interest > to you. > I plan to join. I have been aware of the issue, but could not follow how it was planned to be resolved. I was looking at this: draft-ietf-oauth-pop-key-distribution Thanks again, --Cigdem > > From: Cigdem Sengul <[email protected]> > Sent: Tuesday, February 25, 2020 3:10 PM > To: Hannes Tschofenig <[email protected]> > Cc: [email protected] > Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03 > > Hello Hannes, > > We used broker as it is a widely accepted term in the MQTT Community for > "server" e.g., > majority of the provider would list also a broker implementation to refer > to their server implementation. > > With respect to whether 3.1,1 clients talking to v5, there may be some > issues. This is what the spec says: > > Non-normative Comment > If the Server distributes Application Messages to Clients at different > protocol levels (such as MQTT V3.1.1) which do not support properties or > other features provided by this specification, some information in the > Application Message can be lost, and applications which depend on this > information might not work correctly. > > The spec also defines a protocol version error message: > If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and > the Server does not want to accept the CONNECT packet, the Server MAY send > a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and > then MUST close the Network Connection > > So, whether a broker provides dual support would depend on the provider. > E.g., the Mosquitto broker supports the different protocol versions. > > Thanks, > --Cigdem > > On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig <mailto: > [email protected]> wrote: > Hi Cigdem, Hi Anthony, Hi Paul, > > Why are you using the term MQTT broker? My understanding of the MQTT spec > is that there are only clients and servers - nothing more. > > Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT > v3.1.1 client talk to a MQTT v5 client via a server that supports both > v3.1.1 and v5? > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > Ace mailing list > mailto:[email protected] > https://www.ietf.org/mailman/listinfo/ace > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
