[OASIS Issue Tracker] (MQTT-438) Review comments from Peter

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

    [ https://issues.oasis-open.org/browse/MQTT-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66314#comment-66314 ] 

Richard Coppen commented on MQTT-438:
-------------------------------------

Reviewed with editors

1(i). move TLS reference to "non normative references"
1(ii). rework wording around OPTIONAL
1(iii). soften the wording

3(i). check that termination of flow is clear for error on PUBREC (also need to consider other errors).
3(ii). add non-normative language to help understand error handing for packet id in use case.
3(iii). check that we say to "terminate QoS flow", need to wording around release of packet id in error case. Make sure it referenced back.

4. Peter will offer simplified wording

> Review comments from Peter
> --------------------------
>
>                 Key: MQTT-438
>                 URL: https://issues.oasis-open.org/browse/MQTT-438
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 5, wd14
>            Reporter: Richard Coppen
>
> Review comments from Peter (wd14)
> 1. Normative / non-Normative
> i) At the moment we don't have any normative requirements on underlying transport protocols. That looks a bit odd, but I am ok with that (I think this was a decision we made in 3.1.1). However  TLS and WebSocket are listed as Normative references
> ii) 4.10.2 (determining a response topic) is shown as Non-Normative, but I think it makes sense to have it Normative, as it includes the statement that the Response Info property is OPTIONAL.
> iii) 4.11 (Server redirection) includes Normative language, e.g. "the Server MAY also send a Server Reference to indicate the location of the Server or Servers the Client SHOULD use.".   However the format of Server Reference is vendor-specific, so I don't see how we can make normative statements about it.
> 3. Error handling on QoS 2.  
> i) We don't say anything about errors in 4.3.3. Should the sender abandon the flow if it gets an error on PUBREC?
> ii) When does a packet id become available for reuse if an error occurs?
> iii) What is the meaning of 0x91 - Packet identifier in use?  When should it be used, and what should you do if you receive a packet that contains it?
> 4. Flow control paragraph
> Simplify description



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