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

Iñaki Baz Castillo <> Sun, 24 July 2011 10:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5FFC21F8B3E; Sun, 24 Jul 2011 03:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e5wSSuRZESy3; Sun, 24 Jul 2011 03:55:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0A79D21F858D; Sun, 24 Jul 2011 03:55:03 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2666902qwc.31 for <multiple recipients>; Sun, 24 Jul 2011 03:55:03 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id y36mr2545325qce.227.1311504903091; Sun, 24 Jul 2011 03:55:03 -0700 (PDT)
Received: by with HTTP; Sun, 24 Jul 2011 03:55:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <9031.1311082001.631622@puncture> <> <> <> <> <> <9031.1311270000.588511@puncture> <> <> <> <9031.1311286867.939466@puncture> <>
Date: Sun, 24 Jul 2011 12:55:02 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: Bruce Atherton <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Sun, 24 Jul 2011 10:55:04 -0000

2011/7/22 Bruce Atherton <>om>:

> 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.

Should a new protocol loose cool features just because "most people"
expect a domain to be mapped to a single IP always?

> 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.

You can do it serially (first SRV then A). We are speaking about a few
miliseconds just during the WS connection, no more. In SIP and XMPP
(real *realtime* protocols with IM and voice) this is not a problem.

> As I understand it, the issue that caused the various drafts for HTTP SRV to
> die without getting much traction is one of efficiency.

Could you point to any reference for such a conclusion?

I really think the problem of SRV in HTTP is the fact the HTTP was
already extended when SRV appeared and migration was unfeasible.

> 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.

How is possible that using DNS SRV (and also DNS NAPTR in SIP !!) is
not "inefficient" for SIP and XMPP ***realtime*** protocols?


Iñaki Baz Castillo