Generalized v2 IBC payload header structure

[soareschen]

In #1149, the proposed structure for Payload contains the metadata fields version and encoding. The encoding field is intended to communicate about the encoding format of the appData bytes, and it can be generalized into content-type and follows the MIME standard. The version field is intended to be backward compatible with the original version field used in v1 IBC handshake. However, we have seen in IBCv1 that version has been overused to contain multiple overloaded metadata encoded in an ad-hoc way that cannot be easily composed or extended.

In this issue, I propose that we should consider allowing multiple generalized headers to be present in the IBC payload as a key-value map. This would follow similar structure as HTTP headers, and can be used to store arbitrary metadata about the payload body. Under this scheme, the content-type header becomes an optional header that may be present as one of the entries in this generalized headers map. This would allow different parts of the application to specify different headers without having to cram them as a single value. For example, the incentivized fees for relayers may be specified as a separate field such as forward-relayed-by. If we remove IBC ack as specified in #1150, then the original ack may be converted into a normal IBC packet that contains headers such as payload-type: ack, ack-nonce, ack-status etc.

The main complexity that arise from this proposal is how we should encode the IBC payload headers. One consideration is that we should perhaps keep it limited, similar to HTTP headers, so that applications are not encouraged to add arbitrary nested complex data into the headers. For instance, the encoding should not be plain CBOR or JSON, which would allow arbitrary nested values in the headers. Another consideration is on whether we should require canonicalization of the header keys, e.g. so that they are case insensitive, or that only lower cases are allowed. Similarly, we may want the header values to contain basic ASCII characters with no new lines. All in all, we may consider a format similar to HTTP headers, since they are already battle tested to support all kinds of use cases.