Subject: [Uri-review] URI scheme registration request

From: John Wason <[email-masked]>
Date: Thu, 12 Nov 2015 19:42:36 -0500

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
+1-518-279-6234
[email-masked]

Change controller:
John Wason
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
+1-518-279-6234
[email-masked]

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
(518) 279-6234
[email-masked]

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Fri, 13 Nov 2015 20:33:47 -0500

> rr+pci://localhost - PCI/PCIe transport

You don't say what the format and content of the 'foo' parts is. Does 
it begin with something that can be considered an "authority" segment 
(e.g., a hostname or IP address)? That's what the '//' part is 
supposed to signify; lots of people designing URI schemes seem to 
think the slashes belong after the colon in all cases, but they're 
only supposed to be there if there's an authority involved.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

---

From: John Wason <[email-masked]>
Date: Fri, 13 Nov 2015 23:11:44 -0500

"foo" is an IP address or hostname.

-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
(518) 279-6234
[email-masked]

---

From: <[email-masked]>
Date: Fri, 13 Nov 2015 23:02:21 -0600

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:[email-masked]] On Behalf Of John Wason
Sent: Thursday, November 12, 2015 6:43 PM
To: [email-masked]
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:

Status:
Provisional

Contact:
John Wason
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
+1-518-279-6234
[email-masked]<mailto:[email-masked]>

Change controller:
John Wason
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
+1-518-279-6234
[email-masked]<mailto:[email-masked]>

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.

Context of Use:

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

(518) 279-6234

[email-masked]<mailto:[email-masked]>

---

From: John Wason <[email-masked]>
Date: Sat, 14 Nov 2015 00:32:21 -0500

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

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

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, [email-masked] 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. 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
>
> *From:*Uri-review [mailto:[email-masked]] *On Behalf Of 
> *John Wason
> *Sent:* Thursday, November 12, 2015 6:43 PM
> *To:* [email-masked]
> *Subject:* [Uri-review] URI scheme registration request
>
> Scheme Name:
>
> to specify which transport to use.  This will be accomplished using 
> the "rr" "plus" /transport type/.  Currently in use transport schemes are:
>
> [email-masked] <mailto:[email-masked]>
>
> Change controller:
> John Wason
> Wason Technology, LLC
> PO Box 669
> Tuxedo, NY 10987
> +1-518-279-6234
> [email-masked] <mailto:[email-masked]>
>
> Reference:
> 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".  
> Each scheme will point to a host (and possibly port).  The host will 
> be "localhost" for the hardware based protocols.
>
> 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
> (518) 279-6234
> [email-masked] <mailto:[email-masked]>

-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
(518) 279-6234
[email-masked]

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 14 Nov 2015 11:00:50 -0800

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 <[email-masked]> 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, [email-masked] <mailto:[email-masked]> wrote:
>> John,
>>  
>> 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
>> From: Uri-review [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of John Wason
>> To: [email-masked] <mailto:[email-masked]>
>> 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
>> 
>> 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
>> 
>> 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:
> [email-masked] <mailto:[email-masked]>_______________________________________________
> Uri-review mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/uri-review <https://www.ietf.org/mailman/listinfo/uri-review>

---

From: <[email-masked]>
Date: Sat, 14 Nov 2015 13:47:35 -0600

The syntax for a URI is defined in RFC3986: https://www.ietf.org/rfc/rfc3986.txt It specifies what characters are allowed where and what there general meaning is. It is helpful to be very familiar with that document before designing a URI scheme.

At a high level you have:
      URI         = scheme “:” hier-part [ “?” query ] [ “#” fragment ]

The hier-part includes an authority (host) and any hierarchical data. File systems are hierarchical (delineated by the “/” character), and if you have some sort of robot army it might be hierarchical as well. It is not ideal to use the hier-part for non-hierarchical data. The query can help identify a resource, it isn’t entirely clear what you want to identify with the guid and example. However one approach could be something like:

rr://192.168.1.2:48653?transport=tcp&target=7269993b-c6b0-4135-ba55-8129a9cc6402&cmd=example.create.Create<rr://192.168.1.2:48653?transport=tcp/%7b7269993b-c6b0-4135-ba55-8129a9cc6402%7d/example.create.Create>

From: Roy T. Fielding [mailto:[email-masked]]
Sent: Saturday, November 14, 2015 1:01 PM
To: John Wason
Cc: Warden, David; [email-masked]
Subject: Re: [Uri-review] URI scheme registration request

....Roy

On Nov 13, 2015, at 9:32 PM, John Wason <[email-masked]<mailto:[email-masked]>> wrote:

tcp://192.168.1.2:48653/{7269993b-c6b0-4135-ba55-8129a9cc6402}/example.create.Create<tcp://192.168.1.2:48653/%7b7269993b-c6b0-4135-ba55-8129a9cc6402%7d/example.create.Create>

rr://192.168.1.2:48653?transport=tcp/{7269993b-c6b0-4135-ba55-8129a9cc6402}/example.create.Create<rr://192.168.1.2:48653?transport=tcp/%7b7269993b-c6b0-4135-ba55-8129a9cc6402%7d/example.create.Create>

On 11/14/2015 12:02 AM, [email-masked]<mailto:[email-masked]> wrote:
John,

Regards,
David

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

Scheme Name:

Status:
Provisional

Contact:
John Wason
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
+1-518-279-6234

Change controller:
John Wason
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
+1-518-279-6234

Reference:

Scheme Syntax:
See "Scheme Name"

Scheme semantics:

Context of Use:

Security considerations:

--

John Wason, Ph.D.

Wason Technology, LLC

PO Box 669

Tuxedo, NY 10987

(518) 279-6234

--

John Wason, Ph.D.

Wason Technology, LLC

PO Box 669

Tuxedo, NY 10987

(518) 279-6234

[email-masked]<mailto:[email-masked]>
_______________________________________________
Uri-review mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/uri-review

---

From: Dave Thaler <[email-masked]>
Date: Sat, 14 Nov 2015 20:07:20 +0000

> named Fred at UDP:89898).  (I prefer using dots, like rr.tcp and rr.udp and rr.tcp.tls.)

Careful… RFC 7595 states:
   Furthermore, to prevent collisions with private-use scheme names, new
   scheme names registered MUST NOT contain a "." unless actually
   constructed from a reversed domain name.

So rr.tcp should only be done if you register rr as a TLD, and since rr is 2 letters, it’s reserved for a country code.

Dave

---

From: John Wason <[email-masked]>
Date: Sat, 14 Nov 2015 17:21:05 -0500

Is it possible to register a "wildcard" or have an understanding that 
the scheme can be appended with the transport type?  Subversion uses 
"svn+ssh" to specify an ssh tunnel.  This format seems to be used 
occasionally in practice. Because the different transports can point to 
completely different resources on the same host I am not sure having the 
transport in the query portion is the correct solution.

On 11/14/2015 3:07 PM, Dave Thaler wrote:
> So rr.tcp should only be done if you register rr as a TLD, and since 
> rr is 2 letters, it’s reserved for a country code.
>
> Dave
>

-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
(518) 279-6234
[email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Sat, 14 Nov 2015 23:37:35 +0000

Short answer: unfortunately no

This was the subject of issue #16:
http://trac.tools.ietf.org/wg/appsawg/trac/ticket/16

It was discussed at IETF 89 and then again at IETF 90. In both cases, and as confirmed on the list,
the consensus of the WG was to not allow a notion of wildcards.   Instead you have to individually
register each such scheme.  I see “svn+ssh” is not currently registered, but it sounds like it ought to be.

Dave

From: John Wason [mailto:[email-masked]]
Sent: Saturday, November 14, 2015 2:21 PM
To: Dave Thaler <[email-masked]>; Roy T. Fielding <[email-masked]>
Cc: [email-masked]
Subject: Re: [Uri-review] URI scheme registration request

Is it possible to register a "wildcard" or have an understanding that the scheme can be appended with the transport type?  Subversion uses "svn+ssh" to specify an ssh tunnel.  This format seems to be used occasionally in practice.  Because the different transports can point to completely different resources on the same host I am not sure having the transport in the query portion is the correct solution.

Dave

--

John Wason, Ph.D.

Wason Technology, LLC

PO Box 669

Tuxedo, NY 10987

(518) 279-6234

---

From: John Wason <[email-masked]>
Date: Fri, 20 Nov 2015 23:20:06 -0500

I have prepared a more detailed description of the transports and URI 
request.  Please let me know if you need further specific details:

Robot Raconteur URI Scheme Improvement

John Wason

Wason Technology, LLC

[email-masked]

11/20/15

*Introduction*

Robot Raconteur is being improved to better comply with web standards by 
adding support for WebSocket transports and implementing a new URI 
scheme that can be registered with IANA.The URIs for Robot Raconteur use 
the following basic format:

rr+transport://hostname:port/path/to/endpoint?service=servicename&nodename=targetnodename&nodeid=targetnodeuuid

The scheme is “rr”, “+”, and then the transport type.For instance for 
TCP the scheme is “rr+tcp”. If TLS is used, “rr” is replaced with “rrs” 
to indicate the extra security.For TCP a secure transport would use the 
scheme “rrs+tcp”. The following schemes are used and will each be 
discussed in detail in the following sections:

·rr+tcp

·rrs+tcp

·rr+local

·rr+usb

·rr+pci

·rr

·rr+cloud

·rr+ws

·rrs+ws

·rr+wss

·rrs+wss

Each of these schemes corresponds to a different selection of transports 
and security options.

The hostname and port correspond to the hostname and port of the target 
machine.If no port is specified the default is used.For rr+local, 
rr+tcp, rr+usb, rr+pci, rr, and rr+cloud the port must not be included 
as these do not use ports to find the target.

The absolute path (/path/to/endpoint) in the example is only used for 
WebSockets with HTTP to identify the WebSocket target and must be empty 
or “/” for all other transport types.

The query contains the name of the service to connect to.It may also 
contain the nodeid and nodename if desired to help find the node.The 
same endpoint can provide connection to multiple nodes so this provides 
a way to select the target node. The query string can also be used to 
pass extra parameters to the WebSocket HTTP server if desired.The query 
string is passed unmodified to the server.

All nodes can be secured with username and credential pairs.

A functional example of a Robot Raconteur URI is:

rr+tcp://192.168.2.3:48653/?nodeid= 
a7aa5f85-dfa7-41fe-89a1-1ebff43b9580&service=create

The following sections will describe the exact transports and how they 
create connections to the target nodes.

*TCP Transport*

·rr+tcp – Standard TCP communication

·rrs+tcp – TLS TCP communication

The TCP Transport operates by connecting to a remote port and then using 
the Robot Raconteur protocol to communicate.The official listen port is 
48653. The path must be “/” or empty. The first handshake contains the 
target nodeid and/or nodename to identify which node should be 
connected.Both can be blank to connect to the default node on the 
endpoint.The communication can be wrapped in TLS using Start TLS 
semantics.The first message contains the target nodeid and/or nodename 
and a flag to start using TLS.The server node then provides a 
certificate signed by Wason Technology, LLC issued to the UUID (nodeid) 
of the node.The client can also provide a signed certificate to provide 
certificate based authentication.

Discovery for TCP is accomplished through UDP packets that are broadcast 
periodically on port 48653.The packets contain the nodeid, nodename, the 
connection URI, and some additional metadata to help identify the 
capabilities.The information is generally only used to connect to the 
“Service Index” that runs on all nodes.This index provides detailed 
information about the services available and how to connect.The clients 
will interrogate the nodes through the Service Index to determine if the 
node matches the search criteria.During this process it will also verify 
the TLS certificates if appropriate.

*WebSocket Transport*

The WebSocket transport is an extension to the TCP transport and in the 
software is directly integrated into the TCP transport.It works by 
wrapping the TCP transport data into WebSocket binary frames. The frame 
boundaries are ignored as the stream is reassembled on the receiving 
end.The frames however shall be equal to or less than 4 KB of data per 
frame.

The transport also implements the HTTP handshake to start the WebSocket 
protocol using the subprotocol “robotraconteur”. The URI contains the 
path to the WebSocket and query information, both of which are passed 
unmodified to the server. The URI must contain a query parameter named 
“service” to identify the name of the service to connect.

All nodes that listen for TCP connections shall also be capable of 
detecting and accepting an HTTP WebSocket connection to the root file 
path “/” on the same port that listens for standard Robot Raconteur 
connections. This allows for standard web browsers to connect without 
additional plugins. (Note that HTTPS (wss) is not possible in this 
configuration. See below.)

TLS is somewhat complicated with WebSockets due to the handshake 
behavior.There are four flavors of WebSocket connections:

·rr+ws – No encryption (HTTP)

·rrs+ws – Encryption using the TLS Robot Raconteur transport.This does 
not encrypt the HTTP handshake.For local network use connecting to a 
device this should be sufficient as the handshake only contains the 
target nodeid/service information which is not considered secret data. 
Just after the handshake the Robot Raconteur TLS layer is activated 
protecting any secret data. (HTTP)

·rr+wss – Encrypted HTTPS transport but no Robot Raconteur 
encryption.Not recommended because the target node identity is not 
verified. (HTTPS)

·rrs+wss – Encryption HTTPS transport and TLS Robot Raconteur 
transport.This will encrypt the HTTP handshake and allow for identity 
verification of the node.Note that this is only possible when the target 
node has an official HTTPS certificate which is not available for IoT 
type devices.In those cases rrs+ws should be used as it is designed for 
such scenarios. rrs+wss should only be used when it is determined to be 
truly necessary.

*Local Transport*

·rr+local

The local transport uses UNIX sockets or Named Pipes to communicate 
between nodes on the same machine.The nodeid and/or nodename are used to 
identify the target nodes.The host is always “localhost”.A username can 
be used to specify which user owns the desired node, ie 
“username@localhost”.The port is never used and must be left out of the 
URI. Access control is accomplished through file permissions and 
standard username/credential access control. Untrusted software shall 
not be allow local transport access. The path must be “/” or empty.

*Hardware Transport*

·rr+usb

·rr+pci

Hardware device drivers are implemented through a userspace daemon 
service.This service provides UNIX socket / Named Pipe connections that 
allow nodes to access the devices.Access control is accomplished through 
file permissions.Generally only admin or equivalent users are given 
access. Untrusted software shall not be allow local transport access. 
The path must be “/” or empty.

*Cloud Transport*

·rr

·rr+cloud

The cloud transport is a transport based on WebRTC.The signaling as 
accomplished through the Robot Raconteur server.Nodes are identified by 
the Robot Raconteur username and nodeid/nodname pair.The hostname for 
each user is “username.cloud.robotraconteur.com”, where username is 
replaced with the registered username.For instance, 
“johnw.cloud.robotraconteur.com” would be the hostname “johnw”. The port 
must not be included. Nodes connecting to the cloud service must all 
have issued certificates tied to the uuid of the node (nodeid). This 
communication is always secured through DTLS at the WebRTC 
layer.Security of the overall cloud is managed by the Robot Raconteur 
server. The hostnames for each user are only relevant within the 
signaling server and do not have any general use DNS meaning. “rr” and 
“rr+cloud” are equivalent. The path must be “/” or empty.

On 11/14/2015 6:37 PM, Dave Thaler wrote:
> register each such scheme.  I see “svn+ssh” is not currently 
> registered, but it sounds like it ought to be.
>
> Dave
>
> *From:*John Wason [mailto:[email-masked]]
> *Sent:* Saturday, November 14, 2015 2:21 PM
> *To:* Dave Thaler <[email-masked]>; Roy T. Fielding 
> <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Uri-review] URI scheme registration request
>
> occasionally in practice.  Because the different transports can point 
> to completely different resources on the same host I am not sure 
> having the transport in the query portion is the correct solution.
>
>     So rr.tcp should only be done if you register rr as a TLD, and
>     since rr is 2 letters, it’s reserved for a country code.
>
>     Dave
>
>
>
>
> -- 
> John Wason, Ph.D.
> Wason Technology, LLC
> PO Box 669
> Tuxedo, NY 10987
> (518) 279-6234

-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
(518) 279-6234
[email-masked]

---

From: John Wason <[email-masked]>
Date: Mon, 23 Nov 2015 21:30:20 -0500

I sent the requested information on the URI usage but I think it may 
have bounced because it was too large.  I have put the text on pastebin 
so it can be reviewed. I can send the word document if someone needs a 
permanent copy but it is too large for the list.

http://pastebin.com/4s4e6CjY

     -Dr. Wason

-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
(518) 279-6234
[email-masked]

---

From: John Wason <[email-masked]>
Date: Mon, 30 Nov 2015 22:07:24 -0500

Are there any more questions about this request?  I have not received 
any replies.

-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
(518) 279-6234
[email-masked]