[OASIS Issue Tracker] Updated: (MQTT-167) Appendix A. Mandatory normative statements

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

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

Richard Coppen updated MQTT-167:
--------------------------------

    Proposal: 
This Appendix is non-normative and is provided as a convenient summary of the numbered conformance statements found in the main body of this document. See Chapter 7 for a definitive list of conformance requirements. 

Previously:
>> Rely on normative text rather than clustering of "MUST" statements in Appendix A, which is incomplete and mis-leading in terms of the requirements for conformance. <<

  was:
This Appendix is non-normative and is provided as a convenient summary of the numbered conformance statements found in the main body of this document.  


Previously:
>> Rely on normative text rather than clustering of "MUST" statements in Appendix A, which is incomplete and mis-leading in terms of the requirements for conformance. <<


> Appendix A. Mandatory normative statements 
> -------------------------------------------
>
>                 Key: MQTT-167
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-167
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.1.1
>         Environment: Conformance
>            Reporter: Patrick Durusau
>
> Appendix A. Mandatory normative statements appears to be a listing of normative statements for conformance purposes.
> Entirely up to the TC but I think that is a mis-leading practice. 
> For example, under 1.4.1.2 UTF-8 encoded strings:
> *****
> The data SHOULD NOT include encodings of the Unicode [Unicode63] code points listed below. If a receiver (Server or Client) receives a control packet containing any of them it MAY close the network connection.
> *****
> That is normative text and it does not appear in Annex A. (Note the ambiguous reference to "code points listed below." Give the list a number and format as a list.)
> And 2.1 Fixed header and MQTT Control Packet types are normative text too.
> That is any conforming application will follow those requirements as well.
> That is to say, "MUST" doesn't make text normative.
> Taking 2.1.1 MQTT Control Packet types could be written:
> MQTT control packet types are positioned in the first byte of a MQTT control paket and are represented as a 4-bit unsigned value. The defined MQTT control packet value types are defined in Table #2 (that's not the right table number, just using that as an example).
> Assuming the section has been declared normative, that is all you need for MQTT control packet types.
> Then, elsewhere in the specification, in the conformance clause, you can say:
> "A conforming MQTT application accepts MQTT control packets (do you want "Control Packets" or control packets?) as defined in Section 2, MQTT Control Packet Format."
> Which means all the normative language in Section 2 is applicable to the conforming application, whether it is MUST, MUST NOT, SHOULD, MAY, etc. And you can simply make declarative statements like defining the types of control packets. 
> Yes? 
> As written, Appendix A leaves out all reference to MQTT Control Packet format. But it is a normative part of the specification. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira