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 added > [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 address? > [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 of > [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. > fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63-87@xxxxxxxxxxxxxxxx > > I would have expected > > md5-fingerprint=c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63-87@xxxxxxxxxxxxxxxx > > I was surprised to see the c-param added to the user instead of the right hand side of URI > > so Instead of > ssh://user;foo=bar@xxxxxxxxxxx > > I would have expected > ssh://user@xxxxxxxxxxx;foo=bar > [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 "useFooMode=1" > [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@hostname:port which is useful for SSH. > GIven a major use of SSH is SCP, I wish this URI worked for file paths as well > [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: ietf-ssh@xxxxxxxxxx > > 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@xxxxxxxx mailing lists by 2010-12-15. Exceptionally, comments may be >> sent to iesg@xxxxxxxx instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-salowey-secsh-uri/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-salowey-secsh-uri/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf