[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=34544#action_34544 ] Richard Coppen commented on MQTT-22: ------------------------------------ @Alex, are you comfortable with Andy's suggestion in the last comment? If so, could you make a proposal in this Jira for the TC to review > 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]