[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(_at_)ietf(_dot_)org
[mailto:hybi-bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/hybi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf