Joao Pedro ha scritto:
Hi Sylvain,
Hi all,
please, see the short comment inline:
another issue is that some points should be broken because they are
nosense (when data are returned they are prefixed by their length as
a short ?! the protocol does provides that information (the length of
returned data) as the very first data, why to duplicate it ??)
I have the same question and never understand why this choice was
made. Maybe it was meant as an extra safety check...
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 :-)
AFAICR, there are also plenty of command APDUs in which multiple
information that is conveyed on different and separate bytes could be
actually packed inside the same byte (or smth. like that) -- again, the
main aim was generality and extensibility of the protocol, rather than
any kind of optimizations from a "protocol-overhead" perspective.
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.
Hope this helps.
Bye,
T.
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://feanor.sssup.it/~tommaso
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
