Topic authorisation wrt QoS level.

[cogitoergosum]

An implementation of a broker could have an access control list that decides what topic(s) are published/subscribed by a client. Do you think, another parameter of QoS could also be considered in case of authorisation ? For example, a given client ID is allowed to publish to a topic string X but only at QoS 1. Thus, if that client ID were to publish with QoS 0 or 2, then that publication should fail.

I know, there isn't anything explicitly mentioned in the spec about this aspect of authorisation. Just curious to know.

ನಾಗೇಶ್

[Roger Light]

Hi,

> An implementation of a broker could have an access control list that decides
> what topic(s) are published/subscribed by a client. Do you think, another
> parameter of QoS could also be considered in case of authorisation ?

There's no reason why you couldn't do this. Where do you think this
would be useful?

Cheers,

Roger

[cogitoergosum]

For example, the network traffic increases in QoS 2 message. So, if a client is on a network that couldn't handle the increased bandwidth required for QoS 2, perhaps, this client should not be allowed to send QoS 2 message.

This may be trickier because neither PUBACK or PUBREC has a mechanism to inform the client that the PUBLISH failed due to authorisation issue. If the PUBACK or PUBREC had a field for say, publish return code, then the client would know that the PUBLISH failed. This is somewhat similar to failure in subscription due to authorisation failure. From the spec -  "Note that if a server implementation does not authorize a SUBSCRIBE request to be made by a client, it has no way of informing that client. It must therefore make a positive acknowledgement with a SUBACK, and the client will not be informed that it was not authorized to subscribe."

[Roger Light]

On Sat, Jul 21, 2012 at 7:47 PM, cogitoergosum <nages...@gmail.com> wrote:

> For example, the network traffic increases in QoS 2 message. So, if a client
> is on a network that couldn't handle the increased bandwidth required for
> QoS 2, perhaps, this client should not be allowed to send QoS 2 message.

I'm not sure I agree with your argument. If your message is important
enough to require QoS 2, you don't want to degrade to a lower QoS
based on available bandwidth. Also, as the spec currently stands (and
as you stated), there is no mechanism for informing the client of the
unauthorised publish, so this method in fact increase bandwidth due to
the client retrying the publish. PUBACK, PUBREC, PUBREL and PUBCOMP
are all 4 bytes long. Any publish message will be longer.

Cheers,

Roger