RE: [Uri-review] ssh URI

On Mon, 2009-10-12 at 21:35 +0200, Kristof Zelechovski wrote:
> David, you do not see a need to define a new URI scheme for anything, do
> you?.  If I you do, please enumerate the requirements for a protocol that
> would save it from the http black hole.

You are correct that I see very little need for new URI schemes.  Nearly
all of what would be done by defining a new URI scheme can be done
(better, IMO) by leveraging http URIs.  

However, there *are* some inherent differences that I see between using
a new URI scheme and using http URIs, as described in
http://dbooth.org/2006/urn2http/#differences
[[
 * URI Length.  HTTP URIs will generally be longer.
 * Governing Authority.  New URI schemes must be registered with IANA,
whereas specialized HTTP prefixes may be defined by any URI owner.  This
may be a concern, both because IANA may be perceived as being more
reputable than other organizations, and because IANA provides a single
place to look for scheme definitions.  However, if this concern is
important enough, a registry of specialized HTTP prefixes could be
created by a reputable organization -- potentially even IANA.
 * Expectations.  Users discovering an xyzscheme URI expect it to be
governed by a separate specification, whereas users discovering an HTTP
URI with a specialized prefix may not realize that there is a separate
specification governing it (over and above the http scheme
specification).  This can be mitigated by educating users, and one good
way to do so is to serve useful metadata (indirectly) via the URI, as
described above.
]]

I *do* think that these differences provide reasonable grounds for new
schemes in some cases.  But I think proposers of new URI schemes far too
often fail to adequately explore the possibilities (and bootstrapping
benefits) of using http URIs and, in some cases, HTTP protocol
extensions.  I think there is a strong tendency to assume (erroneously)
that http URIs are limited to the HTTP protocol and thus dismiss them.
This has been quite evident in past discussions about proposed new
schemes.

I don't think I could enumerate all of the considerations important in
deciding whether a new URI scheme is justified, but I do think it would
be appropriate to play out the scenario both ways and compare the
results.  

For example, suppose an HTTP URI prefix were defined, such as
"http://sshuri.org?" (and as of this writing, that domain is available,
BTW).  And suppose that site were set up such that dereferencing one of
those URIs in a browser redirected to a page containing:

 - A brief explanation of SSH URIs, and pointers to tutorials and
specifications.

 - Downloadable software that would cause the browser to recognize such
URIs in the future, and handle them appropriately (i.e., by opening a
secure shell, rather than by fetching a page from sshuri.org).
Furthermore, such software might even be programmed to recognize and
handle the "ssh:" URI scheme as well.

How quickly would user clients implement SSH URIs this way versus if a
new scheme (only) had been used?

Basically, instead of *guessing* that the market would accept and
implement SSH URIs (through a new URI scheme), the HTTP URI approach
would provide a means to demonstrate that the market *had* accepted and
implemented support for SSH URIs.

> SSH is not a new protocol, and the "adoption rate" does not depend on the
> URI; it is an agreement between the owner and the user that counts.  This
> agreement already provides all technical information the user needs, and
> explaining it over HTTP would not be useful.

I was referring to the adoption rate for clients (such as browsers)
recognizing these new SSH URIs and using them for their intended
purpose.  A browser encountering a URI beginning "ssh:..." will not be
able to do anything useful with it until it knows the special semantics
assigned to the "ssh:" prefix.  But a browser encountering a URI
beginning "https://sshuri.org/..." could try to dereference that URI and
could be led to software that, once installed, *would* know to open an
SSH connection when encountering such a URI.  This could dramatically
improve the rate at which browsers learn how to handle these SSH URIs.
Make sense?

> And how would you persuade the Web browser to send an HTTP SSH URI to an
> external handler instead of navigating to it?  (Think Internet Explorer, for
> clarity.)

The same way you would persuade it to launch an SSH connection when an
"ssh:" URI is encountered: the browser needs to know about the semantics
associated with that URI prefix.

David Booth


> Chris
> 
> -----Original Message-----
> From: uri-review-bounces@ietf.org [mailto:uri-review-bounces@ietf.org] On
> Behalf Of David Booth
> Sent: Monday, October 12, 2009 7:02 PM
> To: Steve Suehring
> Cc: uri-review@ietf.org; uri@w3.org
> Subject: Re: [Uri-review] ssh URI
> 
> I don't see a need to define a new URI scheme for this.  You can just
> define an http URI prefix for this purpose, as described in
> http://dbooth.org/2006/urn2http/
> 
> Furthermore, as Graham Klyne suggested during a similar discussion
> earlier, "an HTTP URI can also retrieve a protocol [handler]
> implementation"
> http://lists.w3.org/Archives/Public/uri/2009Sep/0029.html
> This could dramatically improve the adoption rate of a new protocol.
> 
> David Booth
> 
> 
> 
> 
> 
-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Received on Tuesday, 13 October 2009 00:53:09 UTC