Re: [hybi] Framing Take VI (a compromise proposal)

Greg Wilkins <gregw@webtide.com> Mon, 16 August 2010 15:16 UTC

Return-Path: <gregw@webtide.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E743A67B2 for <hybi@core3.amsl.com>; Mon, 16 Aug 2010 08:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.339
X-Spam-Level:
X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[AWL=-1.884, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUZQPBPF5UlW for <hybi@core3.amsl.com>; Mon, 16 Aug 2010 08:16:23 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 81E3A3A6765 for <hybi@ietf.org>; Mon, 16 Aug 2010 08:16:23 -0700 (PDT)
Received: by fxm18 with SMTP id 18so3444021fxm.31 for <hybi@ietf.org>; Mon, 16 Aug 2010 08:16:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.115.201 with SMTP id j9mr5326121faq.48.1281971818769; Mon, 16 Aug 2010 08:16:58 -0700 (PDT)
Received: by 10.223.57.12 with HTTP; Mon, 16 Aug 2010 08:16:58 -0700 (PDT)
In-Reply-To: <AANLkTinyLyOUje4sNkwdYueS17OEvKybtr4z8AHtBbYR@mail.gmail.com>
References: <AANLkTi=TBXO_Cbb+P+e2BVfx69shkf8E1-9ywDh_Y+Kz@mail.gmail.com> <AANLkTi=52ARa2v9oZ1tGosN7oL+kBBVH20XmtkXzPMM0@mail.gmail.com> <AANLkTimjt0YbXfLf83od5b2cSJaZUboBy3-03LFf=Kv8@mail.gmail.com> <AANLkTimV4Xvashf8SZAHS15FCLiX7pUnXcae20Ph73YY@mail.gmail.com> <AANLkTindxmp_cPTZx+6FXsfMt2R0mJt_vNtDZsLRO8Ms@mail.gmail.com> <AANLkTikRJGAbjv9apOC0W4td4h0fJoH75eZ+WkoRgKbm@mail.gmail.com> <AANLkTinyLyOUje4sNkwdYueS17OEvKybtr4z8AHtBbYR@mail.gmail.com>
Date: Tue, 17 Aug 2010 01:16:58 +1000
Message-ID: <AANLkTik9y3zyMBXBtYF+zAJEr1bANr5CpfKdEsmhSZoU@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: John Tamplin <jat@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Framing Take VI (a compromise proposal)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Mon, 16 Aug 2010 15:16:24 -0000

John,

you don't exactly have what I'm proposing.


Consider the following two independent ws connections

connection 1:
   op=text data=Hello World
   op=binary data=9ab39129def329432993
   op=test data=goodbye

connection 2:

   op=text data=One
   op=binary data=2222222222222
   op=text data=three


A hypothetical MUX extension might merge those connections as:

   op=extended ext=MUX(channel=1,type=text) data=Hello World
   op=extended ext=MUX(channel=2,type=text) data=One
   op=extended ext=MUX(channel=1,type=binary)  data=9ab39129def329432993
   op=extended ext=MUX(channel=2,type=binary)  data=2222222222222
   op=extended ext=MUX(channel=2,type=text)  data=three
   op=extended ext=MUX(channel=1,type=text)  data=goodbye



On 17 August 2010 00:51, John Tamplin <jat@google.com> wrote:
> Maybe a compromise would be to define an opcode EXTENDED_FRAME, and for that
> opcode the n bytes (however many we want to allocate) are an extension ID,
> and the rest are extension-defined (which might include data from multiple
> logical channels, for example, so it would need multiple frame
> types/lengths).

that's more or less what I'm proposing.  Although I think of it more
as using something similar to Ian Fette's proposal for extension data,
but only for 1 op code.



> Also note that you were previously suggesting moving the message length
> field to the extension data -- that wouldn't be possible if we do away with
> extension data and instead make it an opcode.  So, I assume that means we
> would keep the message length as defined in the current proposal.

It could still be done as an extension.  Eg the message

   op=text data=Hello World

might be fragmented as

  op=text frag=1 data=Hello
  op=text frag=0 data= World

If you wanted to send the message length, you might send

 op=extension frag=1 ext=META-DATA(byte-length=11, char-length=11,
content-type=text/plain) data=Hello
 op=text frag=0 data= World

Or if you wanted to preserve the ability of intermediaries to see the
data you could send:

 op=extension frag=1 ext=META-DATA(byte-length=11, char-length=11,
content-type=text/plain)
 op=text frag=1 data=Hello
 op=text frag=0 data= World


Or if you wanted to hide the data from intermediaries that didn't know
the extension

 op=extension frag=1 ext=META-DATA(byte-length=11, char-length=11,
content-type=text/plain) data=Hello
 op=extension frag=0 ext= data= World



cheers