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

Iñaki Baz Castillo <ibc@aliax.net> Sun, 24 July 2011 10:55 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 B5FFC21F8B3E; Sun, 24 Jul 2011 03:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5wSSuRZESy3; Sun, 24 Jul 2011 03:55:04 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (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 10.229.44.36 with SMTP id y36mr2545325qce.227.1311504903091; Sun, 24 Jul 2011 03:55:03 -0700 (PDT)
Received: by 10.229.185.195 with HTTP; Sun, 24 Jul 2011 03:55:02 -0700 (PDT)
In-Reply-To: <4E28BA9D.6010501@callenish.com>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <CALiegfk0zVVRBbOP4ugsVXKmcLnryujP6DZqF6Bu_dC2C3PpeQ@mail.gmail.com> <9031.1311082001.631622@puncture> <CALiegfk_GLAhAf=yEe6hYw2bwtxEwg9aJN+f0Bm9he5QgsRavA@mail.gmail.com> <CAP992=Ft6NwG+rbcuWUP0npwVNHY_znHmXmznBQO_krMo3RT6g@mail.gmail.com> <CALiegfmTWMP3GhS1-k2aoHHXkUkB+eWqV=2+BufuWVR1s2Z-EA@mail.gmail.com> <20110721163910.GA16854@1wt.eu> <CAP992=FrX5VxP2o0JLNoJs8nXXba7wbZ6RN9wBUYC0ZSN_wbAg@mail.gmail.com> <9031.1311270000.588511@puncture> <CALiegf=pYzybvc7WB2QfPg6FKrhLxgzHuP-DpuuMfZYJV6Z7FQ@mail.gmail.com> <CAP992=FJymFPKcPVWrF-LkcEtNUz=Kt9L_ex+kLtjiGjL1T46w@mail.gmail.com> <4E28A51F.4020704@callenish.com> <9031.1311286867.939466@puncture> <4E28BA9D.6010501@callenish.com>
Date: Sun, 24 Jul 2011 12:55:02 +0200
Message-ID: <CALiegfmDB+SyqYXVtnDO+n2KunygVzGvaMJ4vuxb_+J9oRaXdQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Bruce Atherton <bruce@callenish.com>
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: Sun, 24 Jul 2011 10:55:04 -0000

2011/7/22 Bruce Atherton <bruce@callenish.com>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?



Regards.


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