[OASIS Issue Tracker] Issue Comment Edited: (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=33991#action_33991 ] 

Andrew Banks edited comment on MQTT-22 at 7/1/13 8:55 AM:
----------------------------------------------------------

Alex, I think the intention of the existing MQTT specification is to allow both administered and dynamic topic names  although this is not made clear. I suggest we add a non normative comment to the specification to make this clear as follows. We need to make this non normative in order to 
avoid being too restrictive about how the server is implemented. 


Non Normative comment.

A publication is sent to each client subscription that matches the topic name in the publication.
The topic name might be either defined in the server by an administrator or it may be instantiated dynamically by the server. The serer might also use a security component to authorize actions on the topic for a given client.



      was (Author: andrew_banks):
    Alex, I think the intention of the existing MQTT specification is to allow both administered and dynamic topic names in subscriptions although this is not made clear. I suggest we add a non normative comment to the specification to make this clear as follows. We need to make this non normative in order to 
avoid being too restrictive about how the server is implemented. 


Non Normative comment.

The topic name in a subscription describes which messages a subscriber will receive.
A a subscription may be created dynamically by the server, within the restrictions of its authorization component, when it receives a SUBSCRIBE packet . 
Alternatively the subscriptions can be administratively created. The server may support one or both of these
alternatives. 

  
> 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