Re: [Uri-review] URI scheme registration request

["Roy T. Fielding" <[e-mail]>]

A URI scheme should define what it names and how that naming maps to the URI syntax.
There is nothing wrong with using separate schemes for different transports if those transports
are essential parts of the name (e.g., if something named Fred at TCP:80 is different from something
named Fred at UDP:89898).  (I prefer using dots, like rr.tcp and rr.udp and rr.tcp.tls.)

The brace characters {} are not allowed in URIs. They are reserved for things like URI Templates
and local macros.

The proposed identifiers are a mix of hardcoded addresses and object identifiers. There is no
definition of the protocol being used after a connection is made. If UDP broadcast is being used
for node discovery, then what is it that the UDP packets are telling the clients? One of these URLs?

In short, I think you need to better document what each URI scheme means from the perspective of
a server and then what the client is expected to do with such a URI.  It doesn't matter if this is all
internally defined in a library that the programmers don't have to worry about: we need to see
the details to make any sense of the scheme and its security implications.

....Roy


> On Nov 13, 2015, at 9:32 PM, John Wason <[e-mail]> wrote:
> 
> Would a web browser be able to understand a question mark in the URI?  For instance, this is what a current URI looks like:
> 
> tcp://192.168.1.2:48653/{7269993b-c6b0-4135-ba55-8129a9cc6402}/example.create.Create <tcp://192.168.1.2:48653/{7269993b-c6b0-4135-ba55-8129a9cc6402}/example.create.Create>
> 
> This is obviously not going to work if I want to have a URI that can detect the protocol.  So would this:
> 
> rr://192.168.1.2:48653?transport=tcp/{7269993b-c6b0-4135-ba55-8129a9cc6402}/example.create.Create <rr://192.168.1.2:48653?transport=tcp/{7269993b-c6b0-4135-ba55-8129a9cc6402}/example.create.Create>
> 
> be considered a valid URI if I were to write a plugin for a web browser that understands the "rr" scheme?
> 
> On 11/14/2015 12:02 AM, [e-mail] <mailto:[e-mail]> wrote:
>> 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 <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] <mailto:[e-mail]>] On Behalf Of John Wason
>> Sent: Thursday, November 12, 2015 6:43 PM
>> To: [e-mail] <mailto:[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 <rr://foo> - Cloud Transport (always secure)
>> rr+cloud://foo <rr+cloud://foo> - Cloud Transport (always secure)
>> rr+tcp://foo <rr+tcp://foo> - TCP Transport
>> rrs+tcp://foo <rrs+tcp://foo> - TCP secure transport
>> rr+usb://localhost <rr+usb://localhost> - USB transport
>> rr+pci://localhost <rr+pci://localhost> - PCI/PCIe transport
>> 
>> Possible schemes for future use with websockets (currently not used)
>> rr+ws://foo <rr+ws://foo>
>> rrs+ws://foo <rrs+ws://foo>
>> rr+wss://foo <rr+wss://foo>
>> rrs+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 <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]>
> 
> -- 
> John Wason, Ph.D.
> Wason Technology, LLC
> PO Box 669
> Tuxedo, NY 10987
> [phone]
> [e-mail] <mailto:[e-mail]>_______________________________________________
> Uri-review mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/uri-review <https://www.ietf.org/mailman/listinfo/uri-review>