3GPP TSG-T3 (USIM) ah #06				Tdoc T3z00 0029
Navacerrada, Spain, 22 - 23 June, 2000	

Hi,

here are some input from side ragrding the SIM Api testing meeting:

First of all: We can easily refer to the userguide of the APDUIO tool
that is publicy available on our website to define the format of the
input and output scripts to run our test. You can find this in the
"JavaCardKit 2.1.X Developement Kit User's Guide" in chapter 8 Using the
APDUTool there is description of the syntax that is used to send APDU's
to the JCWDE.

Second: Browsing throuw the sourcecode I have received, I think it is
necessary to define / have the following

- package structure and AppletNaming
package and the names of the applet should reflect the testcase. Here is
my proposal

1. level 

org.etsi.tests.api or
org.3gpp.tests.api
(are we writing a 3gpp or *Smg9 specification ? than tests.api ok this
means that this a tests package of an api)

2. next we give the full qualified name of the class we test e.g the
test applet for the EnvelopeHandler fom sim.toolkit will end up with the
package name

org.etsi.tests.api.sim.toolkit.EnvelopeHandler;

Questions: 
a. if we need two or more applets to test especially the framwork
behaviour will we put them in one package or do we need two packages.
maybe:

org.etsi.tests.api.sim.toolkit.EnvelopeHandler.001;
org.etsi.tests.api.sim.toolkit.EnvelopeHandler.002;

The test applet for the EnvelopeHandler functionality should have the
name EnvelopeHandlerTests anny further applet that is needed to test the
functionality should have the name EnvelopeHandlerXXTests where XX is a
numerical value starting with 02.

- programming effiency & -controll of the test

-Can we define some generic part of our testing applet so that we can
write an applet class that is the superclass of all further
testapplet's. This generic applet should allocate the buffer to hold the
outcome of the test. Init the menu entry for the applet, write the AID
into the buffer etc.

-we must define a format for the testoutput. In the cJCK we first write
the AID of the testingapplet into the buffer then a length indicator and
then the "protocoll" bytes of the test. (I would prefer a TLV like
structure of the protocoll)

Also in a first step with the first APDU that comes to the applet we
submit the AID of the applet to be tested, the applet then compares the
AID submitted with the APDU with the AID retrieved from via the JCSystem
class. This gives a way to controll that relay the testcases are
performed that we whant.

We can also implement the process mezthod in a way to retrieve the
protocoll buffer via SELECT, READ BINARY from the applet, only to have a
second way to introspec whats going on in the card. 

- Sourcecode guidelines under
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html you can find
the sourcecode guidelines from Sun for Java programs. We can take this
(its the easiest way because its there and its public, and its not fun
to define your own sourcecodeguidelines). My proposal is here to take
the guidelines from Sun , if annybody of you have its own and whant to
share it with the rest thats fine for me.

-Sourcecode controll: 
Thats the most important I think we must find a way to have the tons of
comming applets under controll. Can we use a sourcecode controll system
(realy professional) ? Can we use the ETSI server to share at one place
our code.

Sebastian
_____________________________________________________________________
Sebastian J. Hans                               
Senior Java Architect                   
Sun Java Center

email: sebastian.hans@Swiss.Sun.Com     Sun Microsystems (Schweiz) AG
Tel: +41-1-9089 205                     Sebastian J. Hans
Fax: +41-1-9089 001                     Javastrasse 2 / Hegnau
mobile: +41-(0)79-286 96 18             CH-8604 Volketswil
                                        Switzerland
_____________________________________________________________________