MessageHeaderType SessionID

[a-w50]

Hi,

the sessionIdType has the following restriction:

<xs:restriction base="xs:hexBinary">
	<xs:length value="8"/>
</xs:restriction>

The generated struct representation has

struct {
    uint8_t bytes[iso20_sessionIDType_BYTES_SIZE];
    uint16_t bytesLen;
} SessionID;

Is there any reason, why the SessionID contains a bytesLen field. Shouldn't that be fixed to 8 anyway?

I'm asking, because it seems that I need to set this field manually, although it should be always 8 in length. I know, OpenV2G handles it the same, but looking at the schema, it should be an error, if bytesLen would differ from 8.
Or am I missing anything?

Best,
Anton

[barsnick]

Good observation.

OpenV2G does not handle this particular case in the same manner, because this restriction on SessionID was introduced with ISO 15118-20. Yet indeed ISO -2 also has one such restriction, namely genChallengeType (PaymentDetailsRes->GenChallenge), where both OpenV2G and cbV2G create the bytesLen. ISO -20 adds several more types restricted in such a manner.

To successfully decode a stream which does not conform to the schema (by deviation of length), we would need to keep the bytesLen variable available - or introduce an error for an incorrect length. From the encoding point, keeping the "obsolete" variable would put the responsibility on the user to use it correctly.

The discussion would be whether we keep this flexibility (also for e.g. decoding non-conforming streams), or drop it with the variable, and introduce enforcements. Consider that, in the C world, both encoding and decoding use the same structs as API. In C++, you could consider restricting access in the encoder, and being tolerant in the decoder (with e.g. an error code class indicating a deviation, but not failure to decode the message).

[a-w50]

Thanks for your comments,

I wasn't aware, that this changed from -2 to -20. Anyway, for compatibility reason, it should properly stay as it is for decoding. For encoding, the fixed length could be enforced, though.

Best,
Anton