URI scheme registration request

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

URI scheme registration request

John Wason
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
[hidden email]

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

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
[hidden email]

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

Daniel R. Tobias
On 12 Nov 2015 at 19:42, John Wason wrote:

> 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

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/


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

John Wason
"foo" is an IP address or hostname.

On 11/13/2015 8:33 PM, Daniel R. Tobias wrote:

> On 12 Nov 2015 at 19:42, John Wason wrote:
>
>> 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
> 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.
>


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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

David_Warden
In reply to this post by John Wason

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:[hidden email]] On Behalf Of John Wason
Sent: Thursday, November 12, 2015 6:43 PM
To: [hidden email]
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
+1-518-279-6234
[hidden email]

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

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
[hidden email]

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

John Wason
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, [hidden email] 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

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

 

From: Uri-review [[hidden email]] On Behalf Of John Wason
Sent: Thursday, November 12, 2015 6:43 PM
To: [hidden email]
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
+1-518-279-6234
[hidden email]

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

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
[hidden email]


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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

Roy T. Fielding
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 <[hidden email]> 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:

<a href="tcp://192.168.1.2:48653/{7269993b-c6b0-4135-ba55-8129a9cc6402}/example.create.Create" style="color: purple; text-decoration: underline;" class="">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:

<a href="rr://192.168.1.2:48653?transport=tcp/{7269993b-c6b0-4135-ba55-8129a9cc6402}/example.create.Create" style="color: purple; text-decoration: underline;" class="">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, [hidden email] 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 <a href="rr://foo?transport=tcp&amp;security=tls" style="color: purple; text-decoration: underline;" class="">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 [[hidden email]] On Behalf Of John Wason
Sent: Thursday, November 12, 2015 6:43 PM
To: [hidden email]
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:

<a href="rr://foo" style="color: purple; text-decoration: underline;" class="">rr://foo - Cloud Transport (always secure)
<a href="rr+cloud://foo" style="color: purple; text-decoration: underline;" class="">rr+cloud://foo - Cloud Transport (always secure)
<a href="rr+tcp://foo" style="color: purple; text-decoration: underline;" class="">rr+tcp://foo - TCP Transport
<a href="rrs+tcp://foo" style="color: purple; text-decoration: underline;" class="">rrs+tcp://foo - TCP secure transport
<a href="rr+usb://localhost" style="color: purple; text-decoration: underline;" class="">rr+usb://localhost - USB transport
<a href="rr+pci://localhost" style="color: purple; text-decoration: underline;" class="">rr+pci://localhost - PCI/PCIe transport

Possible schemes for future use with websockets (currently not used)
<a href="rr+ws://foo" style="color: purple; text-decoration: underline;" class="">rr+ws://foo
<a href="rrs+ws://foo" style="color: purple; text-decoration: underline;" class="">rrs+ws://foo
<a href="rr+wss://foo" style="color: purple; text-decoration: underline;" class="">rr+wss://foo
<a href="rrs+wss://foo" style="color: purple; text-decoration: underline;" class="">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
[hidden email]

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

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
[hidden email]


-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
(518) 279-6234
[hidden email]
_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

David_Warden

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:


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

 

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

 

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 <[hidden email]> 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:

<a href="tcp://192.168.1.2:48653/%7b7269993b-c6b0-4135-ba55-8129a9cc6402%7d/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:

<a href="rr://192.168.1.2:48653?transport=tcp/%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

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, [hidden email] 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 <a href="rr://foo?transport=tcp&amp;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 [[hidden email]] On Behalf Of John Wason
Sent: Thursday, November 12, 2015 6:43 PM
To: [hidden email]
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:

<a href="rr://foo">rr://foo - Cloud Transport (always secure)
<a href="rr+cloud://foo">rr+cloud://foo - Cloud Transport (always secure)
<a href="rr+tcp://foo">rr+tcp://foo - TCP Transport
<a href="rrs+tcp://foo">rrs+tcp://foo - TCP secure transport
<a href="rr+usb://localhost">rr+usb://localhost - USB transport
<a href="rr+pci://localhost">rr+pci://localhost - PCI/PCIe transport

Possible schemes for future use with websockets (currently not used)
<a href="rr+ws://foo">rr+ws://foo
<a href="rrs+ws://foo">rrs+ws://foo
<a href="rr+wss://foo">rr+wss://foo
<a href="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
+1-518-279-6234
[hidden email]

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

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
[hidden email]




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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review

 


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

Dave Thaler-2
In reply to this post by Roy T. Fielding

Roy T. Fielding wrote:

> 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.)

 

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


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

John Wason
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:

Roy T. Fielding wrote:

> 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.)

 

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



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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

Dave Thaler-2

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:[hidden email]]
Sent: Saturday, November 14, 2015 2:21 PM
To: Dave Thaler <[hidden email]>; Roy T. Fielding <[hidden email]>
Cc: [hidden email]
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.

On 11/14/2015 3:07 PM, Dave Thaler wrote:

Roy T. Fielding wrote:

> 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.)

 

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




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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

John Wason
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

[hidden email]

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:

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 [[hidden email]]
Sent: Saturday, November 14, 2015 2:21 PM
To: Dave Thaler [hidden email]; Roy T. Fielding [hidden email]
Cc: [hidden email]
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.

On 11/14/2015 3:07 PM, Dave Thaler wrote:

Roy T. Fielding wrote:

> 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.)

 

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




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


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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

John Wason
In reply to this post by Dave Thaler-2
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 

On 11/14/2015 6:37 PM, Dave Thaler wrote:

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 [[hidden email]]
Sent: Saturday, November 14, 2015 2:21 PM
To: Dave Thaler [hidden email]; Roy T. Fielding [hidden email]
Cc: [hidden email]
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.

On 11/14/2015 3:07 PM, Dave Thaler wrote:

Roy T. Fielding wrote:

> 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.)

 

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




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


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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

John Wason
In reply to this post by Dave Thaler-2
Are there any more questions about this request?  I have not received any replies.

On 11/14/2015 6:37 PM, Dave Thaler wrote:

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 [[hidden email]]
Sent: Saturday, November 14, 2015 2:21 PM
To: Dave Thaler [hidden email]; Roy T. Fielding [hidden email]
Cc: [hidden email]
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.

On 11/14/2015 3:07 PM, Dave Thaler wrote:

Roy T. Fielding wrote:

> 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.)

 

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




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


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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

Ted Hardie-2
On Mon, Nov 30, 2015 at 7:07 PM, John Wason <[hidden email]> wrote:
Are there any more questions about this request?  I have not received any replies.


​Hi John,​

​I think this is sufficient for provisional registration.  Hopefully some other folks can chime in as well.

regards,

Ted​

 
On 11/14/2015 6:37 PM, Dave Thaler wrote:

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 [[hidden email]]
Sent: Saturday, November 14, 2015 2:21 PM
To: Dave Thaler [hidden email]; Roy T. Fielding [hidden email]
Cc: [hidden email]
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.

On 11/14/2015 3:07 PM, Dave Thaler wrote:

Roy T. Fielding wrote:

> 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.)

 

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




-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
<a href="tel:%28518%29%20279-6234" value="+15182796234" target="_blank">(518) 279-6234
[hidden email]


-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
<a href="tel:%28518%29%20279-6234" value="+15182796234" target="_blank">(518) 279-6234
[hidden email]

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review



_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

Dave Thaler-2

Agree, the bar for provisional is supposed to be low.

 

From: Ted Hardie [mailto:[hidden email]]
Sent: Tuesday, December 1, 2015 8:01 AM
To: John Wason <[hidden email]>
Cc: Dave Thaler <[hidden email]>; [hidden email]
Subject: Re: [Uri-review] URI scheme registration request

 

On Mon, Nov 30, 2015 at 7:07 PM, John Wason <[hidden email]> wrote:

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

 

​Hi John,​

 

​I think this is sufficient for provisional registration.  Hopefully some other folks can chime in as well.

regards,

Ted​


 

On 11/14/2015 6:37 PM, Dave Thaler wrote:

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 [[hidden email]]
Sent: Saturday, November 14, 2015 2:21 PM
To: Dave Thaler [hidden email]; Roy T. Fielding [hidden email]
Cc: [hidden email]
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.

On 11/14/2015 3:07 PM, Dave Thaler wrote:

Roy T. Fielding wrote:

> 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.)

 

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



-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
<a href="tel:%28518%29%20279-6234" target="_blank">(518) 279-6234
[hidden email]




-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
<a href="tel:%28518%29%20279-6234" target="_blank">(518) 279-6234
[hidden email]


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review

 


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

Roy T. Fielding
In reply to this post by John Wason
On Nov 20, 2015, at 8:20 PM, John Wason <[hidden email]> wrote:

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
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:
 
<a href="rr+transport://hostname:port/path/to/endpoint?service=servicename&amp;nodename=targetnodename&amp;nodeid=targetnodeuuid" style="color: purple; text-decoration: underline;" class="">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:
 
<a href="rr+tcp://192.168.2.3:48653/?nodeid=" style="color: purple; text-decoration: underline;" class="">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.

I still don't see what the purpose is for all these new schemes.  Yes, provisional should have a low bar, but there
should at least be an indication that each scheme being registered provides new identifiers.

For example, the +ws(s) identifiers appear to just be an alias of ws and wss.  Aliases are bad.
rr and rr+cloud are being defined as aliases = VERY BAD.  There is no reason to do that.

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.

Okay, it sounds like you have two identifiers: one for the service index and one for the node within that service.
Why don't you use two URIs: one for identifying the service index (defines the protocols necessary to get there)
and one for a single rr scheme that identifies the rr node ("/" being the index itself)?

Also, TLS implies TCP.  For most schemes, the bare name is TCP and {name}s is TLS.  So, rr and rrs, or
raconteur and raconteurs if you want to be more descriptive.  Using plain rr to indicate the WebRTC
transport is very odd.

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.

This just describes several access mechanism which will (after accessing) make use of rr identifiers.
You don't need new schemes for this.

 
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.

Likewise, not an identifier. You don't need an identifier for every local configuration option.

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.

Likewise, not an identifier.

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.

If this is consistent with WebRTC, then use webrtc's identifiers.

In other words, what you are defining here is an identifier space for rr nodes and then a
bunch of proxy mechanisms for obtaining access to those identified nodes.  We don't do that
by multiplying schemes!  We do it by sending two identifiers: one for the proxy and one for
the resource to access.  The proxy mechanisms already have defined identifier schemes.

....Roy


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

John Wason
Claiming that the different scheme types are simply "proxies" is inaccurate.  The different transport types have incredibly important performance and security implications that are best transmitted as a single piece of data.  Also, a single client can connect to different services using different transport types so there isn't really a single place that the "proxy" can be specified. The chances of a user getting a two piece connection command correct vs just changing a few letters in the URI are remote. The "click to connect" type usage would not work.  Because Robot Raconteur mostly runs on LAN the DNS system is not used for many connections.  Because of this the same URI with only the scheme changed can connect to different services. This means that the "proxy" specification would point to a different resource which is also not a correct usage of the "proxy" concept.

"For example, the +ws(s) identifiers appear to just be an alias of ws and wss."
 
No they aren't.  The protocol needs to be specified.  It is true that rr+ws etc. are compatible with WebSockets but it is just a stream wrapper.  The rr+ws is critically important to the software library to identify how to connect to the service.

 "rr and rr+cloud are being defined as aliases = VERY BAD.  There is no reason to do that."

Except that for users there may be cases where one is more clear than the other.

On 12/1/2015 4:12 PM, Roy T. Fielding wrote:
On Nov 20, 2015, at 8:20 PM, John Wason <[hidden email]> wrote:

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
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:
 
<a moz-do-not-send="true" href="rr+transport://hostname:port/path/to/endpoint?service=servicename&amp;nodename=targetnodename&amp;nodeid=targetnodeuuid" style="color: purple; text-decoration: underline;" class="">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:
 
<a moz-do-not-send="true" href="rr+tcp://192.168.2.3:48653/?nodeid=" style="color: purple; text-decoration: underline;" class="">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.

I still don't see what the purpose is for all these new schemes.  Yes, provisional should have a low bar, but there
should at least be an indication that each scheme being registered provides new identifiers.

For example, the +ws(s) identifiers appear to just be an alias of ws and wss.  Aliases are bad.
rr and rr+cloud are being defined as aliases = VERY BAD.  There is no reason to do that.

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.

Okay, it sounds like you have two identifiers: one for the service index and one for the node within that service.
Why don't you use two URIs: one for identifying the service index (defines the protocols necessary to get there)
and one for a single rr scheme that identifies the rr node ("/" being the index itself)?

Also, TLS implies TCP.  For most schemes, the bare name is TCP and {name}s is TLS.  So, rr and rrs, or
raconteur and raconteurs if you want to be more descriptive.  Using plain rr to indicate the WebRTC
transport is very odd.

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.

This just describes several access mechanism which will (after accessing) make use of rr identifiers.
You don't need new schemes for this.

 
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.

Likewise, not an identifier. You don't need an identifier for every local configuration option.

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.

Likewise, not an identifier.

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.

If this is consistent with WebRTC, then use webrtc's identifiers.

In other words, what you are defining here is an identifier space for rr nodes and then a
bunch of proxy mechanisms for obtaining access to those identified nodes.  We don't do that
by multiplying schemes!  We do it by sending two identifiers: one for the proxy and one for
the resource to access.  The proxy mechanisms already have defined identifier schemes.

....Roy



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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

Roy T. Fielding
> On Dec 1, 2015, at 2:31 PM, John Wason <[hidden email]> wrote:
>
> Claiming that the different scheme types are simply "proxies" is inaccurate.  The different transport types have incredibly important performance and security implications that are best transmitted as a single piece of data.  Also, a single client can connect to different services using different transport types so there isn't really a single place that the "proxy" can be specified. The chances of a user getting a two piece connection command correct vs just changing a few letters in the URI are remote. The "click to connect" type usage would not work.  Because Robot Raconteur mostly runs on LAN the DNS system is not used for many connections.  Because of this the same URI with only the scheme changed can connect to different services. This means that the "proxy" specification would point to a different resource which is also not a correct usage of the "proxy" concept.

I meant that the software is relying on an intermediary/broker in the form of your
service that is being discovered via UDP (or directed to via some other configuration)
in the form of a two-piece connection command, which your own description uses to
construct a single-piece URI.  I am saying you can keep them separate and avoid
registering so many schemes.

This does not imply all your services go through a single proxy.  It just means
there is an obvious two-step being performed similar to how HTTP uses proxies:
1) connect to some arbitrary connection-based transport service;
2) use raconteur on that service.

How you get to that intermediary is obviously important and can be specified with
one URI.  Everything else in your description involves queries to that intermediary
after the connection has been established.  That's why you can have one URI that
identifies the service and another URI that is specific to Robot Raconteur.
Your software already knows it is using RR. You don't need a separate identifier
scheme to tell you that the purpose of the connection is RR.

NOTHING in your description indicates that these two different purposes need to
be combined into a single identifier field.  If we are talking about an information
service with hypertext-style interactions using existing formats (like HTML),
then we would need a single identifier because we intend to include the links
as resource references.  If we are talking about a browser plug-in that relies on
the scheme name to be activated, then one of the schemes needs to be specific to
RR (but it really doesn't matter which one).

> "For example, the +ws(s) identifiers appear to just be an alias of ws and wss."
>  
> No they aren't.  The protocol needs to be specified.  It is true that rr+ws etc. are compatible with WebSockets but it is just a stream wrapper.  The rr+ws is critically important to the software library to identify how to connect to the service.

ws is just a stream wrapper. What you do inside that wrapper is not in the URI
because it is intentionally non-standard and already known to both client and
server.

>  "rr and rr+cloud are being defined as aliases = VERY BAD.  There is no reason to do that."
>
> Except that for users there may be cases where one is more clear than the other.

That is not a reason to alias an entire space of identifiers.

....Roy

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

John Wason
How is what I am requesting any different than the RTSP protocol:

rtsp - Real Time Streaming Protocol
rtsps - Real Time Streaming Protocol over TLS
rtspu - Real Time Streaming Protocol over UDP

or the various iris protocols:

iris
iris.beep
iris.lwz
iris.xpc
iris.xpcs

or the example I used earlier:

svn - subversion
svn+ssh - subversion over ssh

or xmlprc

xmlprc.beep
xmlrcp.beeps


The format I am requesting is in common use to specify the transport
information. I am using "+" because the newer standard says not to use
dots without a DNS registration.


On 12/1/2015 7:28 PM, Roy T. Fielding wrote:

>> On Dec 1, 2015, at 2:31 PM, John Wason <[hidden email]> wrote:
>>
>> Claiming that the different scheme types are simply "proxies" is inaccurate.  The different transport types have incredibly important performance and security implications that are best transmitted as a single piece of data.  Also, a single client can connect to different services using different transport types so there isn't really a single place that the "proxy" can be specified. The chances of a user getting a two piece connection command correct vs just changing a few letters in the URI are remote. The "click to connect" type usage would not work.  Because Robot Raconteur mostly runs on LAN the DNS system is not used for many connections.  Because of this the same URI with only the scheme changed can connect to different services. This means that the "proxy" specification would point to a different resource which is also not a correct usage of the "proxy" concept.
> I meant that the software is relying on an intermediary/broker in the form of your
> service that is being discovered via UDP (or directed to via some other configuration)
> in the form of a two-piece connection command, which your own description uses to
> construct a single-piece URI.  I am saying you can keep them separate and avoid
> registering so many schemes.
>
> This does not imply all your services go through a single proxy.  It just means
> there is an obvious two-step being performed similar to how HTTP uses proxies:
> 1) connect to some arbitrary connection-based transport service;
> 2) use raconteur on that service.
>
> How you get to that intermediary is obviously important and can be specified with
> one URI.  Everything else in your description involves queries to that intermediary
> after the connection has been established.  That's why you can have one URI that
> identifies the service and another URI that is specific to Robot Raconteur.
> Your software already knows it is using RR. You don't need a separate identifier
> scheme to tell you that the purpose of the connection is RR.
>
> NOTHING in your description indicates that these two different purposes need to
> be combined into a single identifier field.  If we are talking about an information
> service with hypertext-style interactions using existing formats (like HTML),
> then we would need a single identifier because we intend to include the links
> as resource references.  If we are talking about a browser plug-in that relies on
> the scheme name to be activated, then one of the schemes needs to be specific to
> RR (but it really doesn't matter which one).
>
>> "For example, the +ws(s) identifiers appear to just be an alias of ws and wss."
>>  
>> No they aren't.  The protocol needs to be specified.  It is true that rr+ws etc. are compatible with WebSockets but it is just a stream wrapper.  The rr+ws is critically important to the software library to identify how to connect to the service.
> ws is just a stream wrapper. What you do inside that wrapper is not in the URI
> because it is intentionally non-standard and already known to both client and
> server.
>
>>   "rr and rr+cloud are being defined as aliases = VERY BAD.  There is no reason to do that."
>>
>> Except that for users there may be cases where one is more clear than the other.
> That is not a reason to alias an entire space of identifiers.
>
> ....Roy
>


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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: URI scheme registration request

David_Warden
While you are correct that there are a number of schemes with compound names, my sense is that if their authors came to this list for advice today they might well be advised to consolidate their scheme. A lot of what is listed is just documenting legacy practices.

For example, rather than have a separate git+ssh scheme, git clients accept ssh URIs. If I were implementing a protocol that optionally accepted TLS, I might activate it automatically if I receive a STARTTLS command (as configured by the client or server) rather than use a separate scheme.

That isn't to say your proposal is unreasonable, just that it might benefit from what others have learned from past schemes on how to simplify things.

-----Original Message-----
From: Uri-review [mailto:[hidden email]] On Behalf Of John Wason
Sent: Tuesday, December 1, 2015 7:10 PM
To: Roy T. Fielding
Cc: [hidden email]
Subject: Re: [Uri-review] URI scheme registration request

How is what I am requesting any different than the RTSP protocol:

rtsp - Real Time Streaming Protocol
rtsps - Real Time Streaming Protocol over TLS rtspu - Real Time Streaming Protocol over UDP

or the various iris protocols:

iris
iris.beep
iris.lwz
iris.xpc
iris.xpcs

or the example I used earlier:

svn - subversion
svn+ssh - subversion over ssh

or xmlprc

xmlprc.beep
xmlrcp.beeps


The format I am requesting is in common use to specify the transport information. I am using "+" because the newer standard says not to use dots without a DNS registration.


On 12/1/2015 7:28 PM, Roy T. Fielding wrote:

>> On Dec 1, 2015, at 2:31 PM, John Wason <[hidden email]> wrote:
>>
>> Claiming that the different scheme types are simply "proxies" is inaccurate.  The different transport types have incredibly important performance and security implications that are best transmitted as a single piece of data.  Also, a single client can connect to different services using different transport types so there isn't really a single place that the "proxy" can be specified. The chances of a user getting a two piece connection command correct vs just changing a few letters in the URI are remote. The "click to connect" type usage would not work.  Because Robot Raconteur mostly runs on LAN the DNS system is not used for many connections.  Because of this the same URI with only the scheme changed can connect to different services. This means that the "proxy" specification would point to a different resource which is also not a correct usage of the "proxy" concept.
> I meant that the software is relying on an intermediary/broker in the
> form of your service that is being discovered via UDP (or directed to
> via some other configuration) in the form of a two-piece connection
> command, which your own description uses to construct a single-piece
> URI.  I am saying you can keep them separate and avoid registering so many schemes.
>
> This does not imply all your services go through a single proxy.  It
> just means there is an obvious two-step being performed similar to how HTTP uses proxies:
> 1) connect to some arbitrary connection-based transport service;
> 2) use raconteur on that service.
>
> How you get to that intermediary is obviously important and can be
> specified with one URI.  Everything else in your description involves
> queries to that intermediary after the connection has been
> established.  That's why you can have one URI that identifies the service and another URI that is specific to Robot Raconteur.
> Your software already knows it is using RR. You don't need a separate
> identifier scheme to tell you that the purpose of the connection is RR.
>
> NOTHING in your description indicates that these two different
> purposes need to be combined into a single identifier field.  If we
> are talking about an information service with hypertext-style
> interactions using existing formats (like HTML), then we would need a
> single identifier because we intend to include the links as resource
> references.  If we are talking about a browser plug-in that relies on
> the scheme name to be activated, then one of the schemes needs to be specific to RR (but it really doesn't matter which one).
>
>> "For example, the +ws(s) identifiers appear to just be an alias of ws and wss."
>>  
>> No they aren't.  The protocol needs to be specified.  It is true that rr+ws etc. are compatible with WebSockets but it is just a stream wrapper.  The rr+ws is critically important to the software library to identify how to connect to the service.
> ws is just a stream wrapper. What you do inside that wrapper is not in
> the URI because it is intentionally non-standard and already known to
> both client and server.
>
>>   "rr and rr+cloud are being defined as aliases = VERY BAD.  There is no reason to do that."
>>
>> Except that for users there may be cases where one is more clear than the other.
> That is not a reason to alias an entire space of identifiers.
>
> ....Roy
>


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

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
12