Consider to use draft-ietf-httpbis-binary-message to represent Response

[hayatoito]

I've skimmed https://datatracker.ietf.org/doc/draft-ietf-httpbis-binary-message/.

My understanding is that we probably can use that format to represent "response" in the Responses section , instead of the current encoding for headers and payload.

eg.

Before:

responses = [response]
response = [headers: bstr .cbor headers, payload: bstr]
headers = { bstr => bstr}

After:

responses = [*response]
response = Response defined in draft-ietf-httpbis-binary-message, perhaps.

I've not dived into it deeply, but this might be worth considering. Let me file an issue here to start a discussion to confirm how that'll fit well.

[hayatoito]

I've read https://datatracker.ietf.org/doc/draft-ietf-httpbis-binary-message/.

Let me share the brief summary what should be changed if we adopt RFC9292.

Note that I don't have a strong opinion whether we should adopt RFC 9292 or not. That needs a discussion.

• The current Web Bundle format
  draft-ietf-wpack-bundled-responses-latest
• RFC 9292
  Binary Representation of HTTP Messages

Changes

4.3 Responses

responses = [*response]
response = [headers: bstr .cbor headers, payload: bstr]
headers = {* bstr => bstr}

will be changed to:

responses = [*known-length-response: bstr]

known-length-response is "Known-Length Response" defined in https://www.rfc-editor.org/rfc/rfc9292.html#name-known-length-messages

RFC 9292 also defines "Indeterminate-Length Response", but I don't see any usage of Indeterminate-Length Response in Web Bundles. Web Bundle format has an "Index" section, so Indeterminate-Length Response doesn't fit well. Each response's size must be predetermined by design.
We don’t need any other changes overall. We don’t need any *-Request defined in RFC 9292.

Drop the following statements (from 4.3 Responses):

The length of the headers byte string in a response MUST be less than 524288 (512*1024) bytes, and recipients MUST fail to load a response with longer headers.

No longer required? I don't see any background of this restriction.

Each response's headers MUST include a :status pseudo-header with exactly 3 ASCII decimal digits and MUST NOT include any other pseudo-headers.

Known-Length Response has "Final Response Control Data", which includes "status code".

Fields which don’t make sense in Web Bundles

I don’t see any usage of the following fields. But we may allow the following fields. In other words, Web Bundle format parser doesn’t emit parse errors. But we should say "Clients SHOULD ignore these fields."

Known-Length Informational Response (..) ...,

This is "Informational Status Codes (100-199)". e.g. Early Hint 103
https://www.rfc-editor.org/rfc/rfc9110#section-15.2
No usage in Web bundles.

Trailer fields (2nd Known-Length Field Section (..) in Known-Length Response)

https://www.rfc-editor.org/rfc/rfc9110#section-5

It seems trailer fields are used only in proxy. No usage in Web Bundles.

Other thoughts

Given that the current Web Bundles format uses cbor encoding everywhere, it seems a bit downside if we adopt RFC9292 in response, given RFC9292 uses their own encoding scheme.

Any ideas or opinions are welcome.