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

John Tamplin <jat@google.com> Fri, 22 July 2011 02:45 UTC

Return-Path: <jat@google.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 03FD111E8086 for <hybi@ietfa.amsl.com>; Thu, 21 Jul 2011 19:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.952
X-Spam-Level:
X-Spam-Status: No, score=-105.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 hO7REVdHVgsk for <hybi@ietfa.amsl.com>; Thu, 21 Jul 2011 19:45:40 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3B511E8075 for <hybi@ietf.org>; Thu, 21 Jul 2011 19:45:40 -0700 (PDT)
Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p6M2jdJe020894 for <hybi@ietf.org>; Thu, 21 Jul 2011 19:45:39 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311302739; bh=ltAjm2zKw9+y8/AdWc7/vIg9Wxc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=uBbEWaW+/WFW4BMnRryau6GmASH/GXOxy/rJ/BSqdFDjL8dVdmDmp7V77kwEQYuij MJB7GQ6/gmDo/jdaxtolA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=W/QBWN61PGZfe1WAQb7ypnVBVX/S2x+fT2x6cM3J0n+r1P0sd/TT/T/lN1Ud1Zann 0gIf/BzexwUEN0pPhbGGw==
Received: from gxk27 (gxk27.prod.google.com [10.202.11.27]) by hpaq1.eem.corp.google.com with ESMTP id p6M2jO6M012728 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Thu, 21 Jul 2011 19:45:37 -0700
Received: by gxk27 with SMTP id 27so1698886gxk.1 for <hybi@ietf.org>; Thu, 21 Jul 2011 19:45:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=a8PlHfCYyrvGzfaLNG3vTG7r+cS6UBlYIEuVZyvPzDQ=; b=EHlZD57a8yaF8MDsaXdUYdjUuY/Qn0MtfH97MZOYUyX4Fe5i6BgqazlLBzCBK1sWhe pSbKdD1/JoROOX31mS5A==
Received: by 10.151.88.21 with SMTP id q21mr1390171ybl.173.1311302737502; Thu, 21 Jul 2011 19:45:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.49.7 with HTTP; Thu, 21 Jul 2011 19:45:17 -0700 (PDT)
In-Reply-To: <CAP992=GedTEfimykCWwdwm=BsZdwFRJO36EO0a_o7iejURJ+tQ@mail.gmail.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> <CAP992=GedTEfimykCWwdwm=BsZdwFRJO36EO0a_o7iejURJ+tQ@mail.gmail.com>
From: John Tamplin <jat@google.com>
Date: Thu, 21 Jul 2011 22:45:17 -0400
Message-ID: <CABLsOLA_QiFMVSBL6dhHLkAjfApEe2i_xg7JafA3pxt1oCHt7w@mail.gmail.com>
To: David Endicott <dendicott@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
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:45:41 -0000

On Thu, Jul 21, 2011 at 10:24 PM, David Endicott <dendicott@gmail.com> wrote:
> 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.

How about some language like "SHOULD use SRV records to locate the
host unless specifically configured for an alternate name resolution
method"?  I think that leaves open the possibility for clients that
know better to do so, but strongly encourages most client
implementations to use SRV records.

-- 
John A. Tamplin
Software Engineer (GWT), Google