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-22) Specification is ambiguous with regards to dynamic topics

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

Dominik Obermaier commented on MQTT-22:

Creation of dynamic topic is a feature which is critical in scenarios where a undefined number of MQTT clients communicate. I strongly favor that each broker vendor can (and should!) implement a mechanism to restrict topics a client can subscribe/publish to (which is imho way beyond the spec). This could be based on the client credentials or client id or whatever the broker vendor chooses to implement. My thoughts on your points:

1) I don't think we can assume that a single broker is used in most cases by multiple applications. We can however for sure assume that a single broker is used by many MQTT clients. If you want to separate the namespaces and the permissions of a client (= "is the client allowed to publish/subscribe on this topic"), your broker should provide a mechanism to do that. I personally think this permission model has nothing to do with dynamic topics because you need the permission model anyway when preventing to publish to another namespace.

2) Again, this can be prevented with a proper permission model on the server.

3) In such an integration scenario the clients most likely need to know on which topic they must publish so the mapping between the MQTT topic and the queue can take place. This is way beyond basic publish/subscribe communication. I experienced that advanced administrative tasks have to be made on the broker side anyway in such scenarios.

I think dynamic topics are one of the features where MQTT excels. It makes it a bit harder for broker vendors but for the users of MQTT this is definitely one of the outstanding features.

> Specification is ambiguous with regards to dynamic topics
> ---------------------------------------------------------
>                 Key: MQTT-22
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-22
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>         Environment: MQTT Server & Client
>            Reporter: Alex Kritikos
>            Assignee: Alex Kritikos
> In the current specification there is no explicit definition of dynamic topic creation. The behaviour of purpose built MQTT only brokers seems to be that topics are dynamically created when a publisher first publishes a message to a topic or when a subscriber subscribes to a topic. This is conceived to be a feature of the 'zero administration' capability that the protocol wishes to deliver: it is assumed that if a client is successfully authenticated then it can also publish / subscribe to arbitrary topic names. 
> I personally do not agree with that model for three reasons:
> 1. A single broker will in most cases be used by multiple applications. A misconfigured client could therefore publish unexpected messages in another application's namespace. 
> 2. As lightweight as MQTT topics may be considered, they surely require some resources on the server. A user could quickly kill a broker by creating very large number of topics accidentally or intentionally.
> 3. Existing MOM brokers that wish to add support for MQTT as a transport protocol may wish to expose other types of server resources (e.g. a queue) so if creation is dynamic how can the resource type be controlled?
> Additionally, if MQTT wants to deliver a 'zero config' approach why does it rely on authentication only? If you are running on a public network you will likely want some level of control not only over who connects but also what they can do. This requires topic level administration so i find it contradictory to dynamic topic creation as far as 'zero config' is concerned.
>  The same applies for another spec statement that reads: "These are the QoS levels at MQTT V3.1 Protocol Specification 12 of 42 which the administrators for the server have permitted the client to subscribe to a particular Topic Name." : Again an out of band administrative function for topics and the subsequent setting of permissions/ACL's of them is suggested which is also contradictory to dynamic topic creation with regards to 'zero config'.

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]