RE: EXT :[openc2-comment] Comments on transf-mqtt-v1.0-csd04.md

Mr. Banks,

 

Thank you for taking the time to read and comment on our specification. I have some thoughts regarding your comments.

 

I believe the items you mention for 2.2, 2.6, and 3.3 are clear from the content of the MQTT v5 specification, and Iâd been taking the approach of not explaining
 such items. Does your experience indicate that these are particularly useful to clarify?

 

WRT to section 2.8 and Will Messages, section 3.1 includes several related requirements, specifying

Will Flag = FALSE

Will QoS = 0 (zero)

Will Retain = FALSE

and stating âOpenC2 Producers and Consumers MUST NOT populate any of the
 CONNECT payload fields related to the MQTT Will Message.â
 As section 2 is non-normative, I donât believe adding âmust notâ language there would represent a meaningful change.

 

Dave

 

David Lemire

IA Systems Engineer

Technical Solutions

302 Sentinel Drive | Annapolis Junction, MD 20701

Work (301) 575-5190 |
Mobile (240) 938-9350

 

From:  [mailto:]
On Behalf Of Andrew Banks

Sent: Tuesday, September 7, 2021 9:09 AM

To: 

Subject: EXT :[openc2-comment] Comments on transf-mqtt-v1.0-csd04.md

 

CAUTION: This email originated from
outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.

 

2.2 Default Topic Structure

Might be worth clarifying the difference between a subscription to "oc2/rsp" and "oc2/rsp/#".

2.6 MQTT Client Identifier

Some brokers allow a connection with a zero byte ClientId. This will cause the MQTT broker to generate a ClientID that is guaranteed to be unique.

2.8 Will Message

Might be better so say "must not use a will message", that way you can opt to use a will message in the future.

3.3 SUBSCRIBE Control Packet

If Qos=1 is used, the receiver will have to be capable of dealing with a repeated (duplicate) message.