[OASIS Issue Tracker] (MQTT-208) confusing narrative around redelivery of control packets

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Richard Coppen updated MQTT-208:
--------------------------------

    Proposal: 
Remove:

While a modern TCP network is unlikely to lose packets, a Client or Server is permitted to attempt redelivery of unacknowledged packets at other times. However, redelivery is not encouraged unless a network failure has been detected. 

Adjust the following para 4.4:

...This is the only circumstance where a Client or Server is REQUIRED to redeliver messages. Clients MAY resend SUBSCRIBE and UNSUBSCRIBE Packets on reconnect but are not REQUIRED to do this. >> Redelivery of Control Packets at any other time is discouraged and should not be necessary on modern network transports. <<

  was:
Remove:

While a modern TCP network is unlikely to lose packets, a Client or Server is permitted to attempt redelivery of unacknowledged packets at other times. However, redelivery is not encouraged unless a network failure has been detected. 

Adjust the following para:

...This is the only circumstance where a Client or Server is REQUIRED to redeliver messages. Clients MAY resend SUBSCRIBE and UNSUBSCRIBE Packets on reconnect but are not REQUIRED to do this. Redelivery of Control Packets at any other time is discouraged and should not be necessary on modern network transports.


> confusing narrative around redelivery of control packets
> --------------------------------------------------------
>
>                 Key: MQTT-208
>                 URL: https://tools.oasis-open.org/issues/browse/MQTT-208
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>            Reporter: Richard Coppen
>
> Section 4.4 is slightly confusing with respect to Control Packet redelivery - the suggestion is that all packets can be retried. 3.1 CONNECT states that a second flow of CONNECT is not allowed. 
>  



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