Re: WebSocket2

Kari hurtta <hurtta-ietf@elmme-mailer.org> Sat, 01 October 2016 19:41 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23A512B068 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 1 Oct 2016 12:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.017
X-Spam-Level:
X-Spam-Status: No, score=-8.017 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10Bk3TN8Ndg6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 1 Oct 2016 12:41:16 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7E012B03D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 1 Oct 2016 12:41:16 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bqQ5t-00078o-NM for ietf-http-wg-dist@listhub.w3.org; Sat, 01 Oct 2016 19:37:09 +0000
Resent-Date: Sat, 01 Oct 2016 19:37:09 +0000
Resent-Message-Id: <E1bqQ5t-00078o-NM@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <hurtta@siilo.fmi.fi>) id 1bqQ5s-0006sC-Hd for ietf-http-wg@listhub.w3.org; Sat, 01 Oct 2016 19:37:08 +0000
Received: from smtpvgate.fmi.fi ([193.166.223.36]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <hurtta@siilo.fmi.fi>) id 1bqQ5q-0005OB-Ht for ietf-http-wg@w3.org; Sat, 01 Oct 2016 19:37:07 +0000
Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20160114/smtpVgate) with ESMTP id u91Jaa2b012702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 1 Oct 2016 22:36:36 +0300
Received: from shell.siilo.fmi.fi by torkku.fmi.fi with ESMTP id u91Jaa2K026159 ; Sat, 1 Oct 2016 22:36:36 +0300
Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id u91Jaa6m008987 ; Sat, 1 Oct 2016 22:36:36 +0300
Received: by shell.siilo.fmi.fi id u91JaZlG008986; Sat, 1 Oct 2016 22:36:35 +0300
Message-Id: <201610011936.u91JaZlG008986@shell.siilo.fmi.fi>
In-Reply-To: <CAG-EYCiXDYjmZ4r_8q31-UKQBG5=U53xOh1vef3-TJCVuytmdw@mail.gmail.com>
References: <CAG-EYCjx5=tExsjOJ+_-5p95Vp=Wfaz8JihDAAykDQpL64T4TA@mail.gmail.com> <20161001051700.245FA10F65@welho-filter1.welho.com> <CAG-EYCiXDYjmZ4r_8q31-UKQBG5=U53xOh1vef3-TJCVuytmdw@mail.gmail.com>
To: Van Catha <vans554@gmail.com>
Date: Sat, 1 Oct 2016 22:36:35 +0300 (EEST)
Sender: hurtta@siilo.fmi.fi
From: Kari hurtta <hurtta-ietf@elmme-mailer.org>
CC: Kari hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha41]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20161001/54829/01
X-Filter: smtpVgate.fmi.fi: ID 54829/01, 1 parts scanned for known viruses
X-Filter: torkku: ID 15451/01, 1 parts scanned for known viruses
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Sat, 01 Oct 2016 22:36:36 +0300 (EEST)
Received-SPF: none client-ip=193.166.223.36; envelope-from=hurtta@siilo.fmi.fi; helo=smtpVgate.fmi.fi
X-W3C-Hub-Spam-Status: No, score=-7.0
X-W3C-Hub-Spam-Report: AWL=0.049, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.099, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bqQ5q-0005OB-Ht e95161667a12e81d9e76219493cff573
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WebSocket2
Archived-At: <http://www.w3.org/mid/201610011936.u91JaZlG008986@shell.siilo.fmi.fi>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32440
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Van Catha <vans554@gmail.com>om>: (Sat Oct  1 21:20:38 2016)
<...>
> require baking WebSocket2 directly into HTTP/2, the way it is now,
> WebSocket2 should run over HTTP/2 with minimal resistance since we do not
> introduce new settings or HTTP/2 frame types.  HTTP/2 was designed from the
> very beginning to not support 2 way streaming like websocket provides
> currently for HTTP/1.1.  I think the resistance would be great if adding
> WebSocket2 requires adding to the actual HTTP/2 specification.
<...>

I interpreter Settings to be extension point. It does not touch HTTP/2
specification.

Hypertext Transfer Protocol Version 2 (HTTP/2)
https://tools.ietf.org/html/rfc7540

5.5.  Extending HTTP/2
https://tools.ietf.org/html/rfc7540#section-5.5

|   This document doesn't mandate a specific method for negotiating the
|   use of an extension but notes that a setting (Section 6.5.2) could be
|   used for that purpose.  If both peers set a value that indicates
|   willingness to use the extension, then the extension can be used.  If
|   a setting is used for extension negotiation, the initial value MUST
|   be defined in such a fashion that the extension is initially
|   disabled.

11.3.  Settings Registry
https://tools.ietf.org/html/rfc7540#section-11.3

|   This document establishes a registry for HTTP/2 settings.  The
|   "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2
|   Settings" registry operates under the "Expert Review" policy
|   [RFC5226] for values in the range from 0x0000 to 0xefff, with values
|   between and 0xf000 and 0xffff being reserved for Experimental Use.


How something (registeration) which is just "Expert Review" can be considered
to be change of actual HTTP/2 specification ?

/ Kari Hurtta