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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf