Hi, I have two points to make on the draft. They relate to the SRV owner name as envisaged by this draft and to the requirements for SRV targets. Firstly, this draft appears to use different semantics for the domain name of an SRV RR than those in RFC2782. My reading of 2782 is that the ``name'' portion of the RR owner (i.e. the name component of _service._protocol.name) is analogous to the server name the client wants to contact. Without SRV records, if I wish to use whois to talk to a server named whois.isp.net I should lookup the A record of whois.isp.net and contact that host. With SRV I should lookup the SRV of _whois._tcp.whois.isp.net and contact the host specified by the A record owned by the SRV target. If I were the operator of a whois server whose published name was ``whois.isp.net'' I might have the following in the isp.net zone to support that second scenario: $ORIGIN isp.net. _whois._tcp.whois IN SRV 10 0 43 dbserver.isp.net. IN SRV 20 0 43 dbbackup.isp.net. dbserver IN A 10.10.10.1 dbbackup IN A 10.20.20.1 SRVs are for adding indirection (amongst other features) to the names people type into browser address bars, MUA configurations and -h options to their whois clients. This draft changes the semantic meaning of the SRV ``name'' when used in a whois context to be ``a whois query string, or a domain above it in the DNS tree''. 2782 says if you want to contact host foo for service X over protocol Y, then lookup "_X._Y.foo IN SRV". This draft says if you want to send a query ABOUT foo to a whois server, lookup "_whois._tcp.foo IN SRV". The semantic meaning of ``foo'' has changed and that change is not explicitly stated. I would like it to be. Secondly, I feel a reminder that the target of an SRV must have an A RR is in order. Taking my isp.net example, above, again. If I controlled customer.com and wanted to use the mechanism in this draft to publish the fact that customer.com is in isp.net's whois server I cannot use: _whois._tcp.customer.com. IN SRV 10 0 43 whois.isp.net. as ``whois.isp.net'' does not have an A RR. I must ``undo'' the name indirection desired by isp.net and instead publish the following RRs (and keep them up to date): _whois._tcp.customer.com. IN SRV 10 0 43 dbserver.isp.net. IN SRV 20 0 43 dbbackup.isp.net. As an aside, when this was first mooted some years ago I wrote a SRV-aware whois client which implemented the mechanism is this draft. Recently I decided it made much more sense to have a SRV whois client that used SRVs in the way I think 2782 intended. My client does SRV processing on the ``server name''. Since this draft appeared I integrated both modes of operation. The support for this draft is referred to as ``wacky mode'' - no offence is intended :-) If anybody wants to play with it, it's at http://romana.now.ie/software/srv-whois Written in perl, requires Net::DNS. More testing would be great as would comments. Example: whois-srv -h whois.denic.de www.foo.de will do - SRV query for _whois._tcp.whois.denic.de and contact the target - If no SRV, do A query for whois.denic.de -- i.e. act as a normal client whois-srv -W -h whois.denic.de www.foo.de will do - SRV query for _whois._tcp.www.foo.de and contact the target - If no SRV, contact target of the _whois._tcp.foo.de SRV - If no SRV, contact target of the _whois._tcp.de SRV - If no SRV, do A query for whois.denic.de -- i.e. act as a normal client Regards, james