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

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

> > 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.
>
> Indeed, the behavior should be exactly as if the user ran the ssh client 
> 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.

> 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.

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?