[OASIS Issue Tracker] Commented: (MQTT-22) Specification is ambiguous with regards to dynamic topics

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

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

Alex Kritikos commented on MQTT-22:
-----------------------------------

Andrew / Richard,

I am happy with a non normative comment. Andrew's suggestion is fine, i would just slightly change it so that its clear we are talking about the server resource. My proposal (based on Andrew's) is as follows:


Non Normative comment. 

A publication is sent to each client subscription that matches the topic name in the publication. 
The topic resource may be either predefined in the server by an administrator or it may be dynamically created by the server when it receives the first subscription or publication with that topic name. The server may also use a security component to selectively authorize actions on the topic resource for a given client. 


> 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