Subject: SSH URI draft

From: Joe Salowey <[email-masked]>
Date: Wed, 17 Nov 2010 10:54:54 -0800

I submitted a new version of the SSH URI draft from several years back.  I removed the SFTP and SCP schemes since I could nto find a stable reference.  We can address these protocols in a separate document.   Please review and send comments.  I'm particularly interested to know what URI schemes have been implemented for these protocols.  

http://tools.ietf.org/html/draft-salowey-secsh-uri-00

Thanks,

Joe

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Nov 2010 14:18:00 -0600

On Wed, Nov 17, 2010 at 10:54:54AM -0800, Joe Salowey wrote:
> I submitted a new version of the SSH URI draft from several years
> back.  I removed the SFTP and SCP schemes since I could nto find a
> stable reference.  We can address these protocols in a separate
> document.   Please review and send comments.  I'm particularly
> interested to know what URI schemes have been implemented for these
> protocols.  
> 

Nothing about what resources can be referred via SSH URIs other than the
entire SSHv2 service?

Resources I can think of:

 - shell sessions, with and without pty
 - port forwardings
 - subsystems
    - paths to resources for those subsystems

Now, to be fair, the idea of specifying port forwardings (and agent, X11
display, and other forwardings) in URIs scares me, so I'd rather leave
them out than in.  And clearly SFTP merits its own URI scheme, and
perhaps so do all subsystems.  But ISTM that we should at least consider
distinguishing between "the whole service" and "shell session".

Nico
--

---

From: Joe Salowey <[email-masked]>
Date: Wed, 17 Nov 2010 13:33:41 -0800

The original intention was for interactive SSH shell sessions.   I agree that port forwarding should be out of scope for this.  I also tend to think that other subsystems would be out of scope as well.   I hadn't really thought about shell sessions without pty, did you have something in mind?  

The draft needs to be clear about this so I'll work up some text.   Do you see a problem with using "ssh" as the scheme name to mean  SSH shell sessions with pty?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Nov 2010 15:45:22 -0600

On Wed, Nov 17, 2010 at 01:33:41PM -0800, Joe Salowey wrote:
> The original intention was for interactive SSH shell sessions.   I
> agree that port forwarding should be out of scope for this.  I also
> tend to think that other subsystems would be out of scope as well.   I
> hadn't really thought about shell sessions without pty, did you have
> something in mind?  

No-pty is only really useful if you're sending a command-line, or if
you're a masochist.  So perhaps an encoded command-line would be a
resource to name...  But I'd have the same concerns as with forwardings:
getting someone to click on a dangerous URI is too easy.  So... never
mind, I think.

> The draft needs to be clear about this so I'll work up some text.   Do
> you see a problem with using "ssh" as the scheme name to mean  SSH
> shell sessions with pty?

None at all.

Nico
--

---

From: der Mouse <[email-masked]>
Date: Wed, 17 Nov 2010 17:12:41 -0500 (EST)

> you're a masochist.

Not quite.  On a few occasions I've seen failure modes that broke pty
logins but let me do no-pty stuff.  (I do, however, think that that
case is rather out of scope for URI design.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Nov 2010 16:53:18 -0600

> case is rather out of scope for URI design.)

Yes, but I consider power users equivalent to masochists in this context :)

---

From: [email-masked] (Niels Möller)
Date: Fri, 19 Nov 2010 12:34:46 +0100

Joe Salowey <[email-masked]> writes:

> I'm particularly interested to know what URI schemes have been
> implemented for these protocols.

The Mercurial version control uses uri's like

  ssh://shell.gmplib.org//home/hgfiles/gmp

where the extra slash before /home means that it's an absolute filename.
An uri's without it, e.g.,

  ssh://shell.gmplib.org/hack/private-gmp-hack

refers to a repository under my home directory (i,e.,
$HOME/hack/private-gmp-hack). 

I imagine other modern version control systems do something similar. The
meaning is loosely: Identify a particularly directory, which is
accessible by means of an ssh connection. In most or all cases, the
access would use a session channel and an "exec" request.

This is the most widespread use of ssh uri's in practice which I am
aware of (and appearantly quite different from what's described in the
SSH URI draft).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: [email-masked]
Date: Fri, 19 Nov 2010 08:39:49 -0600

>   ssh://shell.gmplib.org//home/hgfiles/gmp

So there's a path after the host part and that path represents a command 
or file or path to repository, etc?  You're correct in that a non-empty 
path element is not ignored in this draft.  A parameter should be 
used for this instead otherwise it seems rather unclear what's supposed 
to happen with that path element outside of the context of the 
application-specific usage.

As a side note, why wouldn't the scheme use a . to indicate a relative 
reference (as recommended RFC 3986)?

Steve

---

From: [email-masked] (Niels Möller)
Date: Mon, 22 Nov 2010 12:35:27 +0100

[email-masked] writes:

> or file or path to repository, etc?

It's a path to the repository, which is implemented a directory in the
file system. It is passed as a command line argument to the process
started on the remote machine (and the actual command to use, hg
--server or whatever, is implicit, and I agree it's a good decision not
to encode it into the uri. Would make some sense as an optional
parameter, though).

> A parameter should be used for this instead otherwise it seems rather
> unclear what's supposed to happen with that path element outside of
> the context of the application-specific usage.

Is there any other reasonable interpretation of a path-element than as a
name in the filesystem hierarchy on the ssh server? That said, this
syntax was of course designed for use in a specific application. And I
don't know if you want the standard ssh uri's being designed to cover
the use case of identifying to a particular directory on a particular
server.

> reference (as recommended RFC 3986)?

What would that look like?

  ssh://shell.gmplib.org/./hack/private-gmp-hack

for a path relative to my home directory, and

  ssh://shell.gmplib.org/home/hgfiles/gmp

for an absolute file name? Are there any example where this syntax is
used? To me, it seems counter intuitive, but that is mostly because I'm
used to "/./" being equivalent to just "/"; I'm not familiar with
RFC3986 conventions for anchoring the path.

(And I'm just a mercurial user. I find its use of ssh uri's reasonable,
but I wasn't involved in any way when the used syntax was discussed or
decided).

Regards,
/Niels