Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

Mark Nottingham <mnot@mnot.net> Fri, 25 November 2016 02:39 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 1F9B912A202 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Nov 2016 18:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 VxgwOXnPk0m9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Nov 2016 18:39:50 -0800 (PST)
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 0C7AB12A201 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 24 Nov 2016 18:39:50 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cA6NI-0006lx-5t for ietf-http-wg-dist@listhub.w3.org; Fri, 25 Nov 2016 02:36:28 +0000
Resent-Date: Fri, 25 Nov 2016 02:36:28 +0000
Resent-Message-Id: <E1cA6NI-0006lx-5t@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1cA6NA-0006cs-FL for ietf-http-wg@listhub.w3.org; Fri, 25 Nov 2016 02:36:20 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <mnot@mnot.net>) id 1cA6N3-0002nE-H1 for ietf-http-wg@w3.org; Fri, 25 Nov 2016 02:36:15 +0000
Received: from [192.168.4.130] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D52B122E1F3; Thu, 24 Nov 2016 21:35:48 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <1480041123.3044.3.camel@warmcat.com>
Date: Fri, 25 Nov 2016 13:35:45 +1100
Cc: Van Catha <vans554@gmail.com>, Takeshi Yoshino <tyoshino@google.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Wenbo Zhu <wenboz@google.com>, Martin Thomson <martin.thomson@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA373BD5-0C84-42B5-BB49-612C9C9EDA2D@mnot.net>
References: <CAH9hSJZdBJ02+Z6o=aanZ=5PN=9VwyL1ZcX2jct-6f_FFivLGA@mail.gmail.com> <0f79ddf6-c455-c41a-f269-a1bdcef05b14@ninenines.eu> <CAH9hSJb2R9gv2vNqoyTjbMV4hZTYdpX2PoAoYgWUT1UuigLHRA@mail.gmail.com> <5541be74-afcc-6aef-404e-63acb2f608eb@ninenines.eu> <CAH9hSJarsNFqX1tAL7BZmZQwUrEQs1X3wtrAPuMyz8s-k_7WRg@mail.gmail.com> <43998e7b-9227-7562-b2c6-c08134065e22@ninenines.eu> <CAD3-0rPRPzVvYb6_Z4wDZp73L5Kyb7LmE0P5j4A-2VSRwT7FMw@mail.gmail.com> <CAH9hSJb=mWdHP8xcBis8-jhWgQTfN-cgQXVV3eCyT4U8JYQHZA@mail.gmail.com> <CAP8-FqnLaRvyQgXXkoNQPKcyMhv-O3RN67CMw5L_-1iQ9c6mhw@mail.gmail.com> <CAH9hSJYpsPW4S9n2LaaLTYYKB7wR3Sod2=fny2CZoUR7A0bSJA@mail.gmail.com> <CAP8-FqkOX1Sq6_=Sgb++QRiDWKEiOxAJ13kzMSr9heu-Ek3QmA@mail.gmail.com> <508f7085-b6b9-572e-7b0f-26cafc94dd44@ninenines.eu> <CAH9hSJZcGui08=DivN9vynKejvNFy+RYtRDYDnd6U6gxyX3UgQ@mail.gmail.com> <CAH9hSJZZCVMpQrpEV_JTceEmf2Y2aC_kJNXJmLW=LPebG+JR7g@mail.gmail.com> <CAP8-Fqk9SQJOuKWQmf5cRm9z2ja9wWUeG9xmivhiJf5O57Uryw@mail.gmail.com> <CAH9hSJZTVKx-8vg2xcqr_g4Bg+hc1ufvPZ2hZ+F=dXeVOdSu_Q@mail.gmail.com> <CAP8-Fqm=OVaOJ1imySM41_OuNu0D12Jby59dOpgqz-Bg4M+YOQ@mail.gmail.com> <CAD3-0rM35uXJnwfGay-1s9uw=-P71EubOkxFdKF=gjoXub8YXw@mail.gmail.com> <CAH9hSJZB0SyFiqLqLjd9R-T11yTa12Ekb-H8hYwfc6FeOjD2xQ@mail.gmail.com> <CAP8-FqmU+uBas5zH8oQHkt0zh18YrBm-O-umGPGMkLAjShw1Gw@mail.gmail.com> <CAH9hSJa10DLSozTpXjETyFX0bVYqfRbRFJnmFQNRGeSuZVKWPQ@mail.gmail.com> <CAG-EYChszHdWhp=o+fdOW+pAN90t61MExzsLnteM3tmf9=N0Yw@mail.gmail.com> <CAH9hSJbNk83FT0WqB1tHJvEfaU5CMoAaKRdvy8NTb4zgEUdzBw@mail.gmail.com> <CAG-EYCjwptZcsHeDKwyRBhLTREEC4zxXxtTZvNLe2m1ei2r55g@mail.gmail.com> <437A6E14-03A9-42DD-A4B8-921C80EC5729@mnot.net> <1480035079.3044.1.camel@warmcat.com> <8E039C1D-A9B6-40E4-937E-A55D327FBDC5@mnot.net> <1480041123.3044.3.camel@warmcat.com>
To: Andy Green <andy@warmcat.com>
X-Mailer: Apple Mail (2.3251)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.396, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cA6N3-0002nE-H1 375f35213fcca654185b805efb6dd1f3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)
Archived-At: <http://www.w3.org/mid/EA373BD5-0C84-42B5-BB49-612C9C9EDA2D@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33012
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>

> On 25 Nov. 2016, at 1:32 pm, Andy Green <andy@warmcat.com> wrote:
> 
> On Fri, 2016-11-25 at 13:12 +1100, Mark Nottingham wrote:
>> Andy,
>> 
>> The "people managing it" are the IETF. "Let the community do it" is
>> how the IETF works, with guidance from IETF leadership. I had a 
> 
> No... when ws for http/1 was hashed out, there were some adults in the
> room who could make judgments about what was or wasn't "a consensus" in
> a kinda-definitive way.  Several times these calls were important in
> stopping the definition going around in endless circles... even so you
> will recall there were like 80+ drafts of it.
> 
> That has gone away now.
> 
>> discussion with our Area Director about this topic in Seoul, and we
>> agreed that the hybi list was the best place to talk about
>> WebSockets.
> 
> That's not necessarily a problem, but is either of you guys who decided
> that going to restore the ML to have the kind of management it had when
> it spat out RFC6455?  Or if it's chicken-and-egg, since the list is
> moribund and no evident interest today to point to, some threshold for
> that happening?  If not as I said it feels like it's just getting
> punted over the wall.  It's going back to Hybi but the management of
> Hybi is gone and it's nobody's problem...

Adding Alexey, the Area Directory who's most relevant to this.

You seem to be looking for a Working Group. WGs are formed when the IESG (i.e., all of the ADs) are convinced that it's useful to do so. The first step is usually to put together a charter proposal, and start gathering a community.

In the meantime, the adult supervision you're looking for isn't over here either; our charter restricts us to HTTP.

Cheers,



> -Andy
> 
>> Cheers,
>> 
>> 
>>> On 25 Nov. 2016, at 11:51 am, Andy Green <andy@warmcat.com> wrote:
>>> 
>>> On Fri, 2016-11-25 at 10:35 +1100, Mark Nottingham wrote:
>>>> To clarify, we said that the future of WebSockets really isn't in
>>>> scope for this WG; the proper venue for discussing that is:
>>>>   https://www.ietf.org/mailman/listinfo/hybi
>>> 
>>> They kind of shut that down, the people managing it have gone away
>>> 
>>> https://mailarchive.ietf.org/arch/msg/hybi/YVBJTzJcvzytIY46KfIS8bch
>>> f5E
>>> 
>>> the ML is still running but is very quiet.
>>> 
>>> WS itself seems to be in rude health out there.
>>> 
>>>> What *is* in-scope here is how (if at all) that protocol
>>>> interacts
>>>> with HTTP, including HTTP/2; there are several ways you could
>>>> implement WebSockets over HTTP/2, and a few pitfalls in doing so
>>>> that
>>>> the people on this list will be able to give you feedback on.
>>> 
>>> It's unfortunate that wasn't considered part of defining HTTP/2, so
>>> it
>>> could be baked in.   The subject was certainly raised.  But I can
>>> understand the desire to get the main business out of the door.
>>> 
>>>> However, it's hard to do that before there's agreement in the WS
>>>> community about what the requirements are. Ideally, that
>>>> community
>>>> would bring a single proposal that has broad support here for
>>>> review.
>>> 
>>> Any formal mechanism to manage that has gone away for hybi
>>> AFAICT.  So
>>> this "let the community do it" feels like a bit of a cop-out /
>>> bullet
>>> dodging.
>>> 
>>> At any rate I think the number of people interested in HTTP/2 WS is
>>> still very low compared to the number of people interested in WS
>>> client
>>> and server generally in my experience.  But at some point that will
>>> change, possibly suddenly.
>>> 
>>> -Andy
>>> 
>>>> Cheers,
>>>> 
>>>> 
>>>>> On 25 Nov. 2016, at 5:39 am, Van Catha <vans554@gmail.com>
>>>>> wrote:
>>>>> 
>>>>> Thanks for clarification. Unfortunate that so little attention
>>>>> was
>>>>> paid to this.  Looks like some of us will be on HTTP1.1 for a
>>>>> long
>>>>> time.
>>>>> 
>>>>> On Mon, Nov 21, 2016 at 11:14 PM, Takeshi Yoshino <tyoshino@goo
>>>>> gle.
>>>>> com> wrote:
>>>>> Ah, no. Martin just warned us that we might face the same issue
>>>>> that SSE faced.
>>>>> 
>>>>> Mark's suggestion is a separate thing. The co-chairs (Mark and
>>>>> Patrick) said that this (WiSH) doesn't seems to be a topic that
>>>>> should be discussed in the HTTP WG given the charter of the WG,
>>>>> I
>>>>> think.
>>>>> 
>>>>> On Sun, Nov 20, 2016 at 12:26 PM, Van Catha <vans554@gmail.com>
>>>>> wrote:
>>>>> I do not understand what this means.  Is the suggestion to
>>>>> ignore
>>>>> WiSH for now in favor of SSE?
>>>>> 
>>>>> On Fri, Nov 18, 2016 at 1:55 AM, Takeshi Yoshino <tyoshino@goog
>>>>> le.c
>>>>> om> wrote:
>>>>> I'd like to share the feedback on WiSH from IETF 97.
>>>>> 
>>>>> ----
>>>>> 
>>>>> Due to limited time, I got just one on-site comment from Martin
>>>>> about comparison with Server-sent event (EventSource).
>>>>> 
>>>>> As mentioned in the I-D, yes, this is kinda full-duplex SSE
>>>>> with
>>>>> the WS framing, and it might suffer from unexpected buffering
>>>>> by
>>>>> intermediaries if any as Martin said.
>>>>> 
>>>>> WiSH should work well for deployment with TLS only (possibly
>>>>> with
>>>>> some non-TLS part beyond server side front-end but are under
>>>>> control of the service providers). Given the wide trend of
>>>>> encouraging TLS and browser vendors' implementation status of
>>>>> H2, I
>>>>> think we should prioritize layering simplicity than taking care
>>>>> of
>>>>> gain of WiSH/H2/TCP + transparent proxy (with unexpected
>>>>> buffering)
>>>>> case. For H2-less TLS-less environment, we can just use the
>>>>> WebSocket protocol.
>>>>> 
>>>>> There can still be some risk of MITM (trusted) proxy and
>>>>> unexpected
>>>>> buffering with AntiVirus/Firewall for deployment with TLS, but
>>>>> other WebSocket/H2 mapping proposals also have issues of
>>>>> possible
>>>>> blocking, buffering, etc. WebSocket/TCP's handshake success
>>>>> rate
>>>>> for non-TLS port 80 was also not so good when it started
>>>>> getting
>>>>> deployed, and got improved gradually. I think the problems will
>>>>> get
>>>>> resolved once WiSH is accepted widely, and I believe the total
>>>>> pain
>>>>> and cost would be smaller.
>>>>> 
>>>>> ----
>>>>> 
>>>>> Mark suggested that we should find some other right place than
>>>>> HTTP
>>>>> WG. I'll discuss this with Mark. Maybe we'll consult the
>>>>> DISPATCH
>>>>> WG.
>>>>> 
>>>>> ----
>>>>> 
>>>>> Thanks everyone for the feedback.
>>>>> 
>>>>> Takeshi
>>>>> 
>>>>> On Thu, Nov 3, 2016 at 3:20 AM, Costin Manolache <costin@gmail.
>>>>> com>
>>>>> wrote:
>>>>> Good timing -  http://httpwg.org/http-extensions/encryption-pre
>>>>> view
>>>>> .html is addressing my concerns for
>>>>> webpush ( and general 'encrypted content' ), we're still
>>>>> discussing
>>>>> some details, but for this use
>>>>> case metadata won't be needed.
>>>>> 
>>>>> Costin
>>>>> 
>>>>> 
>>>>> On Tue, Nov 1, 2016 at 10:34 PM Takeshi Yoshino <tyoshino@googl
>>>>> e.co
>>>>> m> wrote:
>>>>> On Mon, Oct 31, 2016 at 5:57 AM, Wenbo Zhu <wenboz@google.com>
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> On Sun, Oct 30, 2016 at 10:25 AM, Costin Manolache <costin@gmai
>>>>> l.co
>>>>> m> wrote:
>>>>> Thanks for the answer and pointers. From earlier responses, it
>>>>> seems possible to use GET
>>>>> or a non-web-stream request to would avoid the extra cost of
>>>>> the
>>>>> pre-flight.
>>>>> 
>>>>> 
>>>>> Yeah, at least the Content-Type in the HTTP request gets
>>>>> eliminated.
>>>>>  
>>>>> One more question/issue: in some cases it would be good to send
>>>>> some
>>>>> metadata (headers) along with binary frames. For example in
>>>>> webpush
>>>>> the content is an encrypted
>>>>> blob, and needs headers for the key/salt. I would assume a lot
>>>>> of
>>>>> other 'binary' messages would
>>>>> benefit if simple metadata could be sent along. Would it be
>>>>> possible to use one of the reserved
>>>>> bits for 'has metadata' and add some encoded headers ? I know
>>>>> in
>>>>> websocket they are intended 
>>>>> for 'extensions', but 'headers' seems a very common use case.
>>>>> Q about webpush: is the metadata different for each binary
>>>>> message? 
>>>>> 
>>>>> We discussed about metadata and how to use one of RSV bits etc.
>>>>> For
>>>>> the current version, let's make sure the WS compatibility is
>>>>> fully
>>>>> addressed (with minimum wire encoding like WiSH)
>>>>> 
>>>>> Agreed. Let's discuss the metadata needs separately. I agree
>>>>> it's
>>>>> important.
>>>>>  
>>>>>  
>>>>> 
>>>>> Having the binary frame use some MIME encoding to pass both
>>>>> text
>>>>> headers and the binary blob
>>>>> is possible - but has complexity and overhead.
>>>>> OTOH, if the binary blob relies on text headers (metata) to be
>>>>> useful, then you probably need define a dedicated MIME
>>>>> encoding.
>>>>> 
>>>>>   
>>>>> 
>>>>> Costin
>>>>> 
>>>>> On Sun, Oct 30, 2016 at 5:27 AM Takeshi Yoshino <tyoshino@googl
>>>>> e.co
>>>>> m> wrote:
>>>>> Thanks, Van, Costin.
>>>>> 
>>>>> On Sun, Oct 30, 2016 at 2:43 AM, Costin Manolache <costin@gmail
>>>>> .com
>>>>>> wrote:
>>>>> 
>>>>> Good point - websocket is widely deployed, including IoT - and
>>>>> the
>>>>> header is pretty easy to handle anyways.
>>>>> +1.
>>>>> 
>>>>> One question: is this intended to be handled by browsers, and
>>>>> exposed using the W3C websocket API ?
>>>>> Will a regular app be able to make WiSH requests and parse the
>>>>> stream by itself, without browser
>>>>> interference ? And if yes, any advice on how it interact with
>>>>> CORS
>>>>> ? 
>>>>> 
>>>>> The first step would be using Streams based upload/download via
>>>>> the
>>>>> Fetch API + protocol processing in JS.
>>>>> 
>>>>> The next step could be either introduction of an optimized
>>>>> native
>>>>> implementation of WiSH parser/framer in the form of the
>>>>> TransformStream which can be used as follows:
>>>>> 
>>>>> const responsePromise = fetch(url, init);
>>>>> responsePromise.then(response => {
>>>>>   const wishStream =
>>>>> response.body().pipeThrough(wishTransformStream);
>>>>>   function readAndProcessMessage() {
>>>>>     const readPromise = wishStream.read();
>>>>>     readPromise.then(result => {
>>>>>       if (result.done) {
>>>>>         // End of stream.
>>>>>         return;
>>>>>       }
>>>>> 
>>>>>       const message = result.value;
>>>>>       // Process the message
>>>>>       // E.g. access message.opcode for opcode, message.body
>>>>> for
>>>>> the body data
>>>>>       readAndProcessMessage();
>>>>>     });
>>>>>   }
>>>>>   readAndProcessMessage();
>>>>> });
>>>>> 
>>>>> and provide a polyfill that presents this as the WebSocket API,
>>>>> and
>>>>> (or skip the step and) go further i.e. native implementation
>>>>> for
>>>>> everything if it turns out optimization is critical.
>>>>> 
>>>>> We need to discuss this also in W3C/WHATWG.
>>>>> 
>>>>> Regarding CORS, if the request includes non CORS-safelisted
>>>>> headers, fetch() based JS polyfills will be basically subject
>>>>> to
>>>>> the CORS preflight requirement. We could try to exempt some of
>>>>> well
>>>>> defined headers if any for CORS like WebSocket handshake's
>>>>> headers
>>>>> and server-sent event's Last-Event-Id are exempted. Regarding
>>>>> the
>>>>> proposed subprotocol negotiation in the form of combination of
>>>>> the
>>>>> Accept header and the Content-Type header, the Accept header is
>>>>> one
>>>>> of the CORS-safelisted headers, so it's not a problem. The
>>>>> Content-
>>>>> Type header is considered to be non-CORS-safelisted if it's
>>>>> value
>>>>> is none of the CORS-safelisted media types. So, WiSH media type
>>>>> would trigger the preflight unless we exclude it.
>>>>> 
>>>>> Origin policy https://wicg.github.io/origin-policy/ might also
>>>>> help.
>>>>>  
>>>>> 
>>>>> Costin
>>>>> 
>>>>> On Fri, Oct 28, 2016 at 12:06 PM Takeshi Yoshino <tyoshino@goog
>>>>> le.c
>>>>> om> wrote:
>>>>> Sorry for being ambivalent.
>>>>> 
>>>>> We can of course revisit each design decision we made for RFC
>>>>> 6455
>>>>> framing and search for the optimal again. But as:
>>>>> - one of the main philosophies behind WiSH is compatibility
>>>>> with
>>>>> WebSocket in terms of both spec and implementation
>>>>> - the WebSocket is widely deployed and therefore we have a lot
>>>>> of
>>>>> implementations in various languages/platform
>>>>> - most browsers already have logic for the framing
>>>>> - the framing is not considered to be so big pain
>>>>> inheriting the WebSocket framing almost as-is is just good
>>>>> enough.
>>>>> Basically, I'm leaning toward this plan.
>>>>> 
>>>>> Takeshi
>>>>> 
>>>>> On Sat, Oct 29, 2016 at 3:12 AM, Takeshi Yoshino <tyoshino@goog
>>>>> le.c
>>>>> om> wrote:
>>>>> On Sat, Oct 29, 2016 at 2:55 AM, Loïc Hoguin <essen@ninenines.e
>>>>> u>
>>>>> wrote:
>>>>> On 10/28/2016 08:41 PM, Costin Manolache wrote:
>>>>> Current overhead is 2 bytes if frame is up to 125 bytes long -
>>>>> which I
>>>>> think it's not very common,
>>>>> 4 bytes for up to 64k, and 10 bytes for anything larger.
>>>>> IMHO adding one byte - i.e. making it fixed 5-byte, with first
>>>>> as
>>>>> is,
>>>>> and next 4 fixed length would
>>>>> be easiest to parse.
>>>>> 
>>>>> Is making it easy (or easier) to parse even a concern anymore?
>>>>> 
>>>>> Considering the number of agents and servers already supporting
>>>>> Websocket, the numerous libraries for nearly all languages and
>>>>> the
>>>>> great autobahntestsuite project validating it all, reusing the
>>>>> existing code is a very sensible solution.
>>>>> 
>>>>> 
>>>>> Yeah, I've been having similar feeling regarding cost for
>>>>> parser/encoder implementation though I might be biased.
>>>>>  
>>>>> There are obviously too many options to encode and each has
>>>>> benefits -
>>>>> my only concern was
>>>>> that the choice of 1, 2, 8 bytes for length may not match
>>>>> common
>>>>> sizes.
>>>>> 
>>>>> ( in webpush frames will be <4k ).
>>>>> 
>>>>> -- 
>>>>> Loïc Hoguin
>>>>> https://ninenines.eu
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Mark Nottingham   https://www.mnot.net/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> 
>> 
>> 
>> 

--
Mark Nottingham   https://www.mnot.net/