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

Iñaki Baz Castillo <> Wed, 20 July 2011 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C032A21F858D; Wed, 20 Jul 2011 14:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.668
X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=0.009, 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 z9X-Imp+LYnn; Wed, 20 Jul 2011 14:12:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9ABA321F851A; Wed, 20 Jul 2011 14:12:53 -0700 (PDT)
Received: by qyk9 with SMTP id 9so3790574qyk.10 for <multiple recipients>; Wed, 20 Jul 2011 14:12:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id s31mr7305586qco.228.1311196373066; Wed, 20 Jul 2011 14:12:53 -0700 (PDT)
Received: by with HTTP; Wed, 20 Jul 2011 14:12:52 -0700 (PDT)
In-Reply-To: <9031.1311082001.631622@puncture>
References: <> <> <9031.1311082001.631622@puncture>
Date: Wed, 20 Jul 2011 23:12:52 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: Dave Cridland <>
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: Wed, 20 Jul 2011 21:13:05 -0000

2011/7/19 Dave Cridland <>et>:
>> 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
>> WebSocket?
> I agree wholeheartedly with this, and strongly recommend that mandatory use
> of SRV is included in the core protocol.
> I think with HTTP's very short lived requests, then it's possible to work
> around the lack of SRV support (at a cost), but the benefit is markedly
> higher with the long-lived, stateful sessions we're anticipating with
> WebSocket.

Unfortunaltely it seems that the debate about DNS SRV support does not
interest to the core WG authors. I would like, at least, to receive
good arguments not to include/mandate DNS SRV support in the draft. If
not, the proposal is just being ignored with no reason.


Iñaki Baz Castillo