2011/7/21 Willy Tarreau <w@xxxxxx>: > I understand the point David is making. DNS is something independant of > WS and conversely. It is one way of resolving addresses, just like there > will be people using hosts files. At no place the protocol specification > dictates how a client should resolve a name to an IP address. The protocol > specifies the transport part only. Host files just replace A/AAAA resolution. Still is possible to query SRV records and later perform hostfiles check for retrieved hostnames (instead of performing DNS A/AAAA for them). > This is the same for other protocols. For instance, neither FTP nor HTTP > explain how a client is supposed to resolve a host name, still the later > explains how to parse a URI. Maybe because DNS SRV born later than FTP or HTTP. But now look at SIP and XMPP protocols which make *extensive* usage of DNS SRV. And SIP is just a "signaling protocol", you could also consider it a "transport protocol" which transports sessions and other kind of data. It's at the very same level than WS, IMHO. > DNS SRV is a DNS extension which only concerns > resolvers. Not all clients will be using resolvers, just a part of them. > Some others will simply forward the request to their HTTP proxy which will > apply whatever DNS resolving method they know, including possibly DNS SRV. If WS spec does not mandate DNS SRV resolution in WS clients (so webbrowsers mainly) then let's forget SRV balancing/failover capabilities. If the WS core draft does not want to handle this topic, then refer to another document mandating it (in the same way SIP RFC 3261 mandates the usage of DNS NAPTR/SRV in RFC 3263 for SIP clients). So you can split WS in: - transport specification RFC (handshake, frames and so). - location WS servers (a MUST for WS clients when resolving WS URI's). > In practice, if there are new elements of DNS SRV that are specific to WS, > they should probably be added to the DNS SRV spec and not the WS spec. No. DNS SRV spec (RFC 2782) just explains the DNS SRV mechanism. Any protocol can decide wheter to include/mandate it or not. Each protocol can register in IANA new "service" values SRV, in the same way SIP and XMPP RFC's create "sip" and "xmpp-server" values. > Maybe the WS spec should mention that it addresses transport only and > not address resolving. It may recommend to follow some principles to > perform the resolving but should not specify how to do it. That would be great, so another document/spec would *mandate* how WS clients MUST resolve WS destinations. But that is not true now as WS core spec states simple A/AAAA resolution for locating a WS server. Regards. -- Iñaki Baz Castillo <ibc@xxxxxxxxx> _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf