OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-417) Feedback comments on WD 11 by Stefan


     [ https://issues.oasis-open.org/browse/MQTT-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Raymor updated MQTT-417:
------------------------------

    Affects Version/s: 5

> Feedback comments on WD 11 by Stefan
> ------------------------------------
>
>                 Key: MQTT-417
>                 URL: https://issues.oasis-open.org/browse/MQTT-417
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: edits
>    Affects Versions: 5, wd11
>            Reporter: Stefan Hagen
>            Assignee: Stefan Hagen
>            Priority: Trivial
>              Labels: editorial
>
> Not ready yet (current reading position before line 684).
> Nits/Suggestions:
> @Abstract lines 26-29:
> These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.
> # - >
> Suggest to allow or to contain the and case, put examples at the end of the argument and order the former alphabetically, and pull shared term context before the list:
> These characteristics make it ideal for use in many situations, including constrained environments where a small code footprint is required or network bandwidth is at a premium, e.g. for communication in the context of Internet of Things (IoT) or Machine to Machine (M2M).
> # < -
> # ---
> @Abstract lines 30-45:
> The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections. Its features include:
> * Use of the publish/subscribe message pattern which provides one-to-many message distribution and decoupling of applications.
> * A messaging transport that is agnostic to the content of the payload. 
> * Three qualities of service for message delivery:
>   + "At most once", where messages are delivered according to the best efforts of the operating environment. Message loss can occur. This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published soon after.
>   + "At least once", where messages are assured to arrive but duplicates can occur.
>   + "Exactly once", where messages are assured to arrive exactly once. This level could be used, for example, with billing systems where duplicate or lost messages could lead to incorrect charges being applied.
> * A small transport overhead and protocol exchanges minimized to reduce network traffic. 
> * A mechanism to notify interested parties when an abnormal disconnection occurs.
> # - >
> Suggest to pull the requirements left with MQTT instead of The protocol and state TCP/IP as sample at end; and features include reads weaker than provides (or the like without exclusively this allows for skipped capabilities) allowing for edited list items reading more clear IMO; also trimmed down the sub-sub items which explained a lot more, than - I think - is expected / useful in an abstract - YMMV (maybe the "At least once" might deserve a catchy example also?):
> MQTT requires a stack of network protocols that provide ordered, lossless, bi-directional connections like e.g. TCP/IP provides. It provides:
> * Publish/subscribe message pattern for one-to-many message distribution and decoupling of applications.
> * Messaging transport agnostic of the payload content. 
> * Message delivery offering three distinct qualities of service:
>   + "At most once", where messages are delivered according to the best efforts of the operating environment and thus messages may get lost, for example, with ambient sensor data.
>   + "At least once", where messages are assured to arrive but duplicates can occur.
>   + "Exactly once", where messages are assured to arrive exactly once, for example, with billing systems.
> * Reduced network traffic through small transport overhead and minimized protocol exchanges. 
> * Mechanism to notify interested parties when an abnormal disconnection occurs.
> # < -
> # ---
> @"1.3 Normative references" lines 425-447:
> @"1.4 Non-Normative references" lines 450-560:
> Suggested to avoid linebreaks inside statements like "DOI 10.17487/RFC2119", "December 2011", "RFC 1928", and the like
> # ---
> @"1.5.4 UTF-8 Encoded String" line 607:
> As a normative quite convoluted sentence( start) reads a bit indirect:
>  A UTF-8 encoded sequence 0xEF 0xBB 0xBF is always to be interpreted to mean U+FEFF ("ZERO
> # - >
> Suggested rewording:
>  The UTF-8 encoded sequence 0xEF 0xBB 0xBF is always interpreted as U+FEFF ("ZERO
> # < -
> # ---
> @"1.5.6 Binary Data" full sentence at line 663/664:
> Note: The below "Where used" sounds more unclear, than the previous a "Binary Data is represented by" statement.
> [Bytes. ] Where used the data consists only of the data portion of the field, which can take any value and
> does not include first two length bytes.
> Maybe better describe the effective length range in bytes of the rpresentation (if necessary at all)
> # ---
> @"1.7 Editing convention" at lines 680-683
> As the yellow highlight to many readers most probably looks like unintented leftovers from draft stages instead the intended and in this section explained rationale, suggested is to move this section before the first such highlighted statement.
> # ---
> Component and JIRA's severity field "priority (shiver)" set in the hopes it will be only editorial and trivial to fix whatever I will find.
> To cite Richard's announcement of WD11 ready to review:
> The editors have requested that each TC member open one Jira containing their feedback comments. The editors can then process anything editorial, remove duplicates, and bring more substantial issues to the attention of the TC.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]