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

David Endicott <dendicott@gmail.com> Fri, 22 July 2011 02:24 UTC

Return-Path: <dendicott@gmail.com>
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 B71B811E8084; Thu, 21 Jul 2011 19:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.57
X-Spam-Level:
X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TSqy8oGZc4RT; Thu, 21 Jul 2011 19:24:44 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5411E8086; Thu, 21 Jul 2011 19:24:43 -0700 (PDT)
Received: by wyj26 with SMTP id 26so1390178wyj.31 for <multiple recipients>; Thu, 21 Jul 2011 19:24:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YosTWudxZhl41afZ8BuiYgAhdogQL1JLIWiYK2WLJU8=; b=vIiUVG+zPlASIvu7VIU3fuN852SHN55IG/3CuoWreNuVnJxJd+oSBvj8r6bCgiciRR Fc8eufT9GI0fjZmQA+/AIzzp72WZNNlBaRmney5Z3Erym+1uQj78ABhzmcS5WXPg+jDS KkAhLI6hlq5jKH1m5BU3GEX7uad3jGz9p1Zq4=
MIME-Version: 1.0
Received: by 10.216.79.18 with SMTP id h18mr861927wee.3.1311301482527; Thu, 21 Jul 2011 19:24:42 -0700 (PDT)
Received: by 10.216.39.197 with HTTP; Thu, 21 Jul 2011 19:24:41 -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: Thu, 21 Jul 2011 22:24:41 -0400
Message-ID: <CAP992=GedTEfimykCWwdwm=BsZdwFRJO36EO0a_o7iejURJ+tQ@mail.gmail.com>
From: David Endicott <dendicott@gmail.com>
To: Bruce Atherton <bruce@callenish.com>
Content-Type: multipart/alternative; boundary="000e0ce0b4f00f3d8404a89f2b39"
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: Fri, 22 Jul 2011 02:24:44 -0000

On Thu, Jul 21, 2011 at 7:47 PM, Bruce Atherton <bruce@callenish.com> wrote:

>
> As I understand it, the issue that caused the various drafts for HTTP SRV
> to die without getting much traction is one of efficiency. 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.
>
> Hmm, I seem to be arguing myself out of supporting DNS SRV as the preferred
> location mechanism. That is not the case. I just think that we face some of
> the same challenges migrating Websockets to SRV as are faced by HTTP because
> we share the same environment for the most part. Willy's example of a proxy
> that doesn't know how to resolve host names using the SRV method is a good
> example. But by advocating for the deployment of SRV records as a best
> practice for Websockets, we may improve things in the HTTP world as well. It
> is a shame there is no standard defined for HTTP SRV to point to.
>

I find myself reminded of my reservations about HTTP Upgrade as the opening
handshake.  It is clever, efficient and reflects some of the shared nature
between HTTP and WS.   However, I felt it should be considered one of
several mechanisms for opening a WS connection, one especially suited for
a co-mingled environment.   But not explicitly the only such method.  (I was
unable to convince many of my position on that, so I could very well be in
the minority about this issue as well)    I think DNS SRV is in a similar
area.   It's a useful technology that if the client uses could be of
benefit.   I'm just not convinced there is overwhelming cause to make it a
mandatory requirement.    Saying that nobody will use it if it's not
legislated does not strike me as a good enough reason.   The technological
advantages are worthy, when it's used, but when it doesn't come into play,
there are added inefficiencies.   Also the name resolution of the HTTP that
serves the Javascript that opens the WS should remain constant.   If WS
resolves the host/domain to a different address than the HTTP it was spawned
from, it becomes a method to bypass same-origin / CORS restrictions.

I favor a minimalist core with extensibility.    Name resolution happens
before the WS opening handshake, so I continue to see this as outside the
domain of the WS protocol.   I would prefer that name resolution be provided
by a selectable method.  That way, in 20 years, when name resolution needs
have again changed, we'll have the ability to adapt.