Re: [Uri-review] URI scheme registration request

[John Wason <[e-mail]>]

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 <[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
>


-- 
John Wason, Ph.D.
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
[phone]
[e-mail]