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

[Gabriel Montenegro <[e-mail]>]

[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: [e-mail] [mailto:[e-mail]] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi