2011/7/21 David Endicott <dendicott@xxxxxxxxx>: > Yes, those are all excellent reasons to use DNS SRV. None of them are a > reason to mandate that WS require it. Because something is good for some > (or many) use cases, does not mean it is appropriate for everything and > certainly is not a reason to mandate it as a requirement. Hi David, I will be away for some days until I can read all the new mails in this thread (I'll do it and will reply in a few days). In the meanwhile I strongly ask you to read the draft about DNS SRV in WebSocket: http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 Sepecially some sections: 1. Introducion [...] DNS SRV mechanism facilitates network applications scalability without requiring an intermediary node distributing the traffic in load-balancing or failover fashion. Instead, DNS SRV mechanism just requires a proper DNS setup. By introducing DNS SRV records into WebSocket protocol [I-D.ietf-hybi-thewebsocketprotocol], WebSocket providers can, optionally, take same advantages and provide scalable services with a minimal infrastructure. This specification mandates the usage of DNS SRV resource records by WebSocket clients when resolving a "ws:" or "wss:" URI [RFC3986], but still leaves the decision of using SRV records up to the service administrator. 3. Implementation [...] It is up to the system administrator whether to set, or not, DNS SRV resource records for the WebSocket protocol within the provided service. This specification allows the system administrator to use the DNS SRV [RFC2782] mechanism to improve the service reliability by providing load-balancing and failover capabilities, but does not mandate it (the system administrator could choose whichever scalability strategy). Section 4 "Client Usage" in which is shown how the WS client should perform SRV resolution just in case the WS URI is a domain and no port is present in the URI: To clarify it, a WebSocket URI like "ws://example.org/myservice" requires the client to perform SRV resolution while "ws://example.org:80/myservice" does not (as the port is explicitly present in the URI). step 3: If there is no SRV result, attempt the fallback process described in Section 4.2 and omit next steps. 4.2. Fallback Process The fallback process SHOULD be a normal A or AAAA address record resolution to determine the IPv4 or IPv6 address of the URI host component (or URI host value without DNS resolution if it contains an IP address). The server connection port is obtained as stated in Section 3.1 of [I-D.ietf-hybi-thewebsocketprotocol]. NOTE: The section 3.1 has changed in the new WS draft. It pointed to http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06#section-3.1 (3.1. Parsing WebSocket URIs) Also, the section 5 (Examples) should clarify it even more. Regards. -- Iñaki Baz Castillo <ibc@xxxxxxxxx> _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf