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=34682#action_34682 ] 

Rahul Gupta commented on MQTT-22:
---------------------------------

Added the non normative comment in section 4.5.2 Topic semantic and usage

> 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
>    Affects Versions: 3.1.1
>         Environment: MQTT Server & Client
>            Reporter: Alex Kritikos
>            Assignee: Andrew Banks
>             Fix For: 3.1.1
>
>
> 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]