Hi,
I have a few questions about PC/SC Part III
In 3.1.1 they say: "The IFD Handler shall then notify the callin gprocess
using an appropriate inter-rpocess signaling mechanism. The specific
signaling mechanism to be implemented is OS dependent and is beyon dthe
scope of this specification"
How is this implemented in our PC/SC driver?? Are we using IPC functions??
And another interesting thing is in 3.1.3 (ICC Events)
"The IFD subsystem shall support the following ICC-related events:
o Card insertion notification
o Card removal notification
When one of these events occurs, it is the responsibility of the IFD Handler
to notify the ICC Resource Manager layer"
How is this implemented in our drivers???
3.1.5.3 T=1 Protocol Support:
"From the ICC Service Provider perspective, an IFD Subsystem shall accept
APDU's, construct the necessary T=1 blocks to convey those APDU's and
asynchronously return the response from the ICC. It is implicit that the ICC
Service Provider has the right to transmit the first such block. The IFD
Subsystem must at all times track whether it, or the ICC has the right to
transmit, an IFD subsystem may return an error if an ICC Service Provider
attempts to initiate a block transmission request."
how do we track at all times who should be able to transmit blocks if we
don't konw who has tranmsitted the last block because it's only impelmented
in a shared object with functions...
maybe I missed something important :)
After reading this document I think that IFD Handlers should be implemented
as RPC routines and a watching daemon which can notify the ICC Resource
Manager if an event occurs... But I don't think if this is implemented at
the moment or how you work around that and if it's compliant with the
standard to work around that...
are there any later specifications than the ones at smartcardsys.com ??
because they have been written in 1997 and 3.1.5.4 says: "... will be
clearly specified in the 1.1 release of these specifications (in early
1998)..." and I think the early 1998's aren't future any more...
Part 3 section 3.2 lists optional Functionality... But do we have to
implement this returning an error code??? Or do we just don't implement
them???
At the moment it returns an error code...
RESPONSECODE IFD_Confiscate_ICC() {
RESPONSECODE lRetVal;
lRetVal = IFD_ERROR_NOT_SUPPORTED; // This is not supported.
return lRetVal;
}
And can you please give me an example how to implement Vendor-specific
features mentoined in 3.2.4 ???
I hope it's okay to ask these questions on this list because I think they
are interesting to everyone :)
Hopefully this was everything... maybe I have some other questions later...
thanks for your time,
gerhard
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
