[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (MQTT-52) Handling permission problems
[ http://tools.oasis-open.org/issues/browse/MQTT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Coppen 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
0x80 - Failure
All other return codes are reserved and MUST NOT be used
<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.
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"
> 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
> Assignee: Andrew Banks
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]