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

Iñaki Baz Castillo <> Tue, 19 July 2011 11:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0654321F852C; Tue, 19 Jul 2011 04:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.667
X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=0.010, 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 YE25rGLggnlr; Tue, 19 Jul 2011 04:51:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 35D4F21F8512; Tue, 19 Jul 2011 04:51:16 -0700 (PDT)
Received: by qyk29 with SMTP id 29so3066487qyk.10 for <multiple recipients>; Tue, 19 Jul 2011 04:51:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id br1mr6519477qab.222.1311076276487; Tue, 19 Jul 2011 04:51:16 -0700 (PDT)
Received: by with HTTP; Tue, 19 Jul 2011 04:51:16 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 19 Jul 2011 13:51:16 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Tue, 19 Jul 2011 11:51:18 -0000

2011/7/11 The IESG <>rg>:
> The IESG has received a request from the BiDirectional or
> Server-Initiated HTTP WG (hybi) to consider the following document:
> - 'The WebSocket protocol'
>  <draft-ietf-hybi-thewebsocketprotocol-10.txt> as a Proposed Standard

Hi, I assume there is no interest in making DNS SRV mechanism exposed
in part of
the WebSocket core specification, neither referencing it (in the same
way RFC 3261 "SIP protocol" mandates the usage of RFC 3263 "Locating
SIP servers").

As said before, making such DNS SRV specification an extension (so
present in other document) will mean no success at all, as WebSocket
client implementors (i.e. webbrowser vendors) will not be mandated to
implement it and service providers could not rely on the support of
DNS SRV in web browsers. So nobody will use them (because IE10 decided
not to implement it, for example). IMHO this is sad due the real
advantages DNS SRV provides for a protocol like WebSocket.

Yes, in HTTP there is no special DNS stuff, all the load-balancing and
failover mechanism are done at server side with very complex and
expensive solutions ( resolves to a single IPv4 !!!!).
The question is: should we also inherit every HTTP limitation in


Iñaki Baz Castillo