I think a driver should do the following:
At Reset CT (ICC) or Request ICC:
* Reset the card.
* Apply default comunication settings: 9600 bps, 1000
ms initial waiting time.
* Detect if the card offers more than one protocol or
D and F are different from the default (1, 372). If so
send PTS and select "best" communication settings: T=1
better than T=0, (why use T=0 if T=1 is available?
there should not be difference from the application
point of view so this would not make drivers
incompatible) and higger offered baudrate (if this
features are implemented by the reader/driver).
Then the application can send commands using this
settings or request a new "reset and PTS" specifying
PTS parameters:
* A CT-API application would call CT_data() to send a
CT command with the PTS request.
* A PC/SC application would specify T=1 in the PCI
parameter of SCardTransmit() and the IFD handler would
reset the card an do PTS.
* The driver would reset the card, and perform PTS as
specified by the application.
If PTS succeeds, the application cand send commands
using the new settings.
--- David Corcoran <[EMAIL PROTECTED]> escribió:
> From: Gil Abel <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: MUSCLE PTS commmand
>
> Hi,
>
> I have though about this many times, and I'm not yet
> convinced what it best
> to do, but I see it like this:
> I agree that is should chooses the best available
> speed, but it is not
> correct to choose T=1 as the default protocol when
> the card offers both T=0
> and T=1. First, according to ISO 7816-3 when both
> protocols are supported,
> the card should offers T=0 first. At my opinion,
> when the user specifies the
> T=1 PCI (at least in the first SCardTransmit after
> reset), then a PPS may be
> invoked by the reader to switch the protocol. I
> think it is better for
> several reasons:
>
> 1. It is more flexible and the user can choose which
> protocol to use.
> 2. Most implementations today will choose T=0 by
> default. Choosing T=1 will
> make PC/SC implementations incompatible.
>
> Gil.
>
> -----Original Message-----
> From: Jim Rees [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 08, 2001 12:39 AM
> To: Smart Muscleheads
> Subject: Re: MUSCLE PTS commmand
>
>
> I think the driver should take care of protocol
> selection, and choose the
> "best" available (highest speed, prefer T=1) without
> bothering the
> application with the details. That's how my
> Todos/PC3 driver is written.
> Does anyone agree with me?
>
***************************************************************
> 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
>
***************************************************************
>
>
***************************************************************
> 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
>
***************************************************************
__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/
***************************************************************
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
***************************************************************
