Carlos,
You hit the nail right on the head ! For those that don't understand that saying, I'm telling Carlos that using the CTBCS through Control function is probably the best approach. In fact I would like to add some to that. Instead of linking those PPS values directly into the card plug-in, I propose that I add KEY/VALUE pairs to the Info.plist XML file that is used with the card plug-ins. So the pluggable card architecture for MUSCLE uses the bundles also if I didn't mention that. No longer is there a card.conf. The bundle directory is now in /usr/local/pcsc/services. I'll add some PPS defines in the XML file so that the user may change them if needed without recompiling. Anyone propose the best way to do this ????? Dave On Sun, 9 Dec 2001, Carlos Prados wrote: > Hi, > > Automatic setting of the PPS parameters by the IFD > Handler would be fine, but as Axel argumented in the > previous e-mail, it's an utopia. > > There are some objections more to the automatic PPS > approach: > > * What if the card asks for a PPS parameter not > supported by the IFD? > > For instance, Cyberflex access specifies in it's ATR > the ability to use F=512, D=8. With CLK=3.5 MHz this > gives 55800 bps, wich is not supported at least by > Towitoko IFD. > > The authomatic solution could be to use the default > 9600 bps baudrate. But Cyberflex can do other > supported baudrates like 38400 bps, without this > setting being indicated nowhere but in the smartcard's > SDK documentation. > > * What if the card's ATR is not extriclty compliant > with ISO 7816-3 and the IFD Handler takes an erroneous > PPS setting? > > IMHO, the correct approach would be to leave PPS for > the card abstraction layer, and for the application > layer. > > But we need a way for the pscsclite user to be able to > specify the correct PPS setting. > > This leads to the next point. The problem with > modifiying SCARD_IO_HEADER is that it would make old > IFD Hanlder's binary incompatible with newer ones, as > a pointer to this structure is passed to the > SCardTransmit function. > > There are some binary-only IFD Handlers out there. > Also there are also some drivers that haven't being > changed in years, even when the IFD Handler has > evolved to support new features and to fix defects. > > The first consecuence is that the pcscd is still tied > to the ugly IFD Handler 1.0 definition for > compatibility with most drivers. The second is that we > must be very carefull with wich changes we introduce > in the IFDH definition, as they can break > compatibility. > > So in conclussion I think that modifiying > SCARD_IO_HEADER and SCARD_IO_REQUEST would be the > _OPTIMAL_ solution for the problem, but it would _not_ > be the _BEST_ solution. > > Maybe defining some pseudo-standard command to > IFDHControl() in the IFH handler developers kit and > IFD Hanlder skeleton, as David pointed. > > So I propose to use the CT-BCS semantics in the > transmission buffer of the IFDHControl() function, and > extend the RESET CT command with the ability to convey > the PPS request in it's data field. > > This way the user can send: > > 0x20 0x11 0x01 0x01 0x06 PPSS PPS0 PPS1 PPS2 PPS3 PCK > > The number of PPS bytes could be decided by the user. > > However, simpler commands could be defined for this > task. > > Thanks, > Carlos. > --- Axel Heider <[EMAIL PROTECTED]> wrote: > > David, > > > > > DC: I'm forwarding this bounced message but I want > > to comment on Carlos's > > > DC: email. That approach would be fine, lets see > > what the others think. > > > DC: I suppose you could also use SCardControl and > > we could design a PPS > > > > > DC: structure .... Does anyone know how it is done > > on Win32 ? > > > > I asked this question in the Microsoft SmartCard DDK > > Mailinglist > > some time ago. They told me it's up to the driver to > > check the > > ATR setting and apply a PPS/PTS. Furthermore, the > > SMCLIB can > > assist by translating the ATR and tell the driver > > what to do. > > > > All you can do manually in you application is > > setting a parameter > > during tha call to SetProtocol: > > > > from WINSMCRD.H > > > > #define SCARD_PROTOCOL_UNDEFINED 0x00000000 > > // There is no active protocol. > > #define SCARD_PROTOCOL_T0 0x00000001 > > // T=0 is the active protocol. > > #define SCARD_PROTOCOL_T1 0x00000002 > > // T=1 is the active protocol. > > #define SCARD_PROTOCOL_RAW 0x00010000 > > // Raw is the active protocol. > > #define SCARD_PROTOCOL_DEFAULT 0x80000000 > > // Use implicit PTS. > > > > // Since using the optimal parameters is the > > default case > > // no bit is defined to be 1 > > > > #define SCARD_PROTOCOL_OPTIMAL 0x00000000 > > // Use PTS to optimize protocol. > > > > This leaves some questions: > > > > * What really is the optimal setting for any card? > > * What if the card's ATR does not tell the optimal > > setting? > > * What if the optimal setting for my > > application/environment > > is not the setting given in the ATR? > > > > Unfortunately, there is no way to issue a PPS/PTS > > via PC/SC > > manually in Windows. And so we have many > > vendor-specific > > implementation, which offer a proprietary way. > > > > > > > > Axel > > > > > > > *************************************************************** > > Unix Smart Card Developers - M.U.S.C.L.E. > > (Movement for the Use of Smart Cards in a Linux > > Environment) > > http://www.linuxnet.com/ > > To unsubscribe send an email to > > [EMAIL PROTECTED] with > > unsubscribe sclinux > > *************************************************************** > > __________________________________________________ > Do You Yahoo!? > Send your FREE holiday greetings online! > http://greetings.yahoo.com > *************************************************************** > Unix Smart Card Developers - M.U.S.C.L.E. > (Movement for the Use of Smart Cards in a Linux Environment) > http://www.linuxnet.com/ > To unsubscribe send an email to [EMAIL PROTECTED] with > unsubscribe sclinux > *************************************************************** > *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
