[hybi] Alternative for SRV proposal

Iñaki Baz Castillo <ibc@aliax.net> Sun, 24 July 2011 19:17 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 16B5F21F8586 for <hybi@ietfa.amsl.com>; Sun, 24 Jul 2011 12:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.646
X-Spam-Level:
X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, 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 90FlHmQSWukt for <hybi@ietfa.amsl.com>; Sun, 24 Jul 2011 12:16:59 -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 5B58121F856A for <hybi@ietf.org>; Sun, 24 Jul 2011 12:16:59 -0700 (PDT)
Received: by qyk9 with SMTP id 9so673509qyk.10 for <hybi@ietf.org>; Sun, 24 Jul 2011 12:16:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.66.25 with SMTP id l25mr2782603qci.265.1311535018769; Sun, 24 Jul 2011 12:16:58 -0700 (PDT)
Received: by 10.229.185.195 with HTTP; Sun, 24 Jul 2011 12:16:58 -0700 (PDT)
Date: Sun, 24 Jul 2011 21:16:58 +0200
Message-ID: <CALiegfni83KAFTeo1vo_XLmLhVSAR_BxYwLoSkOizJ1ToHfqhw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: hybi@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [hybi] Alternative for SRV proposal
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: Sun, 24 Jul 2011 19:17:00 -0000

Hi, it's clear enough for me that DNS SRV will be not implemented in
web browsers for WebSocket URIs resolution. I understand some of the
reasons (not all however).

So I'm thinking about a future (extension) for WebSocket protocol and
API (sorry, I don't know yet the propose WS API so I use pseudo-code):


a) Let's suppose a JavaScript code contains a WS connection, something
like this:

    var mysocket = new WebSocket("ws://www.mydomain.org", null);

Note that there is a second parameter that is null. It would mean (as
the current spec states) that a DNS A query should be performed for
the given URI (or not if there is already a TCP connection).


b) I propose an optional second argument:

    var mysocket = new WebSocket("ws://www.mydomain.org", "ws://mydomain.org");

If the browser supports the new WS extension I'm suggesting, the
browser could *decide* whenever perform DNS A for the first URI or a
DNS SRV for the second URI. For example, WS clients within mobile
devices could decide to always use the first URI so just DNS A would
be done (or not if it was already resolved and connected). In the
other side, desktop web browsers implementing this new extension would
use, by default, the second URI with all the SRV stuff.



I don't like it too much as the service provider cannot anticipate how
clients would resolve the WS server, but for me is better than just
playing with A records and server side failover / load-balancing.


Regards.



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