Re: [Uri-review] URI scheme registration request

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

> On Dec 1, 2015, at 2:31 PM, John Wason <[e-mail]> 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