New constants needed for SBE 2.0 payloads in SOFH about fix-simple-binary-encoding HOT 3 CLOSED

The current SOF version shows explicit codes for SBE Version 1.0 but a range of codes for other Technical Standards such as FAST (0xFA01 – 0xFAFF). Would that avoid the need to release a new version of SOF for every new version of SBE? Or would it make sense to remove the version of the Technical Standard as other Technical Standards have a single code but also no version. It would then be up to the parser for the given encoding to identify the version. It looks like we do not have a consistent approach here.

from fix-simple-binary-encoding.

I can envision a gradual migration during which SBE 1.0 and 2.0 messages are mixed. Having the payload encoding version in the SOFH would allow a fast switch of parsers.

Generically, a parser can determine version of many protocols. However currently, SBE version is in the message schema (out-of-band metadata) but not on the wire, and the version 2.0 header is not back-compatible with 1.0.

Some Internet protocols deal with this problem by having a base header chained to optional extensions. A decoder follows the chain until there are no more headers. Should we consider this approach for SBE, or is it overkill?

For an example, see RFC 7045

from fix-simple-binary-encoding.

Now I think that adding an SOFH value for SBE 2.0 is unnecessary. Although versions 1.0 and 2.0 have slightly different wire formats, the beginning of the message header in 2.0 is the same as the 1.0 header. Therefore, a message header decoder can read the schema ID and version using the same logic for both. Once the schema is determined, metadata for the schema can be referenced to determine its SBE version. Therefore, what is really needed is an attribute in <schema> element giving the SBE wire format version. It can default to the current SBE version in the XML schema, e.g. 2.0.

from fix-simple-binary-encoding.