Saku Ytti wrote: >> Sorry, browser is just an example and any application using domain >> names can support SRV to avoid default port numbers contaminated by >> ALGs. See below for examples of mail and name applications. > > Friends of SRV should read > https://tools.ietf.org/html/draft-lear-httpbis-svcinfo-rr-01 The problem of SRV-like proposals is that they have too much features not needed by most applications, among which, SRV is least painful. If I design a new RR, it would be: _<port>._<proto>.<domain> REDIRECT <altdomain> <altport> where <port> and <proto> are in decimal. > a) if we add SRV to browsers, we need to do +3 DNS lookup per resource > 'for ever', With example.com MX 0 mx.example.com _mx._tcp.mx.example.com SRV 0 0 1000 mx0.example.com only one DNS lookup is enough by answers with additional records, which can be safely cached. > SRVINFO will allow for 1 ultimately. >From an implementer's point of view, fancy fields of <InstanceId> and <Profile> are enough to abandon SRVINFO and URI is worse than that because most applications can not treat most fields of generic URIs. > b) it can announce all the transport protocols you're supporting Yes, all the transport protocols and all the services of a domain, which are announced by SRVINFO RR of the domain. That is a fatal defect of SRVINFO (and URI), because, if a domain support 100 services with 2 transport protocols, there are 200 RRs, all of which must be replied for a single query, which is unacceptably inefficient, which is why it is necessary to use a service specific domain name for each service. All the applications know which service they are offering and almost all, if not all, applications including DNS, know which transport protocol they are currently trying to use. Masataka Ohta