Thanks for the speedy review, some comments and questions inline below:
On Nov 17, 2010, at 12:25 PM, Cullen Jennings wrote:
Several things in this draft surprised me a bit thought nothing looked
completely broken. I
You need an IANA registry for the parameters and a way new parameters get
[Joe] OK, Although I think this was more important when the draft also covered
SFTP, I'm not sure that an SSH terminal session needs additional parameters,
but I'm sure someone will think of something.
Do you need to say anything about encoding when the host name is an IPv6
[Joe] I believe this is taken care of in RFC 3986, but I'll look into this.
It says the fingerprint is in 4716 format but the examples have ssh-dss in
them that does not look like that format. I would have expected they type of
the fingerprint to be on the left not the right of the equal sign so instead
[Joe] ssh-dss is actually the public key algorithm of the hey (ssh-rsa,
ssh-dss, etc.) represented by Host-key-alg and not the type of fingerprint.
An ssh server may have more than one host key for supporting different
algorithms. The hash for the fingerprint is defined in 4716 and is set to MD5.
Maybe we should move away from 4716 so we can have hash agility in the way you
show below. I believe we had some limited discussion of this in the past, but
that was a while ago.
I would have expected
I was surprised to see the c-param added to the user instead of the right
hand side of URI
so Instead of
I would have expected
[Joe] we had some discussion of this previously and I believe it was the other
way at some point. I couldn't find a resolution so I left it as it was.
Looking at it now, It seems like belongs on the right hand side of the URI
since is is not about the user, but parameter is about the resource.
I was surprised that the c-param required the equal so I can not have a
parameter like "useFooMode" but must instead have a parameter like
[Joe] I'm not sure why we did it that way. If it aligns with current practice
we should change it.
I'd be interesting hearing the logic or why the "//" - I'll point out XMPP,
SIP, email, etc don't see to have this
[Joe] The main reason is that telnet does. It seems that the "//" allows you
to define an authority component that consists of user(_at_)hostname:port which
is useful for SSH.
GIven a major use of SSH is SCP, I wish this URI worked for file paths as
[Joe] There are multiple SSH file xfer protocols: Sftp and scp. These were
originally covered in the draft, but there was no stable reference for them so
I decided to defer them to another document. I was thinking they would have
their own URI schemes.
The draft says
This document is discussed on the IETF SSH list:
I realize that was the list for the closed WG but I don't think that is an
IETF list. It is not under IETF rules and is not
listedhttp://www.ietf.org/list/nonwg.html. I would highly suggest moving the
conversation to an IETF list.
[Joe] OK, that is the old SSH WG list which is still active. I guess we can
discuss on the IETF list unless there is another one that is more appropriate.
On Nov 17, 2010, at 11:58 AM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH)'
<draft-salowey-secsh-uri-00.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2010-12-15. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
The file can be obtained via
IESG discussion can be tracked via
No IPR declarations have been submitted directly on this I-D.
IETF-Announce mailing list
Ietf mailing list