Nabble - w3.org - uri

Re: how browsers transform URLs

2009-11-26T00:52:58Z

Erik van der Poel wrote:
> I'm not sure what you mean by "I was surprised that IE simply ignores
> a lone "%" and that it passes through control characters in query
> strings." Are you talking about a lone % in the path part of the URL?
> (In the query part, most of the browsers simply allow a lone %.)

Right... I originally had "in the path" after "lone '%'" :)

Re: how browsers transform URLs

2009-11-25T22:28:52Z

Mike,

Thanks for the email. You're absolutely right that the recommendations
document is missing detailed steps regarding (base + relative ->
absolute). We definitely need to do more tests with the JavaScript
interfaces (this.href, this.getAttribute('href' [, n])) since
Microsoft's documentation on getAttribute mentions absolute and
relative URLs. Until now, most of our testing has been focussed on the
DNS and HTTP packets rather than the JavaScript calls. Also, we don't
have any relative URL tests yet (though I have already found that the
browsers handle the <base> tag with a relative URL inside it
differently).

I'm not sure what you mean by "I was surprised that IE simply ignores
a lone "%" and that it passes through control characters in query
strings." Are you talking about a lone % in the path part of the URL?
(In the query part, most of the browsers simply allow a lone %.)

If you are talking about a lone % in the path part, I have to admit
that I am also surprised about IE's behavior. (What was their reason
for rejecting such URLs?)

Erik

On Wed, Nov 25, 2009 at 5:44 PM, Mike Brown <mike@...> wrote:

> Erik van der Poel wrote:
>> We are happy to announce the open source release of Client URL
>> Internet Emission Sniffer (CURLIES).
>
> Interesting project. Just a couple of cursory observations:
>
> In the recommendations for brower developers, section 6 assumes the URL in the
> href or whatever is absolute. It's really a URI reference, and may relative.
> In that situation, it's relative to the HTML document's URI, which is usually
> found external to the document but can be set elsewhere; see RFC 3986 section
> 5. Regardless of whether it's relative or absolute, there's a procedure for
> converting it to an absolute one (one definition of 'resolution'), and this
> needs to be accounted for in your procedures. For example, it seems some
> cleanup of poorly written URI references (whitespace & bad characters) needs
> to be done, then the resolving to absolute form needs to happen, and only then
> can you start identifying and processing the URI's discrete components (host,
> path, params, whatever).
>
> Anyway, the ASCII test results for path and query were interesting. I'm not
> surprised that "%00" and \x00 were funky, and although it wasn't what I
> expected, I can understand why "\" would be converted to "/" by most browsers
> (except in Firefox, where it's "%5C"). I was surprised that IE simply ignores
> a lone "%" and that it passes through control characters in query strings.
>
> I'm looking forward to seeing what evolves in the "Handle the Rest" section of
> the recommendations :)
>
> Mike
>

Re: how browsers transform URLs

2009-11-25T17:44:58Z

Erik van der Poel wrote:
> We are happy to announce the open source release of Client URL
> Internet Emission Sniffer (CURLIES).

Interesting project. Just a couple of cursory observations:

In the recommendations for brower developers, section 6 assumes the URL in the
href or whatever is absolute. It's really a URI reference, and may relative.
In that situation, it's relative to the HTML document's URI, which is usually
found external to the document but can be set elsewhere; see RFC 3986 section
5. Regardless of whether it's relative or absolute, there's a procedure for
converting it to an absolute one (one definition of 'resolution'), and this
needs to be accounted for in your procedures. For example, it seems some
cleanup of poorly written URI references (whitespace & bad characters) needs
to be done, then the resolving to absolute form needs to happen, and only then
can you start identifying and processing the URI's discrete components (host,
path, params, whatever).

Anyway, the ASCII test results for path and query were interesting. I'm not
surprised that "%00" and \x00 were funky, and although it wasn't what I
expected, I can understand why "\" would be converted to "/" by most browsers
(except in Firefox, where it's "%5C"). I was surprised that IE simply ignores
a lone "%" and that it passes through control characters in query strings.

I'm looking forward to seeing what evolves in the "Handle the Rest" section of
the recommendations :)

Mike

how browsers transform URLs

2009-11-25T11:49:36Z

We are happy to announce the open source release of Client URL
Internet Emission Sniffer (CURLIES).

The purpose of this project is to see how browsers and other Web
clients transform URLs as they access them. This is done by generating
a number of test cases and having each client load the test files
while running a packet sniffer to capture the network emissions.
Reports are then generated from the sniffed packets, highlighting
differences between the clients. For further details and test results,
see the project site:

http://code.google.com/p/curlies/
http://code.google.com/p/curlies/wiki/DesignDocumentForClientURLInternetEmissionSniffer

I have also written some recommendations for browser developers. While
the HTML5 Web Addresses spec already describes how to parse and
resolve a URL, I have taken this a step further to include the DOM
interfaces that can be used to obtain IRIs, URIs and Unicode host
names.

http://code.google.com/p/curlies/wiki/RecommendationsForBrowserDevelopers
http://www.w3.org/html/wg/href/draft

Happy Thanksgiving!

Erik

PS Many thanks to Shaopeng Jia (Google), who did most of the actual work.

URI Template: query param name different than variable name

2009-11-11T06:06:21Z

I expect one of the most common use cases for URI templates will be building query parameters using variable names defined by some specification. For instance, OpenSearch defines variables such as 'searchTerms', 'count', 'startPage', 'language', 'inputEncoding'. Many web sites will want to use different query parameter names to carry the values of these variables. For instance, 'q' for 'searchTerms', 'page' for 'startPage', 'lang' for 'language' etc. This cannot be done well with the current working draft.

The working draft says [in 2.5 Variables]:

"The variable names serve multiple purposes: documentation for what kinds of values are expected, identifiers for associating values within a URI Template processor, and the string to use for each key on key=value substitutions."

I disagree with this restriction. A URI template should allow the template author to choose "the string to use for each key", independently of what another party has decided for the variable name (for documentation and as an identifier).

Of course a template author can write "?q={searchTerms}&p={startPage}". However, the URI Template spec has a '?' operator to do better than this -- allowing the whole "&p=" part to be omitted when no 'startPage' is defined, for instance.

I suggest changing the '?' operator to have a form like "{?name=[var]}".

If 'var' is omitted (the template is "{?name=}") then (as with the current draft) 'name' is used as both the variable name and the query parameter name.

'=' is currently used to introduce a default value: {[op]var[=default]}. However, you don't need to use an operator and a default together. For instance, in the current syntax "{?startPage=1}" can be written as "?startPage={startPage=1} -- there is always a value (from the variable or the default) so the operator-related parts will always be present so they can be 'literals' outside the { } brackets.

Please also require a template processor to be smart about a '?' operator: substituting '?...' if it is the first query param (no previous '?' in the URI being built), or substituting '&...' otherwise.

If this {?name=[var]} proposal is accepted it might be worth making some other changes to keep the syntax consistent. Below is one idea:

{[op [name=]] [vartype] varname [modifier] [| default]}

* add a ',' operator, instead of supporting a variable-list in each {...} expression

* 'default' is a default for the whole expression, not just the variable value excluding modifiers

* use 'name' as the variable name if 'varname' is an empty string

James Manger

Re: URI Template: expanding lists

2009-11-06T11:29:30Z

On Nov 5, 2009, at 10:52 PM, Bob Aman wrote:

>> [Comment on the URI Template working draft]
>>
>> Is there any particular reason why the current draft suggests that
>> variables typed as lists (marked with @) be expanded so that the
>> variable name is followed by a generated numbering?
>>
>> The numbering scheme seems quite odd and specific (1-based with first
>> item unnumbered).
>>
>> For example, in the case of the ? operator:
>>
>> {?@list} ?list=val1&list2=val2&list3=val3
>>
>> Why not simply expand it as:
>>
>> ?list=val1&list=val2&list=val3
>>
>> This would still be a perfectly valid sequence of query parameters.
>> Or am I missing something obvious?
>
> I think the obvious objection is that many web frameworks (php, rails,
> app engine, etc) make the assumption that query parameter keys are
> unique, so method calls like `request.params["list"]` would probably
> return `val3` with no means of obtaining the array order or other
> values in the array without parsing the request URI manually. That
> said, I don't think the obvious objection is a good reason to choose
> what strikes me as the slightly less elegant option, and I would much
> prefer your expansion to the current one. URI templates aren't
> necessary to the function of every web application, frameworks can
> slowly adapt, and in the meantime, manually parsing the URI when
> necessary is fine with me.

Yes, it matches the obvious limitation in HTML and all of the
libraries that pre-parse query parameters into hash tables.
The names must be unique. More importantly, something like

form.cgi{?name,@address}

is such a common idiom that I figured it was worth capturing
in a short form. Almost all examples I've seen using that
kind of form use address, address2, address3 as the names.

However, I don't think this is a necessary feature for
uri-templates, so we could just remove it if folks disagree.

....Roy

Re: URI Template: expanding lists

2009-11-05T22:52:37Z

> [Comment on the URI Template working draft]
>
> Is there any particular reason why the current draft suggests that
> variables typed as lists (marked with @) be expanded so that the
> variable name is followed by a generated numbering?
>
> The numbering scheme seems quite odd and specific (1-based with first
> item unnumbered).
>
> For example, in the case of the ? operator:
>
> {?@list} ?list=val1&list2=val2&list3=val3
>
> Why not simply expand it as:
>
> ?list=val1&list=val2&list=val3
>
> This would still be a perfectly valid sequence of query parameters.
> Or am I missing something obvious?

I think the obvious objection is that many web frameworks (php, rails,
app engine, etc) make the assumption that query parameter keys are
unique, so method calls like `request.params["list"]` would probably
return `val3` with no means of obtaining the array order or other
values in the array without parsing the request URI manually. That
said, I don't think the obvious objection is a good reason to choose
what strikes me as the slightly less elegant option, and I would much
prefer your expansion to the current one. URI templates aren't
necessary to the function of every web application, frameworks can
slowly adapt, and in the meantime, manually parsing the URI when
necessary is fine with me.

-Bob Aman

URI Template: expanding lists

2009-11-05T22:02:06Z

[Comment on the URI Template working draft]

Is there any particular reason why the current draft suggests that
variables typed as lists (marked with @) be expanded so that the
variable name is followed by a generated numbering?

The numbering scheme seems quite odd and specific (1-based with first
item unnumbered).

For example, in the case of the ? operator:

{?@list} ?list=val1&list2=val2&list3=val3

Why not simply expand it as:

?list=val1&list=val2&list=val3

This would still be a perfectly valid sequence of query parameters.
Or am I missing something obvious?

Christophe-

URI template: %-escaping and ASCII templates

2009-11-03T05:46:29Z

[Comments on the current URI Template working draft.]

1. It would be helpful if URI Templates (like URIs) can be written in ASCII so they can be used in similar places to URIs (eg a Link-Template: <template>... HTTP header, similar to the Link: <uri>... HTTP header).

2. Templates should support (almost) all of unicode for variable names.

The current draft offers #2, but not #1. I think we can have both.

The current draft is really an "IRI Template" as 'literals' in a template can use almost any Unicode characters and 'pct-encoded' sequences. Variable names can use almost any Unicode characters -- but NOT 'pct-encoded' sequences.

Consequently, while an IRI can be converted to an ASCII URI (and still be a valid IRI), a template cannot be converted to an ASCII form.

I suggest allowing 'pct-encoded' sequences in 'varname'. These would be decoded before using the resultant variable name to lookup the variable value.

The 'vartype' used to indicate when the variable is an associative array would have to be changed from '%' to another special character.

The definitions become:

varspec = [ vartype ] varname [ modifier ] [ "=" default ]

vartype = "@" / something other than "%"

varname = 1*( varchar / pct-encoded )

varchar = ALPHA / DIGIT / "." / "_" / ucschar / iprivate

Then if you need to put a URI Template into an ASCII protocol, you can %-escape any non-ASCII chars in literals and variable names -- it will still be a valid URI Template.

P.S. I would avoid using '%' for anything other than %-escapes to minimise potential human confusion -- even if it is technically unambiguous.

James Manger

Re: URI template: substring for dates

2009-11-02T15:45:48Z

I agree that dates are much more common in URIs than times. Defining 3
variables for each date field is not as bad as half-a-dozen, but it is
still annoying: some specs will define pubYear, pubMonth, pubDay;
others will define pub=yyyy-mm-dd. HTML5, for instance, might make it
convenient to get a date into a single variable (eg <input
type="date">), but a prefix/suffix template syntax will not be able to
pick out the month.

I don't think you can say a prefix/suffix is qualitatively different
than a substring in being ignorant of variable semantics. The prefix/
suffix syntax can indicate a beginning or ending point from either end
of a value. The substring syntax just lets you indicate both. In all
cases a value can be too small for the offsets so you get less than
expected, or an empty string.

{var:end} and {var^begin} vs {var[begin,end]}

It is a minor difference; offering a little more functionality &
flexibility; with a slightly more familiar syntax.

P.S. The syntax could be {var:begin,end} to support substring
functionality while looking slightly less like a programming language.

P.S. Is there any reason to assume hash-based storage will only ever
use 2 layers? Why not 3?
/{hash[,4]}/{hash[4,8]/{hash[8,]}

James Manger

Re: URI template: substring for dates

2009-11-02T14:06:02Z

Continuous variables (time, but also space) are probably unsuitable for URI Templates for the reasons mentioned by Mr. Fielding.

The last identifying term does not identify a point in time, but rather a sly duration. To identify geographic regions by the barycentric coordinate (e.g. the latitude and longitude of City Hall) has the same problem. I figured out a fix for the geography problem <http://www.rustprivacy.org/primeencoding.zip>, but the time problem will be forever intractable - the left-most term will have to be truncated in order to sort.

The "hash mark" separates the digital from the analog ...

/World/France/Paris (Region)/Paris#AndEverythingThere
/World/UnitedStates/Texas/Paris/MainStreet#AndEverythingThere

Just my 2 cents ...

--Gannon

--- On Mon, 11/2/09, Roy T. Fielding <fielding@...> wrote:

> From: Roy T. Fielding <fielding@...>
> Subject: Re: URI template: substring for dates
> To: "James Manger" <James@...>
> Cc: uri@...
> Date: Monday, November 2, 2009, 1:01 PM
> On Nov 2, 2009, at 4:40 AM, James
> Manger wrote:
>
> > [Comments on the URI Template working draft]
> >
> > Constructing a URI with a substring of a user-provided
> variable value sounds useful. The current working draft has
> a dictionary site as an example (/dictionary/{term:1}/{term}
> produces /dictionary/c/cat), and mentions hash-based
> storage.
> >
> > Another important example is dates. Many, many URI
> designs incorporate dates, in quite a variety of ways (just
> year, year/month/day, XML-style timestamp...) -- which
> sounds like a perfect situation to use a URI template.
>
> Well, not really. It is fairly common for URI layouts
> to incorporate
> some portion of a date value, such as the year and/or month
> of publication.
> Those are simple variable substitutions like:
>
> /post/{year}{month}/{title}
>
> I have never seen a resource layout incorporate the current
> time.
>
> In other words, there is no need for the template syntax to
> be aware
> of date fields because (in this case) it is simpler for the
> variable
> values to be limited as such. String prefix/suffix
> makes sense because
> they are ignorant of variable semantics no matter what the
> values
> might be. Using substrings to extract fields from a
> date value
> means that we know it is a date value, and thus we can use
> a more
> specific value definition like {seconds} without changing
> the syntax.
>
> Thanks for the detailed proposal. I think it would
> make sense if
> we were trying to act like a programming language in the
> template,
> but we are really trying hard to avoid that.
>
> ....Roy
>
>
>

Re: URI template: substring for dates

2009-11-02T11:01:43Z

On Nov 2, 2009, at 4:40 AM, James Manger wrote:

> [Comments on the URI Template working draft]
>
> Constructing a URI with a substring of a user-provided variable
> value sounds useful. The current working draft has a dictionary site
> as an example (/dictionary/{term:1}/{term} produces /dictionary/c/
> cat), and mentions hash-based storage.
>
> Another important example is dates. Many, many URI designs
> incorporate dates, in quite a variety of ways (just year, year/month/
> day, XML-style timestamp...) -- which sounds like a perfect
> situation to use a URI template.

Well, not really. It is fairly common for URI layouts to incorporate
some portion of a date value, such as the year and/or month of
publication.
Those are simple variable substitutions like:

/post/{year}{month}/{title}

I have never seen a resource layout incorporate the current time.

In other words, there is no need for the template syntax to be aware
of date fields because (in this case) it is simpler for the variable
values to be limited as such. String prefix/suffix makes sense because
they are ignorant of variable semantics no matter what the values
might be. Using substrings to extract fields from a date value
means that we know it is a date value, and thus we can use a more
specific value definition like {seconds} without changing the syntax.

Thanks for the detailed proposal. I think it would make sense if
we were trying to act like a programming language in the template,
but we are really trying hard to avoid that.

....Roy

URI template: substring for dates

2009-11-02T04:40:19Z

[Comments on the URI Template working draft]

Constructing a URI with a substring of a user-provided variable value sounds useful. The current working draft has a dictionary site as an example (/dictionary/{term:1}/{term} produces /dictionary/c/cat), and mentions hash-based storage.

Another important example is dates. Many, many URI designs incorporate dates, in quite a variety of ways (just year, year/month/day, XML-style timestamp...) -- which sounds like a perfect situation to use a URI template.

Ideally, a spec could define one variable to hold a date (eg 'published=2009-11-02T11:01:00Z'), then different sites can each have their own template to pick out the parts they need in the arrangement they want. The alternative is specs having to define, say, half-a-dozen variables to hold each component of each date, which is much less appealing (eg 'publishedYear=2009', 'publishedMonth=11', 'publishedDay=02', 'publishedHour=11', 'publishedMinute=01'...).

Picking a 2-digit month, for instance, from a date string to use as a path segment (quite a common occurrence in URIs) requires a substring function with start and end offsets, not just a prefix or suffix as the current syntax supports ({var:end} or {var^begin} respectively).

I suggest a slightly more flexible syntax:

{var[begin,end]}

A template for W3 standards might be:

/TR/{date[,4]}/REC-{title}-{date[,4]}{date[6,8]}{date[9,11]}

producing /TR/1998/REC-CSS2-19980512 when title is "CSS2" and date is "1998-05-12T00:00:00Z".

Both begin and end can take negative values to indicate offsets from the end of the value, instead of from the beginning (like the current draft).

Both begin and end can be optional, defaulting to the beginning and ending of the variable value respectively.

My gut feeling is that [begin,end] would be fairly easier for template authors to understand and remember.

I would be tempted to RECOMMEND that variables that are dates use the XML date format (yyyy-mm-ddThh:mm:ssZ) were possible, but perhaps it would be sufficient to include an example using this format.

Suggested replacement text:

1. Introduction

...

http://example.com/dictionary/{term[,1]}/{term}

2.4 Value Modifiers

A variable can have a modifier indicating that the substituted value is limited to a substring of the variable value. The primary use of these modifiers is to partition an identifier space hierarchically, as is often found in reference sites, date-based URIs and hash-based storage. They can also be used to indicate the maximum length of a given substitution.

  modifier      =  "[" [begin] "," [end] "]"
  begin         =  offset
  end           =  offset
  offset        =  [ "-" ] 1*DIGIT

If the variable is not typed, then each offset refers to a number of characters from either the beginning (0 or positive offset) or end (negative offset) of the variable's value (before any %-escaping). If the begin offset is omitted, the substring starts at the beginning of the value. If the end offset is omitted, the substring stops at the end of the value ("-0" SHALL NOT be used). The comma is never omitted. If the begin or end offset is beyond the variable's value (ie the absolute value of the offset is larger than the length of the variable's value) then the nearest end of the value is used. If the end offset is earlier in the string than the begin offset, an empty string is substituted.

If the variable is typed as a list, a modifier creates a sub-list. That is, the offsets refer to list elements, not characters.

If the variable is typed as an associative array, the offsets refer to tuples.

The following examples illustrate how modifiers work with the different variable types. More complex examples are provided in Section 5.

  Given the variable assignments:
    date  := "2009-10-31T22:55:13Z";
    name  := [ "Fred", "Wilma", "Pebbles" ];
    favs  := [ "color", "red", "volume", "high" ];

  Example Template     Expansion

    {date}             2009-10-31T22:55:13Z
    {date[,50]}        2009-10-31T22:55:13Z    {date[,4]}         2009
    {date[11,]}        22:55:13Z    {date[-1,]}        Z    {date[6,8]}        10
    x{date[15,-15]}y   xy
    {?name}            ?name=Fred,Wilma,Pebbles
    {?name[,1]}        ?name=F
    {?@name}           ?name=Fred&name=Wilma&name=Pebbles
    {?@name[,1]}       ?name=Fred
    {?@name[1,]}       ?name=Wilma&name=Pebbles
    
    {?favs}            ?favs=color,red,volume,high
    {?%favs}           ?color=red&volume=high
    {?%favs[,1]}       ?color=red
    {?%favs[1,]}       ?volume=high
    {?%favs[-1,]}      ?volume=high
    {?%favs[,-1]}      ?color=red

James Manger

"draft-wilde-sms-uri-20" available

2009-10-23T23:03:45Z

dear IESG.

with this email i would like to announce that the internet draft
entitled "URI Scheme for GSM Short Message Service" has just been
updated to version draft-wilde-sms-uri-20.

this new version of draft-wilde-sms-uri updates draft-wilde-sms-uri-19.
the text and html versions of the submitted draft can be found at the
following locations (and in the relevant IETF places):

http://dret.net/netdret/docs/draft-wilde-sms-uri-20.txt
http://dret.net/netdret/docs/draft-wilde-sms-uri-20.html

the draft's abstract reads:

This memo specifies the Uniform Resource Identifier (URI) scheme "sms"
for specifying one or more recipients for an SMS message. SMS messages
are two-way paging messages that can be sent from and received by a
mobile phone or a suitably equipped networked device.

thanks a lot and kind regards,

erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
dret@... - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)

RE: '#' in mailto URIs

2009-10-14T10:31:09Z

What about encouraging URI/IRI scheme registrations to
say about whether fragment identifiers are necessary,
important, useful, allowed.

mailto: could then disallow # fragment identifiers.

Larry

-----Original Message-----
From: "Martin J. Dürst" [mailto:duerst@...]
Sent: Tuesday, October 13, 2009 9:37 PM
To: Michael A. Puls II
Cc: Larry Masinter; jwz@...
Subject: Re: '#' in mailto URIs

This is some very old mail. The current mailto: draft doesn't contain
anything about fragment identifiers. Should it?

The text that I might put in (if we think we need some) is:

>>>>
Note that this specification, like any URI scheme specification, does
not define syntax or meaning of a fragment identifier, because these
depend on the media type of the retrieved resource. In the currently
known usage scenarios, a 'mailto' URI does not serve to retreive a
resource with a media type. Therefore, fragment identifiers are
meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored
upon resolution.
>>>>

Regards, Martin.

On 2008/04/02 6:32, Michael A. Puls II wrote:

>
> 
> On Tue, 01 Apr 2008 13:18:27 -0400, Larry Masinter <LMM@...> wrote:
>
>>> So, it sounds like, in short, you're saying that Safari and Firefox
>>> shouldn't use # that way because it's reserved for future use in mailto
>>> URIs.
>>>
>>> Perhaps you could explicitly note that in your next draft?
>>
>> It isn't reserved "for future use", it's just not allowed.
>
> Martin said that # is *always* a fragment identifier. If it's not
> allowed, ever, then you're saying that mailto URIs don't support
> fragment identifiers and won't ever support fragment identifiers because
> # is not allowed. (Which would make sense to me)
>
> If that's true, then a raw # that is found in a mailto URI (even though
> it's not allowed) would not be anything special and could just be
> accepted literally (if you were not going to throw an error).
>
> That would make sense to me.
>
> However, if mailto URIs support fragment identifiers or might support
> fragment identiers in the future, then # and everything after it in the
> URI needs to be ignored (at least by the mail client itself when parsing
> and filling in the compose fields).
>
> What I got from Martin's response is that mailto URIs (like http URIs)
> support fragment identifiers. It's just that no client *currently* makes
> use of them in any way for 'mailto'.
>
> Basically, I just need to be sure what to do with a raw # in a mailto
> URI (even if it's an error).
>
>> Not every possible string has to have an interpretation.
>
> I don't know what you mean by that sentence or what it pertains to.
> Please clarify.
>
> Thanks
>

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...

Re: ssh URI

2009-10-14T07:36:08Z

On Fri, Oct 9, 2009 at 9:01 AM, Steve Suehring <suehring@...> wrote:
>
> Hello,
>
> Attached is a draft to be submitted to the IETF for URI scheme related
> to secure shell (ssh). The draft was originally included in the secsh
> Working Group which has since concluded.
> ...

>
> Please provide feedback as appropriate.

What does SFTP support GET and not PUT?

Is the syntax/protocol of directory listings standardized elsewhere?

What happens if I open a directory without the correct typecode? My
potentially naive impression is that the whole typecode thing adds
more complexity than value: it is easy to pipe the output into a tool
that does the right newline conversions.

What happen to scp URLs?

The assertion that the ssh URI scheme is designed to invoke an
interactive terminal session strikes me as expressing a user interface
decision, which URI schemes typically do not.

I would reword it this way:

The intended usage of the SSH URI is to declare the existence of an
SSH listener. This information could be used (for example) by a web
user agent to invoke an interactive SSH terminal program, or as input
to a script that would automate some action on the remote host."

It would be nice if a server could configure a list of "safe commands"
that it would accept as parameters. A future curl might allow this:

curl ssh://user@...?uptime > remote_uptime.txt
curl ssh://user@...?ifconfig > remote_config.txt

The server config might be as simple as a list of commands that are
whitelisted for use this way.

Paul Prescod

Re: [Uri-review] ssh URI

2009-10-14T05:49:28Z

On Wed, Oct 14, 2009 at 12:21:56AM -0400, David Booth wrote:
> - I actually think an ssh: scheme is one of the most justifiable
> proposals for a new scheme that I have seen lately, because ssh already
> has widespread adoption, and I would not be at all upset to see it go
> through. In the long run it would be convenient. But the ability to
> serve useful information and software as a fallback for clients that do
> not recognize SSH URIs is an undeniable benefit of http URIs, and I do
> not think any proposal for a new scheme should be considered complete
> without serious consideration of these potential benefits.

David,

Thank you for your input on the http prefix for the ssh uri. I think
the general consensus and what I'm reading from your message indicates
that we'll continue to move forward with the ssh draft as-is, opting for
a new uri scheme as you indicate.

We have some revisions to make to the draft itself based on feedback
here about the location of the fingerprint and feedback from from the
ssh working group mailing list. When we get that revisions settled
we'll submit it back to these mailing lists for a final walkthrough.

Thanks everyone for their input.

Steve

Re: [Uri-review] ssh URI

2009-10-13T21:21:56Z

Some comments:

- Until there are clear criteria for deciding when a new URI scheme
should be used, these discussions will be unavoidable and necessary.

- It is quite clear from these discussions that the possibilities and
benefits available through piggybacking on http URIs are not well
understood by many of those who have been proposing new URI schemes.
The confusion that has been expressed when the idea has been proffered
clearly illustrates this.

- There is an existing W3C TAG issue related to this, though not
specifically about criteria for registering new URI schemes:
[[
HTTPSubstrate-16: Should HTTP be used as a substrate protocol? Does W3C
agree with RFC 3205?
http://www.w3.org/2001/tag/issues.html#HTTPSubstrate-16
]]

- I actually think an ssh: scheme is one of the most justifiable
proposals for a new scheme that I have seen lately, because ssh already
has widespread adoption, and I would not be at all upset to see it go
through. In the long run it would be convenient. But the ability to
serve useful information and software as a fallback for clients that do
not recognize SSH URIs is an undeniable benefit of http URIs, and I do
not think any proposal for a new scheme should be considered complete
without serious consideration of these potential benefits.

- BTW, http URI prefixes and new schemes do not need to be mutually
exclusive. It is also possible to define *both* a new URI scheme *and*
an http URI prefix for the same purpose -- as synonyms. For example,
both the "ssh:" and "http://sshuri.org?" prefixes could be defined. By
first using URIs that are based on the http URIs, support for the SSH
URIs could be bootstrapped faster, because http URIs can dereference to
information and software to support *both* prefixes. Later, when nearly
all clients support these prefixes, authors could start using the
briefer "ssh:" versions of the URIs. This of course would have the
downside of creating pairs of URIs that mean the same thing. But it
would provide a faster adoption path.

In short, although I think there is some good justification for defining
a new scheme for SSH, I don't think the http-based alternatives been
adequately explored yet and the pros/cons weighed.

David Booth

On Tue, 2009-10-13 at 21:35 +0200, Dan Brickley wrote:

> On Tue, Oct 13, 2009 at 9:19 PM, Ted Hardie <ted.ietf@...> wrote:
> > While I applaud the basic sentiment of not having this discussion
> > every time a new URI scheme comes up, I think you'd have to persuade
> > the IETF rather than the TAG.
>
> You're right, of course. I should have put it differently. I meant to
> express gently that if anyone around here is going to be persuaded of
> this approach, it's most likely to be the TAG. Or at least the TAG
> might be the right forum for knocking the ideas into more widely
> appealing shape. If they're persuaded, then the approach would be
> worth requesting serious review from other parties, chief amongst
> those being IETF.
>
> > The IETF is responsible for URI
> > registration, and the documents are pretty clear on that point. The
> > IESG and IAB take the TAG's input very seriously, of course, but the
> > question of URI registration is one where there has been divergence
> > for some time. As the discussion above notes, having HTTP always in
> > the URI loop may make sense for the web; it doesn't work for other
> > deployments and other protocols.
>
> Yes. Even in W3C circles there are a fair number of different views
> bouncing around.
>
> I spent a while re-reading the early years of www-talk today, and it's
> a bit disheartening how much the same old questions are still bouncing
> around 18 years later. And I'm sure not so fun for people just trying
> to register a scheme who get dragged into this decades-long
> permadiscussion.
>
> > I personally agree with those saying ssh ought to be an independent
> > scheme. It has a widely installed user base and I have seen
> > individuals use ssh:hostname as a pseudo-URI for some time. Pushing
> > out a real spec for the URI scheme would avoid interoperability
> > problems there, and that in itself is goodness.
>
> Completely agree...
>
> cheers,
>
> Dan
>
>

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

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

Re: [Uri-review] ssh URI

2009-10-13T21:20:26Z

On Tue, 2009-10-13 at 08:10 +0200, Eliot Lear wrote:

> On 10/13/09 6:02 AM, David Booth wrote:
> > Getting a scheme registered is the *easy* part. The hard part is
> > getting millions of installed clients to implement the special
> > recognition of that scheme.
> >
>
> I agree, and I think what you're proposing is interesting along those
> lines. I also appreciate your answers to my earlier questions. Right
> now we have no guidance or analysis that goes into the associated risks
> of what you are proposing. A few examples of things that can and will
> go wrong with non-participants:
>
> 1. A query goes out to a third party, and the site is down or
> unreachable. In this case, the non-participant will hang in an
> unspecified way rather than get a hard error.

Correct.

> 2. A query goes out and the third party has been compromised. And in
> this case, the third party is a really attractive target because one can
> map administrative resources with SSH. Worse, the client acts on the
> meta-information in some way, leading to additional compromises. You're
> already using redirects. So what can a bad guy redirect to in order to
> make things interesting? Well, he's got a Browser: header. Perhaps he
> redirects to an appropriate exploit.

Yes, this is a risk. But it is a similar risk as for any site that
provides downloadable software. Ultimately, when offered information
(or software) the user must decide whether to trust it. But this
doesn't mean that there isn't benefit to offering such information (or
software). We mustn't throw the baby out with the bath.

>
> Now to be fair to you, I haven't done the analysis to say, "this is
> ABSOLUTELY a problem", but nor have I seen an analysis from you that
> leads me to conclude that this is not a problem.

Likewise, I have not done the analysis to say "this is absolutely NOT a
problem". But I do think the potential benefits are enough to warrant
more thought.

>
--
David Booth, Ph.D.
Cleveland Clinic (contractor)

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

Re: [Uri-review] ssh URI

2009-10-13T21:19:39Z

On Tue, 2009-10-13 at 00:27 -0400, John Cowan wrote:
> David Booth scripsit:
>
> > Getting a scheme registered is the *easy* part. The hard part is
> > getting millions of installed clients to implement the special
> > recognition of that scheme.
>
> No harder than getting them to recognize a load-ssh-protocol-driver
> meta-scheme.

I disagree. If a client doesn't recognize a new scheme, the user has
little choice but to search around for an implementation or hope that
the client vendor adds support for it in the future. But if an http URI
is used, the URI (as a fallback) could dereference directly to a page
providing information about those new URIs, where to download client
software that supports them, and -- potentially -- even attempt to
auto-download a client extension for them. This certainly seems like it
would encourage faster adoption.

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

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

Re: [Uri-review] ssh URI

2009-10-13T18:07:56Z

Dan Brickley writes:

> Or at least the TAG might be the right forum for knocking the ideas
> into more widely appealing shape.

The TAG has considered these questions on and off for several years, and
under a variety of banners. At one point, when I was new on the TAG, I
tried pulling together drafts of a finding [1] under our ISSUE-49
(schemeProtocols) [2]. Either because I didn't understand the issues well
enough, or as likely because several of the very smart and knowledgeable
people in the room didn't actually agree on how things work in this space,
I didn't feel we were getting to closure, and I decided to put the work
down for a few years. I was in fact thinking of trying to pick it up
again, when my appointment as chair diverted most of my TAG time.

There is also a work-in-progress document "Guidelines for Web-based
naming" [3] being written by Henry Thompson and Jonathan Rees, associated
with our ISSUE-50 (URNsandRegistries) [4]. While this has been discussed
quite a bit and is perceived as making progress, and doesn't have consenus
as a TAG finding at this point either.

I do think it's fair to say that many, if not all, individual members of
the TAG do have sympathy with the general advice of "try to use widely
deployed schemes, and especially http, when you can, rather than inventing
a new one." I think David Booth has done a good job of outlining the
advantages promoted by advocates of that position. What exactly are the
limits of that guidance, and when one should indeed implement a new
scheme, seems to remain the subject of disagreement.

Noah

[1] http://www.w3.org/2001/tag/doc/SchemeProtocols.html
[2] http://www.w3.org/2001/tag/group/track/issues/49
[3] http://www.w3.org/2001/tag/doc/namingSchemes.html
[4] http://www.w3.org/2001/tag/group/track/issues/50

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Dan Brickley <danbri@...>
Sent by: uri-request@...
10/13/2009 03:35 PM

To: Ted Hardie <ted.ietf@...>
cc: David Booth <david@...>, uri-review@...,
uri@..., (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: Re: [Uri-review] ssh URI

On Tue, Oct 13, 2009 at 9:19 PM, Ted Hardie <ted.ietf@...> wrote:
> While I applaud the basic sentiment of not having this discussion
> every time a new URI scheme comes up, I think you'd have to persuade
> the IETF rather than the TAG.

You're right, of course. I should have put it differently. I meant to
express gently that if anyone around here is going to be persuaded of
this approach, it's most likely to be the TAG. Or at least the TAG
might be the right forum for knocking the ideas into more widely
appealing shape. If they're persuaded, then the approach would be
worth requesting serious review from other parties, chief amongst
those being IETF.

> The IETF is
responsible for URI
> registration, and the documents are pretty clear on that point. The
> IESG and IAB take the TAG's input very seriously, of course, but the
> question of URI registration is one where there has been divergence
> for some time. As the discussion above notes, having HTTP always in
> the URI loop may make sense for the web; it doesn't work for other
> deployments and other protocols.

Yes. Even in W3C circles there are a fair number of different views
bouncing around.

I spent a while re-reading the early years of www-talk today, and it's
a bit disheartening how much the same old questions are still bouncing
around 18 years later. And I'm sure not so fun for people just trying
to register a scheme who get dragged into this decades-long
permadiscussion.

> I personally agree with those saying ssh ought to be an independent
> scheme. It has a widely installed user base and I have seen
> individuals use ssh:hostname as a pseudo-URI for some time. Pushing
> out a real spec for the URI scheme would avoid interoperability
> problems there, and that in itself is goodness.

Completely agree...

cheers,

Dan

Re: [Uri-review] ssh URI

2009-10-13T12:35:31Z

On Tue, Oct 13, 2009 at 9:19 PM, Ted Hardie <ted.ietf@...> wrote:
> While I applaud the basic sentiment of not having this discussion
> every time a new URI scheme comes up, I think you'd have to persuade
> the IETF rather than the TAG.

You're right, of course. I should have put it differently. I meant to
express gently that if anyone around here is going to be persuaded of
this approach, it's most likely to be the TAG. Or at least the TAG
might be the right forum for knocking the ideas into more widely
appealing shape. If they're persuaded, then the approach would be
worth requesting serious review from other parties, chief amongst
those being IETF.

> The IETF is responsible for URI
> registration, and the documents are pretty clear on that point. The
> IESG and IAB take the TAG's input very seriously, of course, but the
> question of URI registration is one where there has been divergence
> for some time. As the discussion above notes, having HTTP always in
> the URI loop may make sense for the web; it doesn't work for other
> deployments and other protocols.

Yes. Even in W3C circles there are a fair number of different views
bouncing around.

I spent a while re-reading the early years of www-talk today, and it's
a bit disheartening how much the same old questions are still bouncing
around 18 years later. And I'm sure not so fun for people just trying
to register a scheme who get dragged into this decades-long
permadiscussion.

> I personally agree with those saying ssh ought to be an independent
> scheme. It has a widely installed user base and I have seen
> individuals use ssh:hostname as a pseudo-URI for some time. Pushing
> out a real spec for the URI scheme would avoid interoperability
> problems there, and that in itself is goodness.

Completely agree...

cheers,

Dan

Re: ws: and wss: schemes

2009-10-13T04:53:12Z

On Thu, 17 Sep 2009, Julian Reschke wrote:

>
> It now says:
>
> > Encoding considerations.
> > Characters in the host component that are excluded by the syntax
> > defined above must be converted from Unicode to ASCII by applying
> > the IDNA ToASCII algorithm to the Unicode host name, with both the
> > AllowUnassigned and UseSTD3ASCIIRules flags set, and using the
> > result of this algorithm as the host in the URI.
> >
> > Characters in other components that are excluded by the syntax
> > defined above must be converted from Unicode to ASCII by first
> > encoding the characters as UTF-8 and then replacing the
> > corresponding bytes using their percent-encoded form as defined in
> > the URI and IRI specification. [RFC3986] [RFC3987]
>
> I think that's good, except that the mention of IRI in the last sentence
> seems to be superfluous. RFC3986 already defines everything that is
> needed here. Or is there something specific from the IRI spec you think
> is relevant? (In which case it should state that more clearly).

I think referencing IRI for the paragraph that talks about how to process
IRIs is helpful, even if not strictly necessary. (As Martin later pointed
out, though, in general, how to convert Unicode to UTF-8 to percent
escapes appears to be defined in 3987, not 3986.)

On Fri, 18 Sep 2009, "Martin J. D�rst" wrote:
>
> I think this has various problems.
>
> First, it is fixed to IDNA 2003 (I think I may have said this already).
> IDNA 2008 is around the door. It doesn't use terms such as "ToASCII" or
> "AllowUnassigned".

What are the magic terms that we should use instead? (This will affect
HTML5 also; any advice on how to fix the terminology there would be very
welcome also.)

> Second, if this is about resolution (rather than about generic
> conversion), and because this is a new scheme, it should not exclude the
> case that some part of a domain name (reg-name) is percent-encoded,
> because both RFC 3986 and 3987 allow this.

Not sure what you mean here.

> Third, wording this as "characters" seems to say that this is a
> character-by-character operation, or that it might be applied to
> subsequent non-ASCII characters in groups, but ToASCII, when used, has
> to be applied to whole labels, not characters.

The paragraph applies it to the whole hostname.

> Fourth, as http://tools.ietf.org/html/draft-iab-idn-encoding-00 shows in
> more detail, assuming that DNS is always used for resolution of
> reg-names, and the technology will never be used e.g. on intranets with
> other resolution services seems to be unnecessarily restrictive.

Not sure what you mean here.

> Ideally, all the above points should be addressed by some work on the
> IRI front (public-iri@... cc'ed), but that work isn't done yet.

That would indeed be ideal.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

RE: [Uri-review] ssh URI

2009-10-13T01:26:44Z

The browsers, at least the ones I have used, do not know the semantics about
URI schemes, except for the ones they handle internally. They do not need
that to launch an external client or to invoke a plug-in which, at
installation, informed the browser that it can handle such schemes. As has
already demonstrated, there is no such mechanism for URI prefixes, and
indeed there should not be because the surprise factor is too big.
There is no value in educating browser users how to connect to random SSH
servers because every such connection is backed by a preceding contract
between the provider who runs a server and the customer who is allowed to
connect. So there is nothing to discover here.
Best regards,
Chris

Re: [Uri-review] ssh URI

2009-10-13T00:44:04Z

[snip]

David,

Can I suggest a new workflow for these ideas?

Instead of intervening when every new URI scheme proposal comes
through these lists, perhaps you could work to persuade the W3C TAG of
them instead? I think I understand where you're coming from, but the
approach is pretty alien to URIs as currently deployed, particularly
with regard to browser infrastructure, which at the moment is
universally keyed off of the scheme prefix and unlikely to change
rapidly due to the huge security implications.

There might be something in these ideas (though I remain generally
skeptical when it comes to protocols - such as ssh - rather than
content/object identifiers eg. doi, xri, ...). At the moment they're
being discussed in an ad hoc way whenever someone proposes a new
scheme. Could it be more efficient to propose and refine them through
the TAG, perhaps?

cheers,

Dan

Re: [Uri-review] ssh URI

2009-10-12T21:27:05Z

David Booth scripsit:

> Getting a scheme registered is the *easy* part. The hard part is
> getting millions of installed clients to implement the special
> recognition of that scheme.

No harder than getting them to recognize a load-ssh-protocol-driver
meta-scheme.

--
Eric Raymond is the Margaret Mead John Cowan
of the Open Source movement. cowan@...
--Bruce Perens, http://www.ccil.org/~cowan
some years ago

Re: [Uri-review] ssh URI

2009-10-12T21:20:36Z

On Tue, 2009-10-13 at 12:35 +0900, Conrad Parker wrote:

> 2009/10/13 David Booth <david@...>:
> >
> > 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?
>
> Encouraging end-users to download ssh client software from a random
> web site specified by a third-party web-page author, and then
> (automatically) using that software to connect to the desired ssh
> server ... and hoping that this is somehow secure by using an SSL/TLS
> connection to access that software?

It wouldn't be a random web site, it would be the official web site of
SSH URIs! That's no more random than mozilla.com or adobe.com, from
which software is routinely downloaded thousands of times a day.

>
> No, this does not make sense. It encourages use of untrusted ssh
> client software (eg. not sourced from your operating system vendor,

That's a policy choice that should not be baked into the technical
design. Making the software more difficult to obtain is a minus, not a
plus.

> unsigned etc.)

Any such software certainly could and should be signed.

> so the scheme could be easily exploited by a third
> party to serve an ssh client with a backdoor.

That's no different than access to *any* web site. *Any* site can try
to serve up a trojan horse. But that doesn't mean that there isn't
value in visiting web sites and value in making information and software
more readily available with existing mechanisms.

David Booth

> Using https to access
> that info/software does nothing to secure the initiation of the ssh
> connection.
>
> If anything, ssh provides a good use-case for a custom uri scheme.
>
> Conrad.
>
>
--
David Booth, Ph.D.
Cleveland Clinic (contractor)

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

Re: [Uri-review] ssh URI

2009-10-12T21:02:58Z

On Mon, 2009-10-12 at 21:55 -0400, Bob Aman wrote:

> >> I have a problem with this in the general case because I don't think
> >> there's currently a way for such a URI to be registered to a specific
> >> application in any major browser.
> >
> > Take a look at greasemonkey:
> > https://addons.mozilla.org/en-US/firefox/addon/748
> > Greasemonkey is based on recognizing URI patterns and performing special
> > functions when such patterns are recognized.
>
> I'm familiar with greasemonkey. Last I checked, greasemonkey didn't
> launch applications so much as rewrite pages in place, and even if it
> could, that's not even remotely user-friendly. Beyond that, it's not
> something that really applies outside of the Firefox ecosystem. The
> point isn't that it's not technically feasible, the point is that it's
> a path that has way more technical and psychological hurdles to
> overcome than getting a scheme registered with the IANA.

Getting a scheme registered is the *easy* part. The hard part is
getting millions of installed clients to implement the special
recognition of that scheme.

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

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

Re: [Uri-review] ssh URI

2009-10-12T20:35:25Z

2009/10/13 David Booth <david@...>:

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

Encouraging end-users to download ssh client software from a random
web site specified by a third-party web-page author, and then
(automatically) using that software to connect to the desired ssh
server ... and hoping that this is somehow secure by using an SSL/TLS
connection to access that software?

No, this does not make sense. It encourages use of untrusted ssh
client software (eg. not sourced from your operating system vendor,
unsigned etc.) so the scheme could be easily exploited by a third
party to serve an ssh client with a backdoor. Using https to access
that info/software does nothing to secure the initiation of the ssh
connection.

If anything, ssh provides a good use-case for a custom uri scheme.

Conrad.

Re: [Uri-review] ssh URI

2009-10-12T18:55:59Z

>> I have a problem with this in the general case because I don't think
>> there's currently a way for such a URI to be registered to a specific
>> application in any major browser.
>
> Take a look at greasemonkey:
> https://addons.mozilla.org/en-US/firefox/addon/748
> Greasemonkey is based on recognizing URI patterns and performing special
> functions when such patterns are recognized.

I'm familiar with greasemonkey. Last I checked, greasemonkey didn't
launch applications so much as rewrite pages in place, and even if it
could, that's not even remotely user-friendly. Beyond that, it's not
something that really applies outside of the Firefox ecosystem. The
point isn't that it's not technically feasible, the point is that it's
a path that has way more technical and psychological hurdles to
overcome than getting a scheme registered with the IANA.

-Bob Aman

Re: [Uri-review] ssh URI

2009-10-12T18:42:20Z

On Mon, 2009-10-12 at 21:16 -0400, Bob Aman wrote:
> > - 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.
>
> I have a problem with this in the general case because I don't think
> there's currently a way for such a URI to be registered to a specific
> application in any major browser.

Take a look at greasemonkey:
https://addons.mozilla.org/en-US/firefox/addon/748
Greasemonkey is based on recognizing URI patterns and performing special
functions when such patterns are recognized.

David Booth

> And for the specific case, I can
> think of at least one use case where you might want to link to an ssh
> URI in a browser: HTTP-based admin interfaces to machines.
>
> And I'll also repeat my previous comment for emphasis: This concept
> is just confusing.
>
> -1 to the concept of using anything under the http/https scheme to
> formally represent an ssh identifier.
>
> -Bob Aman
>
>

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

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

Re: [Uri-review] ssh URI

2009-10-12T18:16:33Z

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

I have a problem with this in the general case because I don't think
there's currently a way for such a URI to be registered to a specific
application in any major browser. And for the specific case, I can
think of at least one use case where you might want to link to an ssh
URI in a browser: HTTP-based admin interfaces to machines.

And I'll also repeat my previous comment for emphasis: This concept
is just confusing.

-1 to the concept of using anything under the http/https scheme to
formally represent an ssh identifier.

-Bob Aman

Re: [Uri-review] ssh URI

2009-10-12T18:12:39Z

On Mon, 2009-10-12 at 19:51 -0400, Daniel R. Tobias wrote:
> On 12 Oct 2009 at 21:35, 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.
>
> It does seem to be an ideological position for some.

Excuse me? By piggy-backing on http URIs, you can get easier, faster
adoption with more user-friendly fallback behavior. To my mind that's
an engineering concern -- not an idealogical position.

--
David Booth, Ph.D.
Cleveland Clinic (contractor)

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

RE: [Uri-review] ssh URI

2009-10-12T17:52:36Z

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@... [mailto:uri-review-bounces@...] On
> Behalf Of David Booth
> Sent: Monday, October 12, 2009 7:02 PM
> To: Steve Suehring
> Cc: uri-review@...; uri@...
> 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.

Re: [Uri-review] ssh URI

2009-10-12T15:58:18Z

> I don't think that the http URI prefix is a good solution for the ssh
> protocol. There is too much room for userland confusion which is
> undesirable due to the nature of ssh traffic.
>
> Steve

I have to agree with Steve on this. I'm already terribly confused by
David's suggestion.

-Bob Aman