[OASIS Issue Tracker] Updated: (MQTT-52) Handling permission problems

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

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

Allan Stockdill-Mander  updated MQTT-52:
----------------------------------------

    Proposal: 
The 3.1.1 specification should provide a clarification to promote better clients client side error handling, retry and recovery behavior. 


Change Publish (WD13  844)

If a server implementation does not authorize a PUBLISH to be performed by a client; it has no way of informing that client. It MUST either make a positive acknowledgement, according to the normal QoS rules or disconnect the TCP session.


Change Subscribe (WD13 979)

The Payload of a SUBSCRIBE packet MUST contain at least one topic filter / QoS pair. A SUBSCRIBE packet with no payload is a protocol violation.

Remove 991 - 995 (WD13) See MQTT Issue-52 ... authorized to subscribe.

Change from 997 


A SUBACK Packet MUST be sent to the Client by the Server containing a return code for each topic filter/QoS pair. The Server might grant a lower maximum QoS than the subscriber requested. The QoS of Payload Messages sent in response to a subscription MUST be the minimum of the QoS of the originally published message and the maximum QoS granted by the Server.


Change table under 3.9.3 SUBACK Payload to have 4 values, all bits used, remove reserved/granted QoS to read return code.

0x00 - Success - Maximum QoS0
0x01 - Success - Maximum QoS1
0x02 - Success - Maximum QoS2
0x20 - Not allowed

<add to non normative example for failed>

change 1048 - 

substitute "return codes" for "granted QoS's" 

  was:
The 3.1.1 specification should provide a clarification to promote better clients client side error handling, retry and recovery behavior. For example:

The server MAY make a positive acknowledgement, according to the normal QoS rules, and SHOULD disconnect the TCP session.

It is likely that most clients are already written to cope with TCP session failures. By correlating the session failure with the PUBLISH call and state of network connectivity, a client may deduce (more reliably) that there is an permission or configuration problem.


> Handling permission problems
> ----------------------------
>
>                 Key: MQTT-52
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-52
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.1.1
>            Reporter: Richard Coppen
>             Fix For: 3.1.1
>
>
> What should a server do if a client attempts to perform an operation that is disallowed?
> For example:
> 1. Attempts to publish to a topic for which they do not have permission
> The input specification (which is not based on RFC2119 terminology) provides ambiguous guidance for such a scenario. 
> "Note that if a server implementation does not authorize a PUBLISH to be made by a client; it has no way of informing that client. It must therefore make a positive acknowledgement, according to the normal QoS rules, and the client will not be informed that it was not authorized to publish the message."
> This behavior is problematic (strictly enforced or not) since a valid client talking to a poorly configured server will continue to process work unaware of the problem. In practice it is very difficult, if not impossible, to write a client application with error handling and recovery logic to defend against it.

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