Peter Williams wrote:
Ok. I've think learned the say the original question (below) properly (no
thanks to the writing style of 7816)
Communicating my ISOIN TPDU to a card applet generate a status word of 61
??, where SW2 is the data available for polling by ISO_OUT 00 0C 00 00 @SW2.
The TPDU is dispatched to an applet method that always generates constant n
bytes of data.
Am I correct that
(A) by controlling the outgoing TPDUs length bytes (Le, and Le), I designate
my command as either ISOIN or ISOOUT...
Mmmh, yes. There is the asynchronous block protocol T=1. This is cool
and does not expect much from the programmer, you send data and get
data. Things are more complicated for the T=0 protocol. For T=0 there
are 4 cases:
(short means that only 255 bytes can be transmitted and 256 can be
reported, there is also long possible meaning 655xy bytes can be send
and reported, but I know no card which supports this ...)
Case 1 short - only a command without command body is send - 4 bytes
Case 2 short - only out data is expected
Case 3 short - only data send
Case 4 short - data send and responded
Some commands must be transmitted in parts ...
These two protocols are familiar to cards. There are more but not used
in practice.
>
(B) the javacard will decide to issuing a 61 pollin response only for ISOIN
form commands?
No or yes. From which side do you look? Means "IN" card sent to the card
or means "IN" card to the card terminal? 61 means there are response
data which must be retrieved by GET RESPONSE. Here is an expert from the
Java Card spec.:
// Lr < Le
// 1. The card sends <0x61,Lr> completion status bytes
// 2. The CAD sends GET RESPONSE command with Le = Lr.
// 3. The card sends Lr bytes of output data using the standard T=0
<INS> or <~INS>
// procedure byte mechanism.
// 4. The card sends <SW1,SW2> completion status on completion of the
// Applet.process method.
// Lr > Le
// 1. The card sends Le bytes of output data using the standard T=0 <INS> or
// <~INS> procedure byte mechanism.
// 2. The card sends <0x61,(Lr-Le)> completion status bytes
// 3. The CAD sends GET RESPONSE command with new Le <= Lr.
// 4. The card sends (new) Le bytes of output data using the standard
T=0 <INS> or
// <~INS> procedure byte mechanism.
// 5. Repeat steps 2-4 as necessary to send the remaining output data
bytes (Lr) as
// required.
// 6. The card sends <SW1,SW2> completion status on completion of the
// Applet.process method.
(C) a correctly formatted ISOOUT TPDU will (normally) generate a response
which does NOT require the polling process?
For T=0 there is always a GET RESPONSE command necessary.
(2) my musclecard always supplies polling responses : which the
application
must then poll to recover the data.
This should do the MuscleCard library for you. It automatically executes
a GET RESPONSE command. Just right now I see a bug, because it does this
only for the first 0x61 and it does not fetch 0x6c ... But this is
another story and does not matter if the expected length is correct.
What's the magic to have the musclecard provide the service response in
the
APDU, without using the polling process? Again, I want to save needless
roundtrips
Use a card with T=1. For T=0 this was not meant to be.
Regards, Karsten
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
