RE: MICE: specify record size inline, not in separate header

It seems unnecessarily annoying that you cannot even remove the mi-sha256 content-encoding (because you don't know the record size) despite having the Content-Encoding header and the content. Someone needs the proof, but perhaps not everything that handles the content. Even the spec admits that the proof might be acquired by other means, in which case "the MI header MAY be omitted".
Perhaps making it hard to remove the encoding without a proof is a perverse way of discouraging software from simply ignoring the integrity check?

--
James Manger

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, 9 May 2016 2:11 PM
To: Manger, James <James.H.Manger@team.telstra.com>
Cc: ietf-http-wg@w3.org
Subject: Re: MICE: specify record size inline, not in separate header

On 9 May 2016 at 13:43, Manger, James <James.H.Manger@team.telstra.com> wrote:
> How about just putting the record size at the start of the content, eg 
> a 4-byte prefix holding the record size in bytes as a big-endian unsigned int?

I chose the header because you pretty much need one anyway to carry the proof.  Including the size in the body is more space-efficient, but it makes the processing less regular because you have to read off
4 octets before proceeding to call fragment(body, rs+32).

I'm not convinced that there's a clear win either way.

Received on Monday, 9 May 2016 05:57:38 UTC