Subject: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt

From: [email-masked]
Date: Wed, 13 Aug 2003 10:02:51 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SCP/SFTP/SSH URI Format
	Author(s)	: S. Suehring, J. Salowey
	Filename	: draft-ietf-secsh-scp-sftp-ssh-uri-00.txt
	Pages		: 7
	Date		: 2003-8-13
	
This document describes the Uniform Resource Identifiers used to
locate resources for the SCP, SFTP, and SSH protocols.  The document
describes the generic syntax involved in URI definitions as well as
specific definitions for each protocol.  These specific definitions
may include user credentials such as username and password and also
may include other parameters such as fingerprint.  In addition, 
security considerations and examples are also provided within this
document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-scp-sftp-ssh-uri-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Tatham <[email-masked]>
Date: Wed, 13 Aug 2003 16:25:07 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-00.txt

The SSH and SFTP schemes look basically sane to me. Some comments on
the rest:

 - SCP is a bit harder, because AIUI there's no requirement for
   absolute path names on an SCP server to begin with a slash, so
   the stated syntax is potentially ambiguous. (A Windows SCP
   server, for example, is at liberty to begin all its absolute path
   names with "c:\" and "d:\" and so on, I believe.)

 - In the parameters section, there is repeated text saying `This
   parameter MUST NOT add a mechanism to a configured list of
   default configured acceptable encryption types'. I can't
   immediately parse that. Does that mean that if an SSH client
   doesn't by default enable (say) "des-cbc", it must not enable it
   solely on the say-so of the URL? Does it in fact mean that the
   client should restrict its existing set of ciphers (or whatever)
   to the intersection of its preconfigured/default set and the set
   provided in the URL? If not, what does it mean?

 - I'm particularly concerned about the "fingerprint" parameter. I
   appreciate that the document already mentions that it makes a
   difference whether the URL's fingerprint was obtained through a
   trustworthy mechanism, but it strikes me that this might be fun
   to implement in the average software setup in which the web
   browser and the SSH client are separate, because if the client is
   just handed a URL it won't in general know how it was obtained.

   Perhaps a solution is for the web browser to allow separate
   configuration of SSH client commands for securely and insecurely
   obtained SSH URLs, and then those could be configured to be
   respectively `putty --trust-fingerprint-parameter <URL>' and just
   plain `putty <URL>'.

Less fundamental nits:

 - There may be more than one cipher/integrity/key-xchg parameter in
   a given URL, but if there is, what preference order does that
   imply? Or none?

 - Come to think of it, why must there not be more than one
   fingerprint parameter? A host might perfectly well have ssh-dss
   and ssh-rsa host keys, and want to supply the fingerprints of
   both because it can't predict which key exchange mechanisms the
   client supports.

 - `They fingerprint' -> `The fingerprint'.

 - Shouldn't there be references describing the protocols specified
   by the three schemes? (_Is_ there even a document describing SCP?)

 - Why is `Guidelines for new URL schemes' a normative reference?

-- 
Simon Tatham         "Imagine what the world would be like if
<[email-masked]>    there were no hypothetical situations..."

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 13 Aug 2003 13:34:40 -0400

Is there a good reason to define scp URLs in addition to sftp URLs?

I don't think explicitly specifying port 22 in all cases where the URL
doesn't specify a port number is correct; what about SRV DNS records?

What is the rationale for allowing the URL to specify information
about ciphers, integrity protection, etc?  It seems allowing this to
be specified might allow an attacker providing a URL to perform a
downgrade attack, which at the very least should be mentioned in the
security considerations section.  There doesn't seem to be anything
prohibiting an attacker from specifying ``none'', either.

It looks to me like there is no mechanism for specifying the public
key host key algorithm to be used, nor does the fingerprint contain
that information.  Combined with only allowing one fingerprint, that
has the potential to cause interoperability problems: if I have a
server with one ssh-rsa key, and one ssh-dss key, and some clients
happen to prefer ssh-rsa over ssh-dss and others are the other way
around, how do I provide a URL with a fingerprint that will work with
both types of clients?

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 13 Aug 2003 11:06:38 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Tatham
> Sent: Wednesday, August 13, 2003 8:25 AM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt
> 
> 
> The SSH and SFTP schemes look basically sane to me. Some 
> comments on the rest:
> 
I'm not sure, but I believe it is acceptable for the absolute path
section to contain C: or d:. 

Scp://c:/file.txt

Do you see an issue with this?

>    solely on the say-so of the URL? 
[Joe] Yes

>    Does it in fact mean that the
[Joe] Yes

>    respectively `putty --trust-fingerprint-parameter <URL>' and just

[Joe] This would be good, although I'm not sure you could achieve this
configuration in current web browsers and mail clients.   I was thinkin
that this could also involve user participation in the verification as
well.  Perhaps a prompt indicating "the host key from the server matches
(or does not match) the fingerprint in the URL; do you want to proceed?"

>    a given URL, but if there is, what preference order does that
[Joe] they should be listed in order of preference.
 
>    both because it can't predict which key exchange mechanisms the
[Joe] Good point.

---

From: Simon Tatham <[email-masked]>
Date: Wed, 13 Aug 2003 19:17:50 +0100

> I wrote:

> Do you see an issue with this?

Well, the URI definition said

  scp_URI = "scp://" [ userinfo "@" ] host [ ":" port ] 
        [ ; parameter = value ] [ abs_path ]

So the `abs_path' section starts immediately after the host name,
and hence it is expected to begin with a slash:

  scp://hostname/usr/bin/thingy
                ^^^^^^^^^^^^^^^

If the abs_path doesn't begin with a slash, you get

  scp://hostnamec:\bin\thingy

which is clearly useless (and that's without even going into the
backslash issue).

-- 
Simon Tatham         "_shin_, n. An ingenious device for
<[email-masked]>    finding tables and chairs in the dark."

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 13 Aug 2003 11:20:55 -0700

> [mailto:[email-masked]] On Behalf Of Joel N. Weber II
> Sent: Wednesday, August 13, 2003 10:35 AM
> To: [email-masked]
[Joe] SCP is is use today, we thought it would be useful.

> I don't think explicitly specifying port 22 in all cases 
> where the URL doesn't specify a port number is correct; what 
> about SRV DNS records?
[Joe] So the suggestion would be something like:

If the URL doesn't specify a port number the it should check for a SRV
DNS record if it is available, if it is not then it should use port 22.

> 
> What is the rationale for allowing the URL to specify 
> information about ciphers, integrity protection, etc?  It 
> seems allowing this to be specified might allow an attacker 
> providing a URL to perform a downgrade attack, which at the 
> very least should be mentioned in the security considerations 
> section.  There doesn't seem to be anything prohibiting an 
> attacker from specifying ``none'', either.

[Joe]  This was added as an afterthought to the fingerprint parameter.
The thought was that the this would allow the URL to specify what
parameters should be used.  However for parameters that are negotiated
such as cipher, integrity, etc. It's not clear that they add much value.
The list should not add to what is configured as acceptable to the
client confiuration.  If the client allows none in its default
configuration there is a potential problem whether the URL speficies it
or not.  Perhaps it would be better to let the SSH negotiation take care
of this and remove it from the URL.      
 
> It looks to me like there is no mechanism for specifying the 
> public key host key algorithm to be used, nor does the 
> fingerprint contain that information.  Combined with only 
> allowing one fingerprint, that has the potential to cause 
> interoperability problems: if I have a server with one 
> ssh-rsa key, and one ssh-dss key, and some clients happen to 
> prefer ssh-rsa over ssh-dss and others are the other way 
> around, how do I provide a URL with a fingerprint that will 
> work with both types of clients?
> 
[Joe] Yes, I didn't think about this.  There should be a way to
accomplish this.  It seems like we may need to allow for multiple
fingerprints and multiple host algortihms.  Perhaps the fingerprint
parameter should be something like
fingerprint=<hostkeyalg>:<fingerprint>;

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 13 Aug 2003 11:35:59 -0700

Sorry I goofed up my response

So how about 

scp://hostname/c:/bin/thingy

Isn't there current a similar problem with ftp urls?

It would seem that in order to form the URL you would have to convert
path-separators into / to fit into URL syntax. I think this is what is
done with FTP.  Currently I don't have access to a windows FTP server to
test out this theory.  

I guess the difference is that in FTP you have an explicit change
directory command that you can interpret each path element to be an
argumant for.  I'm not sure if SCP has this concept.  In any case we
will have to be a bit more specific about the handling of path elements
SCP and probably SFTP as well.

Joe  

> From: Simon Tatham [mailto:[email-masked]] On 
> Behalf Of Simon Tatham
> Sent: Wednesday, August 13, 2003 11:18 AM
> To: Joseph Salowey
> Cc: [email-masked]
> So the `abs_path' section starts immediately after the host 
> name, and hence it is expected to begin with a slash:
> 
> which is clearly useless (and that's without even going into 
> the backslash issue)

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Aug 2003 14:35:18 -0700

> DNS record if it is available, if it is not then it should use port 22.

Then you need to describe this in detail (e.g., SRV RR naming).  And the
fact that DNS is often deployed in insecure configurations is definitely
something to point out in the security considerations section - that is,
if the SRV lookup cannot be done securely then 22 should be used, IMO.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 13 Aug 2003 17:55:55 -0400

> [Joe] SCP is is use today, we thought it would be useful.

I guess I'm not really clear on what the working group and ssh
implementors think should be the future of scp vs sftp.  If there is a
desire to depreciate scp in favor of sftp, it may be best to not
define a URL scheme for scp to encourage the use of sftp.

> DNS record if it is available, if it is not then it should use port 22.

It might be better to come up with language along the lines that if
the port number is specified in the URL, it is used, otherwise the
port number to use is determined by what is specified in the other
secsh documents.  However, it seems like there's a little bit of
vagueness there; the transport draft says that ssh normally listens on
port 22, and there's no mention of SRV records anywhere in the secsh
documents, as far as I can tell.

> of this and remove it from the URL.      

I can have a client which is set up to accept AES, or if that is not
available, single DES, or if that is not available, none.  As long as
I'm properly verifying the host key, the client allowing that fallback
will not reduce security in the cases where the server does support
AES, because the signature made with the host key is against a hash
that includes all of the cipher algorithms that both sides offered.

But I do agree that letting ssh negotiation decide these things makes
sense.  (The only times I can remember I've overridden a list of
algorithms that my ssh client had by default were testing pgp-sign-*
support before I'd written the code to add those algorithms to the
default proposal list, and overriding the cipher when doing a long
file transfer between relatively slow machines over ethernet.  And if
the latter problem is worth fixing, it should be done with careful
consideration of which ciphers are both fast and secure, and putting
such a cipher at the begining of the list for all file transfers.)

> fingerprint=<hostkeyalg>:<fingerprint>;

I'm not sure that there's necessarily a need to allow for multiple
fingerprints.  If you are getting an ssh:// url from a trusted source,
you could just use an ssh-dss key, and all clients will support that.

The set of characters that can theoretically be used in the name of a
host key algorithm is probably a superset of what you want to allow in
a URL, so there probably needs to be an escaping mechanism, sigh.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 13 Aug 2003 17:57:17 -0400

> if the SRV lookup cannot be done securely then 22 should be used, IMO.

While we're at it, maybe we should say that if the A lookup can't be
done securely, then you have to use 127.0.0.1?  :-P

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Aug 2003 14:56:26 -0700

> done securely, then you have to use 127.0.0.1?  :-P

Point taken :)

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 13 Aug 2003 19:23:14 -0400

> done with FTP.  

yep, that matches my (possibly lossy) understanding of ftp as well
(shortly after NetBSD's ftp client was extended to take url's on the
command line, there was a followup code change to do individual
cd's for each URL component ..)

---

From: Simon Tatham <[email-masked]>
Date: Thu, 14 Aug 2003 00:25:57 +0100

> scp://hostname/c:/bin/thingy

The difficulty with that is that you really want the SCP client to
send the pathname 'c:/bin/thingy', without a leading slash. But when
you say `scp://hostname/usr/bin/foo', you want the SCP client to
send `/usr/bin/foo', _with_ the leading slash. So this design
requires the _client_ to do something clever about conditionally
stripping the leading slash. Surely?

(Unless you're mandating that the _server_ in the 'c:/' case must be
capable of throwing away a leading slash? But that seems like a
requirement on server behaviour as well as URI format, which is
fairly serious remit creep...)

-- 
Simon Tatham         "I'm going to pull his head off. Ear by ear."
<[email-masked]>                          - a games teacher

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 13 Aug 2003 19:36:58 -0400

(again, wg chair hat off..)

> fairly serious remit creep...)

An alternative (which would confuse a different set of people) would
be to always eat the / after then hostname-part of the URL, so for
unix systems, you'd see URL's like:

scp://user@hostname/.login     (referring to the .login in your home directory)
scp://user@hostname//etc/passwd

On the other hand, this would also make

scp://user1@hostname/~user2/foo

less of a special case.

					- Bill

---

From: Darren J Moffat <[email-masked]>
Date: Wed, 13 Aug 2003 17:07:59 -0700 (PDT)

> fairly serious remit creep...)

Keeping in mind that scp is really just the rcp protocol over the SSH
transport.  Since rcp is a historically a UNIX protocol it doesn't (at
least to me, but probably not to everyone) seem unreasonable that a
server providing access via rcp should do the work of mapping UNIX
style names to its style.  Isn't that the case with '/' vs '\' on
Windows anyway ?

How would one specify an scp URI that was accessing a resource mounted
from a remote Windows filesystem (IIRC double slashes are required).

> scp://user@hostname//etc/passwd

Given the user@ part that actually seems reasonable, and it makes it similar
to the following cli syntax for scp(1):

	$ scp user@hostname:.login
	$ scp user@hostname:/etc/passwd

The double // requirement could be confusing in a case where "userinfo@"
isn't specified. For example:

 scp://hostname/etc/passwd or scp://hostname//etc/passwd

Based on the behaviour of http I would personally have expected these
to be equivalent, however they wouldn't necessarily be.  What is the username
on the remote host when "userinfo@" isn't specified (which is where the
home directory is inferred from).

-- 
Darren J Moffat

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 13 Aug 2003 21:59:18 -0700

URI's have a pretty specific format detailed in RFC 2396.  Here is my
interpretation

For SCP/SFTP we are defining Abolute URI

AbsoluteURI = scheme ":" (hier_part | opaque_part)

If we deicide that SCP URIs are hierarchical in nature and will be
parsed by a URI parser then we use a hier_part.

Hier-Part = "//authority [abs_path]
Abs_path = "/" path_segments

In this case we use the standard URI definitions to define the authority
(User@host:port).  Along with this comes the leading '/' and the use of
'/' as a path separator.  This means that SCP will have to have a
minimal URI paser.  This means the C:\mywindows\files may be represented
as

Scp://host/c:/mywindows/files

If we choose to make them opaque then what comes after scp: is defined
and parsed by SCP then the URI for the above file might look like (other
parsing schemes are possible, the point is they do not have to adhere to
URI parsing).

Scp:user:@host::c:\mywindows\files

In general since filesystems have a hierachical structure it is probably
better to go with hierarchical naming.  This makes it possible to use
relative URLs and reference a resource in different ways.

Thanks,

Joe

> Sent: Wednesday, August 13, 2003 4:26 PM
> To: [email-masked]
> The difficulty with that is that you really want the SCP 
> client to send the pathname 'c:/bin/thingy', without a 
> leading slash. But when you say `scp://hostname/usr/bin/foo', 
> you want the SCP client to send `/usr/bin/foo', _with_ the 
> leading slash. So this design requires the _client_ to do 
> something clever about conditionally stripping the leading 
> slash. Surely?
> 
> (Unless you're mandating that the _server_ in the 'c:/' case 
> must be capable of throwing away a leading slash? But that 
> seems like a requirement on server behaviour as well as URI 
> format, which is fairly serious remit creep...)
> 
> --

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 13 Aug 2003 22:16:21 -0700

Comments inline

> [mailto:[email-masked]] On Behalf Of Darren J Moffat
> Sent: Wednesday, August 13, 2003 5:08 PM
> To: [email-masked]
> > requirement on server behaviour as well as URI format, 
> which is fairly 
> > serious remit creep...)
> 
> Keeping in mind that scp is really just the rcp protocol over 
> the SSH transport.  Since rcp is a historically a UNIX 
> protocol it doesn't (at least to me, but probably not to 
> everyone) seem unreasonable that a server providing access 
> via rcp should do the work of mapping UNIX style names to its 
> style.  Isn't that the case with '/' vs '\' on Windows anyway ?
> 

[Joe] URI syntax dictates the leading '/' and the use of '/' as a
separator in a hierarcical namespace. 

> How would one specify an scp URI that was accessing a 
> resource mounted from a remote Windows filesystem (IIRC 
> double slashes are required).
> 

[Joe] Okay, my brain hurts.

Scp://hostname/\\remotehostname\directory\file

> Given the user@ part that actually seems reasonable, and it 
> makes it similar to the following cli syntax for scp(1):
> 
> The double // requirement could be confusing in a case where 
> "userinfo@" isn't specified. For example:
> 
[Joe] The "//" is part of URL syntax and is required if we are using
hierarcical naming

> Based on the behaviour of http I would personally have 
> expected these to be equivalent, however they wouldn't 
> necessarily be.  What is the username on the remote host when 
> "userinfo@" isn't specified (which is where the home 
> directory is inferred from).
> 
[Joe] There is madness in the method 

In general scp://hostname/etc/passwd means

cd etc (not /etc) 
get the file passwd

(this would probably get you the passwd file under the etc directory in
your home directory)

Scp://hostname//etc/passwd means 

cd 
cd etc 
Get the file passwd

(this would probably get you the passwd file under the etc directory in
your home directory)

Scp://hostname/%2Fetc/passwd means

cd /etc
Get the file passwd
(this would get you the file /etc/passwd, note that the '/' must be
escaped as %2F since it is a reserved character in hierarchical URLs)

This is detailed in
http://www.ietf.org/internet-drafts/draft-hoffkohn-rfc1738bis-00.txt
section 2.2.2.  I expect we need a similar description for SCP and SFTP.

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 13 Aug 2003 22:19:13 -0700

> name, and hence it is expected to begin with a slash:

[Joe] So abs_path is defined in RFC2396 as 

Abs_path = '/' path_segments

We will need to include ABNF refernces in the next revision.

> the backslash issue).

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 13 Aug 2003 22:20:48 -0700

> something clever about conditionally stripping the leading 
[Joe] Yes the client needs to implement a URI parser.

---

From: Roumen Petrov <[email-masked]>
Date: Thu, 14 Aug 2003 15:33:22 +0300

What about syntax:

secsh_URI := secsh_scheme "://" [secsh_userinfo] "@" ] host [ ":" port ] 
[; params] [abs_path]
secsh_scheme := {ssh|scp|sftp}
abs_path := "/" path_segments
path_segments := ["/"] segment [ "/" segment]
params := parameter=value [, parameter=value]

- when path_segments begin with "/" or "%2F" => path is relative to "/" 
or "My Computer(?)" :) for windows otherwise to user home directory.
- when parameter is not supported by scheme should be ignored - as 
example typecode for ssh.

Misc.:
I hope that attached shell script "ftp-url-test.sh" will help to 
understand ftp urls. Script use two programs wget and curl.
Before to run we should create directory "c:" in user home "${HOME}" and 
in root  "/" and file path.txt in them, i.e.:
-----------------------------------------------------------------------------
$ cd
$ mkdir 'c:'
$ cd 'c:'
$ pwd > path.txt
$ su -
# cd /
# mkdir 'c:'
# cd 'c:'
# pwd > path.txt
-----------------------------------------------------------------------------

output from script is similar to:
-----------------------------------------------------------------------------
=== port:=
===[ftp://test:change_it@localhost/c:/path.txt]===
wget->/home/test/c:
curl->/home/test/c:
===[ftp://test:change_it@localhost/c%3A/path.txt]===
wget->/home/test/c:
curl->/home/test/c:
===[ftp://test:change_it@localhost//c:/path.txt]===
wget->/c:
curl->/c:
===[ftp://test:change_it@localhost//c%3A/path.txt]===
wget->/c:
curl->/c:
===[ftp://test:change_it@localhost/%2Fc%3A/path.txt]===
wget->/c:
curl->/c:
=== port:=21
===[ftp://test:change_it@localhost:21/c:/path.txt]===
wget->/home/test/c:
curl->/home/test/c:
===[ftp://test:change_it@localhost:21/c%3A/path.txt]===
wget->/home/test/c:
curl->/home/test/c:
===[ftp://test:change_it@localhost:21//c:/path.txt]===
wget->/c:
curl->/c:
===[ftp://test:change_it@localhost:21//c%3A/path.txt]===
wget->/c:
curl->/c:
===[ftp://test:change_it@localhost:21/%2Fc%3A/path.txt]===
wget->/c:
curl->/c:
-----------------------------------------------------------------------------
Browsers:
- Konqueror 3.0.x ( not tested with versions > 3.1 and  < 3.0 ) always 
download "/c:/path.txt" :-(
- ftp in Opera 6.0 (not tested with versions >= 6.1 and < 6) is not 
stable (problems with userinfo and ":" in path).
- Gecko (not tested with versions < 1.0) - fine
- IE - not tested.
- Comunicator (Netcape 4.7x):
  - "ftp://user:pass@host" list user home dir and change url to 
ftp://user@host/path_to_user_home
  - "ftp://user:pass@host/" list root directory
, i.e. depend from implementation  :-(

>cd's for each URL component ..)
#!/bin/sh
# Author: Roumen Petrov

WGET="wget"
WGET_OPT="--proxy=off -e verbose=off -e debug=off -e server_response=off --output-document=-"

CURL="curl"
CURL_OPT=""

DEFAULT_PORT="21"

# ===
scheme="ftp"

user="${USER}"
pass="change_it"
userinfo="${user}:${pass}"

host="localhost"

for port in '' 21; do
  echo "=== port:=${port}"

  hostport=""
  #if test -n "${port}" -a "${port}" != "${DEFAULT_PORT}"; then
  if test -n "${port}"; then
    hostport="${host}:${port}"
  else
    hostport="${host}"
  fi

  for abs_path in \
    'c:/path.txt' \
    'c%3A/path.txt' \
    '/c:/path.txt' \
    '/c%3A/path.txt' \
    '%2Fc%3A/path.txt' \
  ; do
    URL="${scheme}://${userinfo}@${hostport}/${abs_path}"

    echo "===[${URL}]==="
    printf "wget->"; ${WGET} ${WGET_OPT} "${URL}" 2>/dev/null
    printf "curl->"; ${CURL} ${CURL_OPT} "${URL}" 2>/dev/null
  done
done

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Aug 2003 10:34:35 -0400

On Wednesday, Aug 13, 2003, at 20:07 America/Montreal, Darren J Moffat 
wrote:
> Since rcp is a historically a UNIX protocol it doesn't (at
> style names to its style.

To confirm and be more precise, RCP was invented at UC Berkeley
as part of the BSD UNIX distributions.  So the protocol has always
been UNIX-centric for those reasons.  It is far too late in the day
to be proposing any changes to RCP in that regard.

IMHO,

Ran

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 15 Aug 2003 04:35:34 -0400

> documents, as far as I can tell.

Indeed, the behavior should be exactly as if the user ran the ssh client 
without specifying a port.  For most (all?) ssh clients, that means 
connecting to port 22.

RFC2782 is fairly clear on this:

    Service SRV records SHOULD NOT be used in the absence
    of such specification.

That is, if the SSH protocol spec does not specify the use of SRV records, 
then their use by implementations is explicitly NOT RECOMMENDED by RFC2782. 
In the present case, we're defining a URL syntax for a protocol which is 
primarily accessed by means other than URL's.  It would seem inappropriate 
in such a context to specify the use of SRV records when the underlying 
protocol does not do so.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: "Joel N. Weber II" <[email-masked]>
Date: Fri, 15 Aug 2003 13:00:43 -0400

> without specifying a port.

Yep, and the URL spec should say that

> For most (all?) ssh clients, that means 
> connecting to port 22.

and not mention port 22, so that we don't have to update the URL spec
in the future if this changes.

> in such a context to specify the use of SRV records when the underlying 

Interesting.  I'm aware of some ssh SRV records that a friend set up,
so I assumed that using them was correct.

RFC2782 doesn't seem to offer any guidance about which protocols
should use SRV, and which shouldn't.

Is not using SRV in ssh a delibrate decision?

---

From: Steve Suehring <[email-masked]>
Date: Fri, 15 Aug 2003 12:56:10 -0500

> Yep, and the URL spec should say that

I guess I'm just not sure if we need to get more specific about the port.  
In looking at RFC 2396, "If the port is omitted, the default port number
is assumed."  The wording as it stands in the draft is "If the port is not
included, port 22 is assumed."  Therefore, should we just change it to: 
"If the port is not included, the default port is assumed."?  I personally 
like it as is with the specific port included, but I'm not against 
changing it.

Steve

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 15 Aug 2003 14:26:05 -0400

> in the future if this changes.

Agree.

>> That is, if the SSH protocol spec does not specify the use of SRV
>> records,  then their use by implementations is explicitly NOT
>> RECOMMENDED by RFC2782.  In the present case, we're defining a URL
>> syntax for a protocol which is  primarily accessed by means other than
>> URL's.  It would seem inappropriate  in such a context to specify the
>> use of SRV records when the underlying  protocol does not do so.
>

Well, "MUST is for implementors", so YMMV.

> should use SRV, and which shouldn't.

Correct.  It doesn't offer a lot of guidance to protocol designers as to 
when it makes sense to specify the use of SRV records and when it does not. 
IMHO, SRV records are appropriate for services where you're likely to want 
to find a canonical instance of a service for a particular site (such as 
Kerberos KDC's), or where service may be provided by a set of redundant 
machines (such as mail exchangers).  It doesn't make sense for 
host-directed interactive services like telnet and ssh, except perhaps in a 
small number of cases.

The guidance that RFC2782 _does_ provide is to implementors, particularly 
of clients -- it RECOMMENDs that SRV records not be used unless specified.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 18 Aug 2003 12:00:53 -0400

> like it as is with the specific port included, but I'm not against 

one alternate wording making it clear this document isn't inventing
anything:

   "if the port is not included, the default port (22) is assumed"

However, the ssh clients I'm familiar with generally include the
ability to have a local configuration override which can replace both
port number and ip address on a host-by-host basis -- this does throw
something of a monkey wrench into the mix.  

In the past, I've used this to good effect (in combination with other
kludgy bits of duct tape and bailing wire) to work around connectivity
abnormalities of various sorts..

					- Bill

---

From: Jacob Nevins <[email-masked]>
Date: Thu, 21 Aug 2003 17:07:48 +0100

Joseph Salowey writes:
> [Joel N. Weber II:]

How should filenames containing spaces be represented in scp: URLs?
Backslashes?

The scp "protocol" requires that such filenames be quoted in some
unspecified way (often using Unix shell quoting, but presumably
server-dependent).
IME, with many current clients it's up to the user to know the quoting
convention on the particular server. Either the quoting will have to
be embedded in URLs (and hence specified), or quoting becomes the
client's responsibility and the standardisation of the URL format will
not do much to achieve interoperability.

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 25 Aug 2003 17:17:22 -0700

> [mailto:[email-masked]] On Behalf Of Jacob Nevins
> Sent: Thursday, August 21, 2003 9:08 AM
> To: [email-masked]
> How should filenames containing spaces be represented in scp: 
> URLs? Backslashes?
> 

[Joe] In a URL spaces need to be escaped (%20)

> The scp "protocol" requires that such filenames be quoted in 
> some unspecified way (often using Unix shell quoting, but 
> presumably server-dependent). IME, with many current clients 
> it's up to the user to know the quoting convention on the 
> particular server. Either the quoting will have to be 
> embedded in URLs (and hence specified), or quoting becomes 
> the client's responsibility and the standardisation of the 
> URL format will not do much to achieve interoperability.
> 

[Joe] So if hierarchical URL format is used then either the SCP client
or server will have to deal with converting the URL into the appropriate
format.  If we decide to use an opaque format then this portion of the
URL would not be paresed by the URL parser and existing ways of
formatting the pathname apply.  

It seems that using hierarcical URLs will require implementation work on
SCP client and maybe SCP server which may not be desireable.