Discussion: support of value types other than bytes (and integers)

[quentinlampin]

Context

In RFC 8724, it is explained that field values types returned by the parser are not constrained and the choice is left to the implementer. In page 13, it is indeed stated:

Target Value (TV) is the value used to match against the packet header field. The Target Value can be a scalar value of any type (integer, strings, etc.) or a more complex structure (array, list, etc.). The types and representations are out of scope for this document.

Moreover, the Matching Operators MSB(x), described in section 7.3, implicitly mandates the support of a raw representation of the field values. In (micro)Python, the closest representation type is bytes, making it a default, de facto, type for parsers.

Supporting types other than bytes, e.g. integer, strings, arrays, is challenging because of encoding/decoding issues. Here is a list of issues that comes to mind:

• Integers of arbitrary encoding, e.g. endianness
• Arbitrary string encoding: e.g. utf-8, ascii, latin-*, etc.
• Arrays encoding: e.g. array delimiters.

In general, unless the Compression/Decompression Actions (CDAs) keep track of the specific encoding of source (uncompressed) packets, the received (decompressed) packets may end up different from the source, leading to systematic transmission errors.

Assuming network ordering of bytes, the implementation can however get away without storing the encoding of integer fields, hence the "easy" support of integers.

The Question

In light of the encoding issues, should the implementation support other field types ? What would be the pros and cons ?

The issue is there to keep track of the thought process about this.