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...@host.example.com
> 
> I would have expected 
> 
> md5-fingerprint=c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63...@host.example.com
> 
> 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;[email protected]
> 
> I would have expected
> ssh://[email protected];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 u...@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: [email protected]
> 
> 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
>> [email protected] mailing lists by 2010-12-15. Exceptionally, comments may be
>> sent to [email protected] 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> 

_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to