REPLY_RAW format seemingly at odds with IEC 60839-11-5:2020

[mpfj]

Describe the bug
Looking at the code, I can see the reply format for RAW card reads.
However, this does not match IEC 60839-11-5:2020 which we are working against.

Expected behavior
For example, the IEC standard shows 2 bytes for the reply data size, whereas you only have 1.

I see that the SIA spec is 2.2.2 published in 2024.
So is the IEC standard now "out-of-date"?
If so, shouldn't some backward compatibility be required?

[sidcha]

Hi @mpfj, Can you please post a screenshot of what you are looking at? I checked v2.2 and v2.1.5 (predates the IEC version) of the spec and both seems to agree (with code) that data can be arbitrary length.

Also "whereas you only have 1" -- where are you seeing this?

[mpfj]

I now realise I'm not necessarily looking at the same thing but here's the IEC definition of the RAW card reading reply:

And here's the definition from osdp.h:

I guess the struct isn't a direct byte-for-byte mapping.

Regardless, my reply packets always seem to be missing the first 2 card data bytes and was just checking to see if I've missed something.
It's possible my testing tool ("OSDP Bench" from the Windows Store) might be wrong so was hoping I could just get confirmation that the IEC reply format is still valid.

Cheers

[sidcha]

LibOSDP exposed API (osdp.h) is not the same as the wire OSDP contract. Have you tried the LibOSDP python CP example https://doc.osdp.dev/python/getting-started#control-panel-mode to cross check the results?

[mpfj]

False alarm ... my bad.
After staring at my code, I finally found had an index offset bug.
All fixed now, cheers