Framing and control-frame continuations

Roberto Peon <grmocg@gmail.com> Tue, 05 February 2013 22:30 UTC

Return-Path: <ietf-http-wg-request@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 D1FE821F8630 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 5 Feb 2013 14:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.518
X-Spam-Level:
X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zshPoZ2Ty7ZZ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 5 Feb 2013 14:30:22 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79921F861A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 5 Feb 2013 14:30:22 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U2r0m-00022f-Hx for ietf-http-wg-dist@listhub.w3.org; Tue, 05 Feb 2013 22:29:08 +0000
Resent-Date: Tue, 05 Feb 2013 22:29:08 +0000
Resent-Message-Id: <E1U2r0m-00022f-Hx@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1U2r0a-00020Q-Ih for ietf-http-wg@listhub.w3.org; Tue, 05 Feb 2013 22:28:56 +0000
Received: from mail-la0-f47.google.com ([209.85.215.47]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1U2r0Z-0002Zo-Ka for ietf-http-wg@w3.org; Tue, 05 Feb 2013 22:28:56 +0000
Received: by mail-la0-f47.google.com with SMTP id fj20so731424lab.20 for <ietf-http-wg@w3.org>; Tue, 05 Feb 2013 14:28:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=j26aUPc5Kfz9PpB2rfr/9Yxh71/XLzpoJqpHruMqPEg=; b=iTYowFbdU/LBX1rkS0u7YH3E12qzEsLLIUde1oQJuprbBhDpwkI214/G5Ao3NBQF40 7wdBNVXZ7NND8Qx0ii/EhfQHEP6duo82sb+G+Ha3qvQ3YbYsK7D6taaGEdqXU7SB2qxb pt6LNglmnldXkEn5ZSgH/r+8zVpVP6G27gVmJ2V6GPvue1qqLXzX7KaFID3QMewVrohq adK/a5rX3dtap38xkX7K5+Pj/p/LTwfzlN+KhZwp5s296PQ7lzvfxIGYfxiJbAVf1N8+ oFacD8159Ph7cEZ53VBtCu8RUq0IaWki6qi9ryP0IUZAijtWVaPuv0X3bFUzZuDPgQ3x n1Hw==
MIME-Version: 1.0
X-Received: by 10.152.144.130 with SMTP id sm2mr24566712lab.49.1360103308514; Tue, 05 Feb 2013 14:28:28 -0800 (PST)
Received: by 10.112.81.5 with HTTP; Tue, 5 Feb 2013 14:28:28 -0800 (PST)
Date: Tue, 05 Feb 2013 14:28:28 -0800
Message-ID: <CAP+FsNemzHOH1YrDXbEqy_dMB8h=e2pD0QrgLzkz+cUtdHMaRw@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="e89a8f2348a98fd61b04d501ba40"
Received-SPF: pass client-ip=209.85.215.47; envelope-from=grmocg@gmail.com; helo=mail-la0-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.584, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U2r0Z-0002Zo-Ka dfd8db4171d30c14f7fb12f7370d30ab
X-Original-To: ietf-http-wg@w3.org
Subject: Framing and control-frame continuations
Archived-At: <http://www.w3.org/mid/CAP+FsNemzHOH1YrDXbEqy_dMB8h=e2pD0QrgLzkz+cUtdHMaRw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16391
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>

The proposal for framing is that there are always 8 bytes to read for every
frame, both control and data frames. (Thanks to Jeff Pinner for modifying
this for me already!)

Generically, this is the format of a frame.

  0        1        2        3        4         5        6        7
  +--------+--------+--------+--------+--------+--------+--------+--------+
  | Length(16)      |Type(8) |Flags(8)| Num-of-Entries-or-Stream-ID-or-ID | ->
  +--------+--------+--------+--------+--------+--------+--------+--------+

  8..N
  +========+
  |  Data  |
  +========+


   Length: An unsigned 16-bit value representing the number of bytes of
   the data field.

   Type: The frame type.

   Flags: Flags related to this frame.  Flag definitions are dependent
   upon the frame type.

   Data: data associated with this control frame.  The format of this
   data is controlled by the frame type.

For a data frame, TYPE is set to zero, and the
Num-of-Entries-or-Stream-ID-or-ID field (gotta get a better name :) )
contains a '0' followed by 31 bits of stream ID. Valid flags are:


      0x01 = FLAG_FIN - signifies that this frame represents the last
      frame to be transmitted on this stream.  See Stream Close
      (Section 2.3.7) below.

      0x02 = MSG_DONE - signifies that this frame represents the last
      frame of a message.  This is relevant for layering of message-
      based protocols on top of SPDY.



For control frames, a non-zero value will exist in the TYPE field.
The following flags are valid for all control frames:



      0x01 = FLAG_FIN - signifies that this frame represents the last
      frame to be transmitted on this stream.

      0x02 = MSG_DONE - signifies that this frame represents the last
      frame of a sequence of a run of same-type control frames.


If MSG_DONE is not set for a control-frame, then the particular
control message was unable to fit within a single control-frame.
Implementations may process the control message up to the amount
received, but MUST not treat the message as done. Implementations
SHOULD finish sending the control-message as soon as possible and when
finished with the particular control message, they MUST set MSG_DONE.


What do people think about the FLAGS/TYPE arrangement? If swapped, we
gain more contiguous reserved bits.
-=R