RE: Large Frame Proposal

To quote Mark from an earlier thread...



On Wednesday,25 June 2014 06:11, mnot@mnot.net wrote:

> WRT the "jumbo" frame (i.e., flagging that some prefix of the

> payload is actually an extension length) -- this sort of hack is

> necessary to back-port bigger frames onto an existing protocol



Amen. A 31-bit frame-length field may be too many bits today, but IMO we shouldn't set ourselves up for an ugly hack later.



So I propose some variant of the following...





  0                   1                   2                   3

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|   Reserved    |                  Length (24)                  |

+-+-------------+-----------------------------------------------+

|R|                 Stream Identifier (31)                      |

+-+-------------+---------------+-------------------------------+

|   Type (8)    |   Flags (8)   |

+===============+===============+===============================+

|                   Frame Payload (0...)                      ...

+---------------------------------------------------------------+







This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Thursday, 10 July 2014 09:51:46 UTC