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

Gabriel Montenegro <> Fri, 22 July 2011 00:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51CCC21F8782; Thu, 21 Jul 2011 17:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lOM8gJiaAt7g; Thu, 21 Jul 2011 17:14:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8B52921F877D; Thu, 21 Jul 2011 17:14:27 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 21 Jul 2011 17:14:26 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.2; Thu, 21 Jul 2011 17:14:26 -0700
Received: from ([]) by ([]) with mapi id 14.01.0289.008; Thu, 21 Jul 2011 17:14:26 -0700
From: Gabriel Montenegro <>
To: Bruce Atherton <>, Dave Cridland <>
Thread-Topic: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
Thread-Index: AQHMR8o7lHZOnlMp5E682blrKHSyH5T3gDEAgAADn4CAAAJFgIAARziAgAABb4CAABgwgP//kMyw
Date: Fri, 22 Jul 2011 00:14:25 +0000
Message-ID: <>
References: <> <> <9031.1311082001.631622@puncture> <> <> <> <> <> <9031.1311270000.588511@puncture> <> <> <> <9031.1311286867.939466@puncture> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Server-Initiated HTTP <>, IETF-Discussion <>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jul 2011 00:14:28 -0000

[As an individual]

I think the lack of DNS SRV for HTTP could also be because of the guidance in 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: [] 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