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-152) 4.3.3 QoS 2: Exactly once delivery diagram


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

Peter Niblett updated MQTT-152:
-------------------------------

    Proposal: 
Changes to section 4.3 - see Working Draft 4.3

1. Introductory para changed to say that diagrams are non-normative and show possible implementations.

2. All the MUST statements that are currently in 4.3 and subsections have been consolidated into 5 numbered statements
SENDER for QoS 0
SENDER for QoS 1
SENDER for QOS 2. 
RECEIVER for QOS 1
RECEIVER for QOS 2

3. Minor tidyup to normative statement in 4.4 (retry)

When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers 

(added the bit about "using their original Packet Identifiers")
4. New normative statement in 4.5

"When a Server takes ownership of an incoming Application Message it MUST add it to the Session state of clients with matching Subscriptions. Matching rules are defined in Section ‎4.7."

  was:Normative requirements should appear in normative prose and not illustrative diagrams. 


> 4.3.3 QoS 2: Exactly once delivery diagram
> ------------------------------------------
>
>                 Key: MQTT-152
>                 URL: https://tools.oasis-open.org/issues/browse/MQTT-152
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.1.1
>         Environment: Normative
>            Reporter: Patrick Durusau
>
> Using the diagram in 4.3.3 as an example, it appears to be specifying normative behavior that is not reflected in the normative prose.
> Yes?
> For example, the phrase "discard message" appears only in diagrams, not in the normative text.
> See: 4.3.3 (2X), 4.3.2
> Discard <Packet Identifier> only occurs in 4.3.3
> Discard stored state - only occurs in 4.3.3
> Store message - 4.3.3 (2X), 4.3.2
> Normative behavior should not be implied by diagrams but should appear in the normative text.



--
This message was sent by Atlassian JIRA
(v6.1.1#6155)


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