Recently, there was some discussion about how to handle the T=0 protocol in
OpenCard, or to be more exact, how to handle T=0 Case 4. This is the case
where the card indicates that its result has to be obtained by sending a
subsequent GetResponse command. The return code indicating this case is
0x61 XX, where XX is the length of the response to be retreived.
When designing the OpenCard Framework, we defined the card terminal layer
role in communication with cards as follows: The card terminal layer
transparently sends command APDUs to smart cards and returns the response
APDUs. It does not interpret or modify the transmitted APDUs in any way.
It is important to have such a transparent communication path. Only some
examples: How would a card applet programmer be able to test how a T=0 card
reacts if a wrong GetResponse command is sent to the card after obtaining
61 XX if the card terminal driver handles this automatically ? What if
someone wrote an Applet for a T=1 JavaCard that returns 61 XX due to a
programming error ?
All interpretation of APDUs is the task of the card service layer. Card
services have the responsibility of handling the application protocol
required by the card - even if the application protocol has a special case
due to the missing support for two way flow in T=0.
Best Regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division - Smart Card Solutions
E-mail: [EMAIL PROTECTED] Tel.: ++49-7031-16-3479 Fax.:
++49-7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
[EMAIL PROTECTED] on 14.04.99 05:24:43
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED] (bcc: Thomas Schaeck/Germany/IBM)
Subject: Re: [OCF] Card Terminal behaviour when SW1=0x6c
In einer eMail vom 13.04.99 17:15:10 MEZ, schreiben Sie:
<< Thema: [OCF] Card Terminal behaviour when SW1=0x6c >>
Hi,
in my eyes, the transport layer of the CardTerminal implementation
- i.e. the clases that manage the exchange of APDUs according to an
ISO-7816 protocol T=x - is responsible for handling the '0x6C 0xLe' case,
where 0xLe gives the correct number of bytes generated by a card command.
A CardServivce (running somewhere between OSI presentation and application
layer) should be isolated as much as possible from protocol specific tasks.
In general, it must work with every card 'understanding' the command APDUs
transmitted, whether speaking T=0 or T=1.
Best regards.
----------------------------------------------------------------------
Markus A. Stulle - Schlei�heimer Stra�e 70 [EMAIL PROTECTED]
D-80797 Muenchen - Germany
Tel./FAX: (+89) 520 59 001, GSM: (+171) 213 - 70 84
GSM-FAX: (+171) 214 - 84 74, GSM-Data: - 86 74
AOL-FAX: (+40) 36 03 - 02 00 16
'Java Madman' Current Java version is: Java 2
Available at: http://java.sun.com/products/jdk/1.2
-----------+===+------------------------------------------------------
> press |ESC| key once to abort program or twice to continue! <
-----------+===+------------------------------------------------------
Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
access to documentation, code, presentations, and OCF announcements.
---------------------------------------------------------------------------
--
To unsubscribe from the OCF Mailing list, send a mail to
"[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of
the
message.
