On Fri, Jul 22, 2011 at 01:22:15AM +0200, Iñaki Baz Castillo wrote: > Well, in SIP there are NAPTR records because SIP can work over > different transports (UDP, TCP, TLS-TCP. SCTP, TLS-SCTP). In case of > WebSocket, it just defined for TCP so NAPTR records don't make sense. > > So just SRV is required: > > a) _ws._tcp.DOMAIN.COM for WS URI > b) _wss._tcp.DOMAIN.COM for WSS URI Iñaki, what we're saying is that the resolving applies first to HTTP well before it is WS. For instance, a client could connect to an HTTP server, fetch a few objects, then decide to upgrade the connection to switch to WebSocket. DNS resolving for WS would not even be involved here. I agree with what others have been saying : if/when a different handshake is supported, eg. on a specific port without the HTTP upgrade, then it will make sense. But as of now we're relying on the lower layer. As Greg said it, without a deep change in HTTP you won't be able to make the rule a MUST for WS. However, John's suggest of using a SHOULD when the record exists and the client can see it looks fine. What's the problem if not all of your clients go to the same hosts ? You can even announce all of your servers with A/AAAA and with SRV as well as long as they're running on the same ports. Those who can use SRV just have more information than the other ones and can be served better. Regards, Willy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf