Last Call Review of draft-ietf-httpbis-binary-message-04
review-ietf-httpbis-binary-message-04-secdir-lc-migault-2022-06-01-00

Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

abstract:

""" 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.

Section 3.

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 ?

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.