Which standard follows SplitBinary Encoder/Decoder?

[gbonnefille]

While using the SplitBinaryEncoder and SplitBinaryDecoder it appears the encoding is not the one I expected.

I expect an encoding following the Mission Operations - Message Abstraction Layer Binding to TCP/IP Transport and Split Binary Encoding (Red Book CCSDS 524.2-R-1).

But, when encoding IdentifierList (for example) the nullability of the element of the list does not use the presence flags. Furthermore, a null element will be encoded as an empty element (empty string instead of null string).

As discussed in https://github.com/esa/CCSDS_MO_TRANS/issues/7, is it planned to fix this implementation? Applying the pull-request https://github.com/esa/CCSDS_MO_TRANS/pull/11 can help to track current deviations to standard.

[gbonnefille]

I've noticed that the new TCP/IP transport implementation uses its own SplitBinary implementation, instead of using this layer.

[SamCooper]

This implement is what the official standard was based on, and it will be updated to reflect the standard.

The TCP/IP version is compliant but is not separate from that transport, the plan is to merge the two implementations into this one.

[gbonnefille]

OK, thanks for explanation.

[gbonnefille]

Since the TCP/IP transport was recently updated by @CesarCoelho to better reflect the TCP/IP standard, the problem of the encoding of nullable elements is more than ever blocking.

Is it planned to update the SplitBinaryEncoder and SplitBinaryDecoder implementations?

As a reminder, these implementations do not use the presence flags for nullable elements (except for the Boolean, already overloaded in these classes).

[dmarszk]

This pull request fixes mentioned issues and refactors encodings and transports - https://github.com/esa/CCSDS_MO_TRANS/pull/37

[CesarCoelho]

Hi @gbonnefille ,

Could you confirm the fix, so we can close this issue?