Re: Secdir last call review of draft-ietf-httpbis-binary-message-04

[Martin Thomson <[e-mail]>]

Hi Daniel,

Thanks for the review.

On Wed, Jun 1, 2022, at 23:58, Daniel Migault via Datatracker wrote:
> """ As such, this format is unlikely to be suitable for applications that
> depend on an exact recording of the encoding of messages."""
>
> I am wondering what it actually means. Typically, I do not see much differences
> between the content provided by bmessage and message. For my own information,
> in case a response is compressed I am wondering if the compression would occur
> "over" the bmessage or if the bmessage would include the compressed content.

There are no (or at least no significant) *semantic* differences, but there are great differences in *encoding*.  For some applications, capturing the precise encoding is considered important.  Archival and security applications are two obvious ones.  For instance, WARC is fairly good at capturing this information.

We discussed the potential for this to capture capture HTTP/2 messages with all their header compression, framing boundaries, and other details but decided that this was not the goal of this format.  For one, trying to capture those details would greatly alter the efficiency and simplicity of the encoding.

So this is simply an statement of limited applicability: we capture semantics, not encoding.  I had hoped that was clear through the use of "exact recording of the encoding of messages".

As for compression, it is possible to compress a binary message (if you send one over HTTP, you can use a compressed content coding), but the format itself has no compression - or the ability to capture what compression was used in a message that the binary message might have been produced from.  The content of a binary message might also use a content coding, but that is just a native feature of HTTP that comes for free when you convey HTTP semantics.

> I have the impression item 2 of the list could be more consistent with the
> other items that is starting with 2. interim response. By the way wouldn't
> informational response more appropriated ?

It's informational.  I don't know how I keep making that mistake.  Tacked onto an open pull request (which fixes another instance of the same error).

> Section 4
>
>    This document describes a number of ways that a message can be
>    invalid.  Invalid messages MUST NOT be processed except to log an
>    error and produce an error response.
>
> The message seems to be at least processed to determined it is invalid. I
> believe what we are trying to say here is that the message must not be passed
> to the application or must be discarded as soon as it is detected to be invalid.

True:

Invalid messages MUST NOT be processed ++further++ except to log an error and produce an error response.