[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-602) Miroslav's points
[ https://issues.oasis-open.org/browse/MQTT-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=83557#comment-83557 ]
Ian Craggs edited comment on MQTT-602 at 10/5/23 5:26 PM:
----------------------------------------------------------
============================================================================
Section 1 - Discussion points for Miroslav PrÃmek for sub-committee meeting
============================================================================
1.1 - Agreed, the final list of reason codes is still being defined so added 0x97 Quota exceeded which will be used in various places, including a normative statement for REGACK alias exceeded;
Point of note, no specific code or normative statement for this exists in v5.0.
1.2 - The 1.2 version of the specification indicates that the transparent gateway implementation shall provide an ~almost transparent message exchange. In some circumstances this exchange is not
possible due to the fundamental packet differences. The will message can be set transparently as part of the CONNECT lifecycle, but hot updates should not be supported as the risk to connection stability on gateway connection recycling is too high.
The specification shall call this out explicitly where possible. Since the functional behaviour
of a transparent implementation is deferred to the broker, the brokers' constraints are expressed at the protocol layer in the gateway. We should add a distinct error code for such circumstances.
1.3 - Point for discussion, I believe we should align SN with MQTT 5.0 and add a non normative statement to suggest its unwise, but not expressly forbidden to have wildcards in short names.
1.4 - UTF-8 Strings versus packet defined length strings. I believe this is a valid statement; there are instances where a classic UTF-8 string field (which encodes the length) is helpful where the field is of variable length within the packet. However in certain circumstances these extra 2 bytes are not required where the size can be derived from the packet,
I propose therefore we have a new string field type which applied the UTF-8 encoded constraints but omits the field length, thus saving space.
1.5 - The AUTH packet shall be updated to remove invalid description. I agree that AUTH continuation is a nice concept - POINT FOR DISCUSSION
1.6 - I have spoken at length on this subject since this point was raised. We should assume that if entirely new predefined alias's were needed, this would be an update to both gateway and firmware.
The new predefined alias's would no doubt need functional support in the application code. However, the problem arises when (and the problem we are trying to solve) is perhaps NOT the update of the predefined alias map on the client,
as much as catering for a use case where a client attempts to REGISTER a PREDEFINED alias which seems to occur a lot. We must therefore mandate that if a client attempts to register a PREDEFINED topic it is either expressly forbidden
OR a be aware that a topic may exist in BOTH the predefined and NORMAL spaces.. do we think we are happy with this?
1.7 - I agree there is large complexity when dealing with the sleep states, in both aggregate and transparent deployments; but their presence is a huge benefit. I believe that there is sound reason to justify the mandating of full QoS lifecycle in the AWAKE state, not
least because the specification will mandate one message in flight per direction at any point in time; some devices may choose never to return to their ACTIVE state and thus render the QoS irrelevant if processing messages without their ack counterparts. Some constraints must be put in place here and I believe processing messages across states outside DUP messaging
would be prone to even greater complexity.
1.8 - This point is valid however it is entirely a function of the client implementation and the type of memory associated with the NORMAL session alias's as to whether these may be dropped during the SLEEP. Some implementations will choose to deep sleep and lose any ephemeral alias storage during this cycle, others may not.
Since it is true that the REGISTER roundtrip will be an expensive operation, I suggest a new field on the DISCONNECT packet with a retainNormalAlias function. Specifying this field allows the client to tell the gateway whether to retain the registration across the sleep cycle and I believe this has been advocated for before.
1.9.1 - Correct change to be applied to section 1.3 - target v20
1.9.2 - Correct, this was applied in a field import from v5.0 in case we used these fields for the Property type we were going to use which had subsequently been dropped - target v20
1.9.3 - Correct, field name will be applied throughout the document - target v20
1.9.4 - DISCONNECT reason string shall be encoded using the new UTF-8 constrained field type (per 1.4 if agreed) and included in - target v20
1.9.5 - WSN is still relavent to the specification and should be included in the 1.3 Terminology section in - target v20
1.9.6 - For dual use bytes, ensure there is no bit based breakdown lines, and simply use text to say OR across the full byte matrix to make it a clearer read - target v20
1.9.7 - Copy and paste textual description of reason codes need to be made applicable within each packet type OR generic @see table 38 - target v20
1.9.8 - Copy and paste table name to be fixed in table 38 - target v20
1.9.9 - Correct this is mandatory and will be added as a normative statement - target v20
1.9.10 - CleanSession usage should be replaced appropriately with CleanStart as required - target v20
1.9.11 - Update to reflect new naming - target v20
1.9.12 - Correct update to document section number required - target v20
was (Author: icraggs1):
Simon Johnson
17:08 (1 hour ago)
to me
============================================================================
Section 1 - Discussion points for Miroslav PrÃmek for sub-committee meeting
============================================================================
1.1 - Agreed, the final list of reason codes is still being defined so added 0x97 Quota exceeded which will be used in various places, including a normative statement for REGACK alias exceeded;
Point of note, no specific code or normative statement for this exists in v5.0.
1.2 - The 1.2 version of the specification indicates that the transparent gateway implementation shall provide an ~almost transparent message exchange. In some circumstances this exchange is not
possible due to the fundamental packet differences. The will message can be set transparently as part of the CONNECT lifecycle, but hot updates should not be supported as the risk to connection stability on gateway connection recycling is too high.
The specification shall call this out explicitly where possible. Since the functional behaviour
of a transparent implementation is deferred to the broker, the brokers' constraints are expressed at the protocol layer in the gateway. We should add a distinct error code for such circumstances.
1.3 - Point for discussion, I believe we should align SN with MQTT 5.0 and add a non normative statement to suggest its unwise, but not expressly forbidden to have wildcards in short names.
1.4 - UTF-8 Strings versus packet defined length strings. I believe this is a valid statement; there are instances where a classic UTF-8 string field (which encodes the length) is helpful where the field is of variable length within the packet. However in certain circumstances these extra 2 bytes are not required where the size can be derived from the packet,
I propose therefore we have a new string field type which applied the UTF-8 encoded constraints but omits the field length, thus saving space.
1.5 - The AUTH packet shall be updated to remove invalid description. I agree that AUTH continuation is a nice concept - POINT FOR DISCUSSION
1.6 - I have spoken at length on this subject since this point was raised. We should assume that if entirely new predefined alias's were needed, this would be an update to both gateway and firmware.
The new predefined alias's would no doubt need functional support in the application code. However, the problem arises when (and the problem we are trying to solve) is perhaps NOT the update of the predefined alias map on the client,
as much as catering for a use case where a client attempts to REGISTER a PREDEFINED alias which seems to occur a lot. We must therefore mandate that if a client attempts to register a PREDEFINED topic it is either expressly forbidden
OR a be aware that a topic may exist in BOTH the predefined and NORMAL spaces.. do we think we are happy with this?
1.7 - I agree there is large complexity when dealing with the sleep states, in both aggregate and transparent deployments; but their presence is a huge benefit. I believe that there is sound reason to justify the mandating of full QoS lifecycle in the AWAKE state, not
least because the specification will mandate one message in flight per direction at any point in time; some devices may choose never to return to their ACTIVE state and thus render the QoS irrelevant if processing messages without their ack counterparts. Some constraints must be put in place here and I believe processing messages across states outside DUP messaging
would be prone to even greater complexity.
1.8 - This point is valid however it is entirely a function of the client implementation and the type of memory associated with the NORMAL session alias's as to whether these may be dropped during the SLEEP. Some implementations will choose to deep sleep and lose any ephemeral alias storage during this cycle, others may not.
Since it is true that the REGISTER roundtrip will be an expensive operation, I suggest a new field on the DISCONNECT packet with a retainNormalAlias function. Specifying this field allows the client to tell the gateway whether to retain the registration across the sleep cycle and I believe this has been advocated for before.
1.9.1 - Correct change to be applied to section 1.3 - target v20
1.9.2 - Correct, this was applied in a field import from v5.0 in case we used these fields for the Property type we were going to use which had subsequently been dropped - target v20
1.9.3 - Correct, field name will be applied throughout the document - target v20
1.9.4 - DISCONNECT reason string shall be encoded using the new UTF-8 constrained field type (per 1.4 if agreed) and included in - target v20
1.9.5 - WSN is still relavent to the specification and should be included in the 1.3 Terminology section in - target v20
1.9.6 - For dual use bytes, ensure there is no bit based breakdown lines, and simply use text to say OR across the full byte matrix to make it a clearer read - target v20
1.9.7 - Copy and paste textual description of reason codes need to be made applicable within each packet type OR generic @see table 38 - target v20
1.9.8 - Copy and paste table name to be fixed in table 38 - target v20
1.9.9 - Correct this is mandatory and will be added as a normative statement - target v20
1.9.10 - CleanSession usage should be replaced appropriately with CleanStart as required - target v20
1.9.11 - Update to reflect new naming - target v20
1.9.12 - Correct update to document section number required - target v20
> Miroslav's points
> -----------------
>
> Key: MQTT-602
> URL: https://issues.oasis-open.org/browse/MQTT-602
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Improvement
> Components: MQTT-SN
> Affects Versions: v2.0
> Reporter: Ian Craggs
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.3#803004)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]