Re: [Uri-review] URI scheme registration request

[<[e-mail]>]

John,

My suggestion is that you use a single “rr” URI scheme for all the variants. I suspect the client will more often know what transports are available than the URI generator will. While they probably have meaning to you, the variants aren’t all that descriptive in general. For example, I can tunnel TCP over USB and you can’t be much more nebulous than “cloud”. If you try and register each variant, it will make it harder on firewall administrators (for instance) who want to handle (allow/disallow) all rr protocols the same way (in principle). It will also clutter the parameters registry.

You could include parameters to handle the variants like rr://foo?transport=tcp&security=tls. You will probably need to define parameters anyway if you want to constrain the TLS negotiation at all (say by including the remote certificate thumbprint) or your other protocol details like PCI slot. You could define these in an RFC or other document.

Regards,
David
(The above reflects my personal opinion and not necessarily that of my employer.)

From: Uri-review [mailto:[e-mail]] On Behalf Of John Wason
Sent: Thursday, November 12, 2015 6:43 PM
To: [e-mail]
Subject: [Uri-review] URI scheme registration request

Scheme Name:

The requested scheme improvement is for use with Robot Raconteur, a communication framework for robotics and automation. It will have the basic form "rr://" for unsecured transport and "rrs://" for transports secured using StartTLS channel upgrade.  Because Robot Raconteur is capable of running over multiple transports, the scheme will also need to specify which transport to use.  This will be accomplished using the "rr" "plus" transport type.  Currently in use transport schemes are:

rr://foo - Cloud Transport (always secure)
rr+cloud://foo - Cloud Transport (always secure)
rr+tcp://foo - TCP Transport
rrs+tcp://foo - TCP secure transport
rr+usb://localhost - USB transport
rr+pci://localhost - PCI/PCIe transport

Possible schemes for future use with websockets (currently not used)
rr+ws://foo
rrs+ws://foo
rr+wss://foo
rrs+wss://foo

Status:
Provisional

Application/protocols that use this scheme name:
None

Contact:
John Wason
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
[phone]
[e-mail]<mailto:[e-mail]>

Change controller:
John Wason
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
[phone]
[e-mail]<mailto:[e-mail]>

Reference:
Robot Raconteur is currently a proprietary software project.  All documentation can be found at http://robotraconteur.com/documentation .  It currently has port 48653 officially registered for TCP and UDP use along with the host names "robotraconteur" and "rr-discovery".  Standardization is of interest however the exact method and commercial implications are still being investigated.

Scheme Syntax:
See "Scheme Name"

Scheme semantics:
Each scheme will point to a host (and possibly port).  The host will be "localhost" for the hardware based protocols.

Definition of Operations:
Asynchronous message stream using binary protocol.

Context of Use:
Robot Raconteur communication protocol over port 48653 (where applicable).

Internationalization and Character Encoding:
All strings in the message stream are encoded as UTF-8 and do not have any security implications.  The only part of the URI expecting to contain international characters are hostnames registered through DNS.

Security considerations:
Robot Raconteur is mainly used for communication over the local network except for the cloud transport.  All transports over the internet use TLS or DTLS security using certificates matched to each node through a UUID unless the user specifically uses unsecured TCP.  Nodes can be secured using password and certificate based authentication. The transport itself is immune to parsing attacks as it uses length prefixes for all data fields.



--

John Wason, Ph.D.

Wason Technology, LLC

PO Box 669

Tuxedo, NY 10987

[phone]

[e-mail]<mailto:[e-mail]>