Hi,
> I'm posting the new IFD Handler 3 documentation.  It includes support for 
> a new function and also describes the USB bundle approach in some detail.
I have no problem with the USB part and I am happy to see this.
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.

In my opinion, the main standard document is the ISO7816-4 and if the 
IFD_Transmit_To_ICC takes as parameter an APDU, it must follow all the request of the 
ISO (else it may use TPDU). First the application programmer must have the right to 
send all case of APDU he wants without knowing the T-protocol (even a case 4 contrary 
that explains the part 3). Second, in the case 4S.3 of APDU, the ISO explains that 
"The communication system MUST send a TPDU command with GET RESPONSE ...." (excuse me 
for the traduction but I have a french version of this ISO). Imagine the case where 
the reader will be smart. Perhaps it may send itself the get response if it follow the 
ISO7816-4. And in my opinion, if the reader is just a bridge (i.e. a stupid smart card 
reader) sending the received command from the driver to the card, it is the 
responsability to the reader driver to send the GET RESPONSE.

I don't speak here of the case 2S.3 but I think there must also be a chaining. In the 
documentation of PC/SC part 3, I have not see any remarks on this problem.

I hope this post will help to clarify this problem. When we will have choose our way 
we must do an applet to test the PC/SC Lite driver as the applet that I have develop.

Best regards,
Damien Sauveron



-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.musclecard.com/mailman/listinfo/muscle

Reply via email to