Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 21/07/2011 3:21 PM, Dave Cridland wrote:

SRV lookup is pretty commonplace now in libraries. XMPP and SIP clients have no difficulty finding this functionality in a wide variety of environments. For the web, where there are substantially fewer web browsers than there are XMPP clients, I don't think this would pose any kind of problem.

Oh, it isn't hard, but it violates the principle of least surprise. Most people think they know how to code name resolution by using gethostbyname() or equivalent. And to do it efficiently, especially when we are operating in a world that is predominantly driven by HTTP servers, requires complexities like dealing with asynchronous calls to fetch the A and SRV records at the same time under the assumption that the SRV record probably won't exist.


It can be argued that not using a MUST may well open up interoperability problems because some Websockets clients contact the wrong host. However, keep in mind that in the older SIP RFC2543 it provided two resolution mechanisms. It specified that clients SHOULD look up address records, but MAY use the DNS SRV mechanism. SIP survived that without too much of a hassle. And specifying that Websockets clients SHOULD use DNS SRV, but MAY use address records alone looks like an improvement.


SIP survived because it was very small. I don't see WS making a transition, in the same way that repeated attempts have failed to move HTTP to SRV.

Dave.

As I understand it, the issue that caused the various drafts for HTTP SRV to die without getting much traction is one of efficiency. It is inefficient to make all these extra DNS calls, especially when it is unlikely that many of the records you are blocking on will exist. Other than the inefficiency, HTTP SRV is just an incremental technology you add to your existing DNS without hurting what already exists. Since Websockets uses the same infrastructure the records are unlikely to exist for it either, so the inefficiency issues are still present.

Hmm, I seem to be arguing myself out of supporting DNS SRV as the preferred location mechanism. That is not the case. I just think that we face some of the same challenges migrating Websockets to SRV as are faced by HTTP because we share the same environment for the most part. Willy's example of a proxy that doesn't know how to resolve host names using the SRV method is a good example. But by advocating for the deployment of SRV records as a best practice for Websockets, we may improve things in the HTTP world as well. It is a shame there is no standard defined for HTTP SRV to point to.

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]