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

Iñaki Baz Castillo <ibc@aliax.net> Wed, 20 July 2011 21:13 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C032A21F858D; Wed, 20 Jul 2011 14:13:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.668
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9X-Imp+LYnn; Wed, 20 Jul 2011 14:12:53 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (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 10.229.105.95 with SMTP id s31mr7305586qco.228.1311196373066; Wed, 20 Jul 2011 14:12:53 -0700 (PDT)
Received: by 10.229.185.195 with HTTP; Wed, 20 Jul 2011 14:12:52 -0700 (PDT)
In-Reply-To: <9031.1311082001.631622@puncture>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <CALiegfk0zVVRBbOP4ugsVXKmcLnryujP6DZqF6Bu_dC2C3PpeQ@mail.gmail.com> <9031.1311082001.631622@puncture>
Date: Wed, 20 Jul 2011 23:12:52 +0200
Message-ID: <CALiegfk_GLAhAf=yEe6hYw2bwtxEwg9aJN+f0Bm9he5QgsRavA@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Dave Cridland <dave@cridland.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP <hybi@ietf.org>, IETF-Discussion <ietf@ietf.org>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2011 21:13:05 -0000

2011/7/19 Dave Cridland <dave@cridland.net>:
>> Hi, I assume there is no interest in making DNS SRV mechanism exposed
>> in http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 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 (www.facebook.com 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.

Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>