- From: Daniel Migault via Datatracker <noreply@ietf.org>
- Date: Wed, 01 Jun 2022 06:58:43 -0700
- To: <secdir@ietf.org>
- Cc: draft-ietf-httpbis-binary-message.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
Reviewer: Daniel Migault Review result: Ready 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.
Received on Wednesday, 1 June 2022 13:58:56 UTC