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.
Agree.
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.
Well, "MUST is for implementors", so YMMV.
RFC2782 doesn't seem to offer any guidance about which protocols should use SRV, and which shouldn't.
Correct. It doesn't offer a lot of guidance to protocol designers as to when it makes sense to specify the use of SRV records and when it does not. IMHO, SRV records are appropriate for services where you're likely to want to find a canonical instance of a service for a particular site (such as Kerberos KDC's), or where service may be provided by a set of redundant machines (such as mail exchangers). It doesn't make sense for host-directed interactive services like telnet and ssh, except perhaps in a small number of cases.
The guidance that RFC2782 _does_ provide is to implementors, particularly of clients -- it RECOMMENDs that SRV records not be used unless specified.