2011/7/19 Dave Cridland <d...@cridland.net>: >> Hi, I assume there is no interest in making DNS SRV mechanism exposed >> in http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 part of >> the WebSocket core specification, neither referencing it (in the same >> way RFC 3261 "SIP protocol" mandates the usage of RFC 3263 "Locating >> SIP servers"). >> >> As said before, making such DNS SRV specification an extension (so >> present in other document) will mean no success at all, as WebSocket >> client implementors (i.e. webbrowser vendors) will not be mandated to >> implement it and service providers could not rely on the support of >> DNS SRV in web browsers. So nobody will use them (because IE10 decided >> not to implement it, for example). IMHO this is sad due the real >> advantages DNS SRV provides for a protocol like WebSocket. >> >> Yes, in HTTP there is no special DNS stuff, all the load-balancing and >> failover mechanism are done at server side with very complex and >> expensive solutions (www.facebook.com resolves to a single IPv4 !!!!). >> The question is: should we also inherit every HTTP limitation in >> WebSocket? > > I agree wholeheartedly with this, and strongly recommend that mandatory use > of SRV is included in the core protocol. > > I think with HTTP's very short lived requests, then it's possible to work > around the lack of SRV support (at a cost), but the benefit is markedly > higher with the long-lived, stateful sessions we're anticipating with > WebSocket.
Unfortunaltely it seems that the debate about DNS SRV support does not interest to the core WG authors. I would like, at least, to receive good arguments not to include/mandate DNS SRV support in the draft. If not, the proposal is just being ignored with no reason. Regards. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
