Hi Tommaso, Thank for this feedback regarding your specification.
Tommaso Cucinotta a écrit :
as you will have noticed, various parts of the MuscleCard protocol have not been designed with too much care about saving bytes in the smart-card <-> host transfer, so, we just decided to have a DataChunk (short + data) wherever we needed a data chunk :-)
actually the applet specification does save bytes in exchange, for instance the control parameters P1 and P2 are used by most of the commands to carry some data; other specifications use to insert these data (eg a mechanism, a PIN try counter, ...) in a data object itself inserted in a constructed data object itself ... the whole transmitted in the data field of the APDU. so basically, the only "waste of bytes" is that length of response inserted in outgoing commands. I understand your goal (I think I understand it), you wrote that specifications with protocol T=0 in mind and card capabilities were limited, so you gave yourself an additional way to double-check the card's response. But it wasn't the only way to acheive that point; PC/SC 1.0 was issued in 1998 so it exist when you wrote your spec. and it gave garanty for the terminal to be able to know the length of returned data; regarding card capability - and mainly its capability to return long block of data, you would have been able to choose to return a '61xx' (ISO 7816-4 1995) status to indicate that more data is available for reading.
Just for feeding your discussion a little bit, I'm not even sure that the "DataLocation" (APDU vs INPUT OBJECT) makes sense in all the APDUs in which it is present.
I share the same feeling and without surprise, this indicator is mainly used by outgoing commands, it looks like you were not fully confident with this category of commands ;-) Best regards, Sylvain. _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
