[hybi] New port and Tunneling?

"Shelby Moore" <shelby@coolpage.com> Sun, 15 August 2010 20:48 UTC

Return-Path: <shelby@coolpage.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 3C68B3A67C3 for <hybi@core3.amsl.com>; Sun, 15 Aug 2010 13:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.561
X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_50=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id QbV6M5Q+YP-Z for <hybi@core3.amsl.com>; Sun, 15 Aug 2010 13:48:00 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com []) by core3.amsl.com (Postfix) with SMTP id F22A93A66B4 for <hybi@ietf.org>; Sun, 15 Aug 2010 13:47:59 -0700 (PDT)
Received: (qmail 23648 invoked by uid 65534); 15 Aug 2010 20:48:35 -0000
Received: from ([]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Sun, 15 Aug 2010 16:48:35 -0400
Message-ID: <7ffabb591b2292c9b81abecfaec3cdb6.squirrel@sm.webmail.pair.com>
Date: Sun, 15 Aug 2010 16:48:35 -0400
From: "Shelby Moore" <shelby@coolpage.com>
To: hybi@ietf.org
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: [hybi] New port and Tunneling?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shelby@coolpage.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 15 Aug 2010 20:48:01 -0000

I googled this discussion list archive and did not find much on this.

Seems the great likelihood of messy soft failure and other a priori
unquantifiable complexity with reusing the port 80 or 443+TLS due to the
HTTP legacy on the network and/or complexity issues with HTTP Upgrade or
non-mainstream use of TLS.

Seems what we really need is a hard fail, so we can dynamically and
gracefully downgrade to long polling solutions (Comet/BOSH...).  K.I.S.S.

We are going to have to downgrade whether due to proxy soft failure or new
port tunnel failure, so why chose the higher complexity "root canal"

Am I missing something or is the K.I.S.S.  way to get a hard fail is
tunnel over a new port?  Then we can get P2P WebSockets too (wow)!


FAQ at the above link seems to be pretty simple and deterministic in terms
of failure detection.

The man-in-middle vulnerability and the beneficial features of HTTP (e.g.
URL redirection, virtual hosting,...) could still be obtained by
handshaking orthogonally with standard HTTP GET.

Educate me please.  Certainly the solution can't be this simple correct? Why?

(4:45am and 45 years old, good nite)