The statment by Thomas Schaeck is clearly not representing what ISO is 
     defining as an APDU (He refers clearly only to the transport layer).
     To our understanding the Card Terminal driver must hide this 
     implementation totaly from the Card Service. It is anyhow unclear who 
     is talking in T=0 to whom. The communication between card and terminal 
     may be in T=0 but the Terminal will talk with the Host in T=1 (in this 
     case the Terminal may already handle the 61 XX by itself) or 
     viceversa.
     
     The nice feature of the OpenCard Framework is that you can write Card 
     Services which will work without having to deal with implementatiomn 
     details. The APDUs (C-APDU and R-APDU) are protocol independent and 
     the mapping of TPDUs to APDUs for T=0 is defined in ISO/IEC 7816-3 and 
     7816-4:
     To our understanding a good card terminal driver should also perform 
     the re-issuing of commands in T=0 case 2 when the card responds with 
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: schaeck@de.ibm.com       Tel.: ++49-7031-16-3479       Fax.: 
++49-7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 
Boeblingen, Germany

     
MarkStulle@aol.com on 14.04.99 05:24:43
     
Please respond to MarkStulle@aol.com
     
To:   opencard@opencard.org
cc:   barberj@nwdt.natwest.co.uk (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          MarkStulle@aol.com
                   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 
"opencard-request@opencard.org" with the word "unsubscribe" in the BODY of 
the
message.

o 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 
"opencard-request@opencard.org" with the word "unsubscribe" in the BODY of 
the
message.

o 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 
"opencard-request@opencard.org" with the word "unsubscribe" in the BODY of 
the
message.

o 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 
"opencard-request@opencard.org" with the word "unsubscribe" in the BODY of 
the
message.

o 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. 
--------------
m