[OASIS Issue Tracker] (MQTT-203) MQTT URI Scheme

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

    [ https://issues.oasis-open.org/browse/MQTT-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61686#comment-61686 ] 

Nicholas O'Leary edited comment on MQTT-203 at 1/27/16 11:40 AM:
-----------------------------------------------------------------

Following discussion at the Jan 2016 face-to-face TC meeting, the following comments were made:

 - This should reference RFC 3986 for URI structure > https://www.ietf.org/rfc/rfc3986.txt
 - It should get registered as an IANA URI Scheme
 - Publish first as a Committee note, but in proper IANA language to enable its registration (can be picked up as a (non?)normative chapter in a future spec)
 - The 'query parameters' should be full specified for all connect options (not just clientid as in the current proposal)
 - The URI could include a topic as part of the 'path' component
    - including a topic raises questions over encoding:
       - Standard uri parsing libraries will clean up path components to remove double slashes and relative components ('/a/../b' -> '/b')
       - topics that begin with a '/' are tricky as they will naturally need to have a double slash in the uri

 - This presumes a raw TCP connection. How might it extend to identifying the transport is websocket based (or ano underlying transport in the future)



Next steps:

 - Nick to come back with an updated proposal that addresses these points


was (Author: knolleary):
Following discussion at the Jan 2016 face-to-face TC meeting, the following comments were made:

 - This should reference RFC 3986 for URI structure > https://www.ietf.org/rfc/rfc3986.txt
 - It should get registered as an IANA URI Scheme
 - Publish first as a Committee note, but in proper IANA language to enable its registration (can be picked up as a (non?)normative chapter in a future spec)
 - The 'query parameters' should be full specified for all connect options (not just clientid as in the current proposal)
 - The URI could include a topic as part of the 'path' component
    - including a topic raises questions over encoding:
       - Standard uri parsing libraries will clean up path components to remove double slashes and relative components ('/a/../b' -> '/b')
       - topics that begin with a '/' are tricky as they will naturally need to have a double slash in the uri

 - This presumes a raw TCP connection. How might it extend to identifying the transport is websocket based (or ano underlying transport in the future)



> MQTT URI Scheme
> ---------------
>
>                 Key: MQTT-203
>                 URL: https://issues.oasis-open.org/browse/MQTT-203
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: futures
>            Reporter: Nicholas O'Leary
>            Priority: Critical
>
> There have been a number of discussions in the community on how to specify a broker's connection details in a uri.
> The result of the community discussion is captured here - https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme
> In summary, the following uri format is proposed:
>     mqtt://[username][:password]@host.domain[:port][?clientid=clientid]
> The uri scheme could alternative be 'mqtts' to specify a secure TLS connection should be used.
> Other connection-time options (clean session etc) could also be expressed as query parameters.
> A path portion of the uri could be used to specify a specific topic.
> This JIRA can be addressed by way of Committee Note, rather than as an addition to the spec itsef.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)