Re: [Uri-review] URI scheme registration request

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:uri-review-bounces@ietf.org] On Behalf Of John Wason
Sent: Tuesday, December 1, 2015 7:10 PM
To: Roy T. Fielding
Cc: uri-review@ietf.org
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 <wason@wasontech.com> 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
wason@wasontech.com

_______________________________________________
Uri-review mailing list
Uri-review@ietf.org
https://www.ietf.org/mailman/listinfo/uri-review