[hybi] Replacing encapsulation method of the mux extension with END_SEGMENT (was: Re: Discontinuation of mux ...)
Takeshi Yoshino <tyoshino@google.com> Fri, 07 February 2014 12:07 UTC
Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264321A1DBD for <hybi@ietfa.amsl.com>; Fri, 7 Feb 2014 04:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Level:
X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
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 Acg8DOpi1gm8 for <hybi@ietfa.amsl.com>; Fri, 7 Feb 2014 04:07:52 -0800 (PST)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3314E1A1DBC for <hybi@ietf.org>; Fri, 7 Feb 2014 04:07:52 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id hi5so760113wib.9 for <hybi@ietf.org>; Fri, 07 Feb 2014 04:07:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=x9cA1XOr13srVWXWLM68MVfJoDz2lUOVOP7nx7K9kp4=; b=OCiwZklbPSAeuiaabfR2zEqzlHw5+WATTvgqSrc7TTlVKzMgsRi3WbgiXIANr61fHJ J9ZL+v1mvAtJ/KyjXR+CrtqamsoUH90fdM/0llQuPthI39o30CyNOx1U9gy9J522JnZh 9QlQmg9LyVg7+6yCsQNTqdaz/0DLzijDoO2qW8CmZCZDLAnKK/y73BzpHUzgEmZSjfiu zPu8UHikBEIEXpLecNisnD+QebbW6Gv9OdrV0S7JVmnAibehWkdeOzQfPnr+oUUh3Kyt 5jGLVTy4aPl1wTAj1yv3duVPlHJ749aJZRosZzKIM/b+lIWQQ+EbU3uzmE1rbMJhOrJY ChSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=x9cA1XOr13srVWXWLM68MVfJoDz2lUOVOP7nx7K9kp4=; b=lGvJImNbTUl/XNk9PMOumpG46NIb1Pxv/xMOrlkRaZf3pREzZUfKSRJ4ZsflWvNswv nF46gnzuokyGgO0Jfi3i2+bng8PYUAC5YYp8Gx2da0BwjUAXshpEQGKZYLsdkRlIQfx9 bKOInv3mOdqinsua3ff0AWcF3xdFWh14GRWRSK59aN1l/VrLo/jUM11H/p3tc6LQGuVP 5UFQRFdEMe65Jl1Kjm6tiw6ucXoTysWwcURo67DpNNASm6gQakGotD2z+2N5+MTKN3/m 7ZOXQNWjl7lJliz/NVQW5mMx69N6QiYyDd946DQlxwN6lOD+VI5yc4JRjWGxCXD6byy2 tGmw==
X-Gm-Message-State: ALoCoQlXIR27PfXBgJ5dJyGrQwdoh/UHyOHOTAaaroZu/FJsNCfvBAuep3sfWzQh/jNlWty8qQzITk1t+E7QfcgROmYb7K113vOan9zbjqAe9AfekT/2uRzdvvt24FkfACy6PmJsgi7A5CJEMd9/2veSVIZFqFNIMzi5iyiZpmDYEmfUnytcN+/Ll6m3IpQR4Y/MpD/Dfe0S
X-Received: by 10.194.71.47 with SMTP id r15mr10410547wju.19.1391774871462; Fri, 07 Feb 2014 04:07:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.8.231 with HTTP; Fri, 7 Feb 2014 04:07:31 -0800 (PST)
From: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 07 Feb 2014 21:07:31 +0900
Message-ID: <CAH9hSJaYgxHsxM12BC7a-=TG+Ga+x2EUVCcXvsfcYcgrKsvkxQ@mail.gmail.com>
To: Roberto Peon <fenix@google.com>
Content-Type: multipart/alternative; boundary="047d7bfd0172d2518504f1cfd655"
Cc: "hybi@ietf.org" <hybi@ietf.org>, Peter Thorson <webmaster@zaphoyd.com>
Subject: [hybi] Replacing encapsulation method of the mux extension with END_SEGMENT (was: Re: Discontinuation of mux ...)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Feb 2014 12:07:55 -0000
Just FYI, here's how the WebSocket specific mux extension (which we were developing in HyBi) would be like if its encapsulation method is replaced with HTTP/2.0 DATA frames and END_SEGMENT (formerly MSG_DONE) signal. If the WebSocket header fields are represented as HEADERS HTTP/2.0 frame, it'll be the same as yhirano's plan C. ==== Data frame 1 - 1bit: FIN of the encapsulated WebSocket frame - 3bits: RSV1-3 of ... - 4bits: Opcode of ... - Rest: 1st part of payload of ... Data frame 2 - 2nd part of payload of ... ... Data frame N (with END_SEGMENT set) - Last part of payload of ... ==== See also http://www.ietf.org/mail-archive/web/hybi/current/msg10404.htmlfor the reason why I think it's fine to exclude frame length. On Fri, Feb 7, 2014 at 4:23 AM, Roberto Peon <fenix@google.com> wrote: > > > > On Thu, Feb 6, 2014 at 7:26 AM, Peter Thorson <webmaster@zaphoyd.com>wrote: > >> >> I am fine with a “flush hint” flag where the sending endpoint >> *may/should* add it to HTTP/2.0 frames that the application prefers not to >> have buffered/delayed by intermediaries. I am fine with a separate bit >> named FLUSH_HINT (useful for either Plan D or native messaging) or re-using >> MSG_DONE to imply “flush hint” for Plan D streams if MSG_DONE is used >> elsewhere by HTTP/2.0. I would not want to define specific scenarios where >> a flush must occur. >> > > > HTTP2's MSG_DONE (under a different name) is in the next implementation > draft, coming out shortly. > For HTTP on HTTP/2 it is use for delimiting chunk boundaries on an HTTP > stream, since the lack of this has proven painful for some. Intermediaries > are disallowed from coalescing data across frame where this is set. >
- [hybi] Replacing encapsulation method of the mux … Takeshi Yoshino
- Re: [hybi] Replacing encapsulation method of the … Takeshi Yoshino