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] Commented: (MQTT-167) Appendix A. Mandatory normative statements

    [ http://tools.oasis-open.org/issues/browse/MQTT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36681#action_36681 ] 

Richard Coppen commented on MQTT-167:

TC approve proposal 27.02.2014:

(Now Appendix B in WD18)

>>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.<< 

> 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 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


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