search

jpos / jPOS-CMF

jPOS Common Message Format
http://jpos.org
12 stars 20 forks source link

DE-022 Point-of-Service data code - Bit tables feel misleading and perhaps are reflecting an endianess? #23

Open marksalternewday opened 1 year ago

marksalternewday commented 1 year ago

I found the tables confusing and attached a patch to reflect my changes. Happy to discuss if needed.

Although I revised the bit indicators I did not rearrange the 'rows' - for now at least :-)

Suggested_fix_to_PDC_tables___-_Arrange_flags_to_match_hexlayouts(perhaps_row_order_is_n.patch

ar commented 1 year ago

Thank you for the patch Mark.

Interesting enough, this issue was raised by @barspi in parallel. It is indeed confusing in ISO-8583 v2003 spec.

This is the layout used by the ISO spec itself, so I think we'd add extra confusion if we change these values here.

What's probably wrong is the endianness of PosDataCode implementation. We are thinking about making its endianness configurable.

Bad thing is the spec isn't clear about the value of 'BIT 1'. I assumed bit 1's value was 1, bit 2 was 2, bit 3 was 4, BUT, if we take a look at how the ISO8583 message's bitmap is documented, perhaps the gentlemen at the ISO committee think bits work the other way around :)

marksalternewday commented 1 year ago

For me, if the mapping matches - so that during debugging it is easy to compare to the spec - that would be good.

I can't guess how the ISO committee think ;-)

I was thinking that perhaps the conversion to/from bytes/bit could be left until pack/unpack instead of being done on each interaction, it might allow some speed gains (not that they are necessarily needed)