> I don't think explicitly specifying port 22 in all cases > where the URL doesn't specify a port number is correct; what > about SRV DNS records? [Joe] So the suggestion would be something like: If the URL doesn't specify a port number the it should check for a SRV DNS record if it is available, if it is not then it should use port 22.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. For most (all?) ssh clients, that means connecting to port 22.
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.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA