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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf