Also it includes a detail on the IFDHTransmitToICC: "The driver is NOT
> responsible for doing an automatic Get Response command for a received > buffers containing 61 XX."
First, I have sent many requests or patch to many manufacturers in order
> they support the automatic chaining. :-/ In my opinion the PC/SC application > programmers use the APDU to communicate with the smart card but they don't > want to have the knowledge of the underlying protocol. In my point of view, > the only interest for which the APDU have been introduced, is that it allows > an abstraction over the low layer protocols.
Today, I have printed the part 3 of PC/SC and the remarks on the T=0 of the
> IFD_Transmit_To_ICC seems confirms your position if we want that PC/SC Lite > must compliant with the PC/SC windows version. On theses remarks I have the > feeling that the PC/SC specifications choose a wrong way. Perhaps I am in the > error.
I have run into this same situation writing T=0 firmware for a reader. I have asked around to other smartcard groups, experts, reader firmware writers and even my guru :-) and there is absolutely no consensus on whether or not the reader or the application (or somebody in the middle somehwere) must handle GetResponse.
In my case, I handle it in the reader, but I have complaints from some smartcard application developers that tell me that their apps break because they *expect* to handle the GetResponse processing after a specific APDU - to me, that's just bogus programming, but what can you do?
I am thinking of providing the ability to configure my firmware to enable or disable GetResponse processing, but I haven't figured out a way to do it in a generic and non-intrusive way yet, anyone have any ideas? I'd hate to pick an APDU at random and use that as my reader control APDU and then come to find out later that someone has also chosen that same APDU for some card applet function.
I suppose that I could reserve an AID and use that as a way into my reader's firmware for control/status operations.
mike
-- ---------------------------------------------------------------------------- Michael Bender E-Mail: [EMAIL PROTECTED] Sun Microsystems, Inc. Tel: 831-401-9510 14 Network Circle Tel: x.31807 Menlo Park, Ca. 94025 Mailstop: UMPK14-260 MD: VPN/IMAP
Never give up! Never surrender!
----------------------------------------------------------------------------
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
