Specify record size inline, not in a separate header

[manger]

Indicating the coding with the "Content-Encoding: mi-sha256" header, but using a separate header to hold the critical record size parameter (eg "MI: rs=1024") feels like a poor design.

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?

The 2nd example from the spec would become (after converting <…> to bytes):

Content-Encoding: mi-sha256 Content-Length: 109

<00 00 00 10>When I grow up, I want to be a watermelon

[martinthomson]

Let's see what others think. I'm not sure either way.

[jyasskin]

https://tools.ietf.org/html/draft-thomson-http-mice-02 currently encodes the record size inline rather than in the MI header, so I think this issue can be closed.

[martinthomson]

Right. Thanks.

[ioggstream]

@martinthomson

Question

Provided I have:

• the decoded payload: When I grow up, I want to be a watermelon
• the MI header

~How can I validate the hash?~ I cannot validate the mi-sha256.

Idea

The original idea of rs in header (in addition to the payload) has sense indeed, as allow mi-sha256 to validate a content ex-post.

It could be something like mi-sha256/1024=... or a structured header.

[jyasskin]

@ioggstream https://github.com/martinthomson/http-mice/blob/master/micd.js has code to validate the payload+hash. I'm not sure what you're asking for beyond that.

[ioggstream]

Hi @jyasskin. I was just noting that:

• the MI header does not contain enough information to be used as a generic content hash (which would be useful)
• the actual design just work in conjunction with content-encoding: mi-sha256

[jyasskin]

To remove the content encoding, the header would also have to include all of the internal hashes. https://martinthomson.github.io/http-mice/draft-thomson-http-mice.html#example-with-multiple-records has an example of a message containing multiple proofs, and FAQ 3 gives an argument against moving the proofs to the header.

[ioggstream]

@jyasskin I wrote an (imho) reasonable proposal here https://github.com/martinthomson/http-mice/issues/16 :)

[jyasskin]

@ioggstream Sorry for misunderstanding you last year. I thought you were talking about validating the message as it arrives on the wire, but you clearly said you wanted to validate the decoded message, presumably after it's stored on disk. I don't understand the need for that, but I agree it's something that's not enabled by the current arrangement of headers, without storing some extra metadata with the decoded message.