[As an individual] I think the lack of DNS SRV for HTTP could also be because of the guidance in http://wiki.tools.ietf.org/html/draft-iab-dns-applications-02#section-4 that argues that DNS might not be the best approach for *all* HTTP applications. Perhaps also for WS applications... It could be a good alternative to have, so I agree with pursuing it as a separate option in a different document. > -----Original Message----- > From: hybi-bounces@xxxxxxxx [mailto:hybi-bounces@xxxxxxxx] On Behalf Of > Bruce Atherton > Sent: Thursday, July 21, 2011 16:48 > To: Dave Cridland > Cc: Server-Initiated HTTP; IETF-Discussion > Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The > WebSocket protocol) to Proposed Standard > > 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. > > _______________________________________________ > hybi mailing list > hybi@xxxxxxxx > https://www.ietf.org/mailman/listinfo/hybi _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf