You are right!
;) This shows all the interest of technology such as RMI , making the
function independant of the transport protocol (something famous in the IT,
but it seems hard to come to the card).
CH
At 12:09 29/03/2001, Gil Abel wrote:
>Hi,
>
>I generally agree with you, but it may worth to consider that some important
>smart card standards, e.g. PC/SC and EMV, do NOT support VPP (I think memory
>cards are not relevant to this discussion), and if your application needs
>only to be EMV compliant for example, you may consider using odd
>instructions if you have very good reasons to do so...
>
>Of course, it is always better to use only even INS codes and be compliant
>to ISO 7816.
>
>Gil.
>
>-----Original Message-----
>From: Cedric Huet [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 29, 2001 11:15 AM
>To: Sebastien Jean; [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: [OCF] CLA, INS, SW available/reserved values
>
>
>Hi,
>Sorry Sebastien but I disagree with that. Please considere following
>arguments and make your own opinion.
>
>In some cases the ACK could be !INS xor 1, that's why INS should not be an
>odd one.
>
>That's not because some samples seems to work that they are compliant with
>the standards! Beeing compliant with the standard meens reaching
>interoperability at APDU level, which is a great chance for your applet to
>work with as much readers as possible!
>It's always better this way, but everyone is free to interpret the standard
>is own way.
>You can afford to brake some few sprayed standards, but there are millions
>of smart card readers in the world, and this success is due to the ISO 7816
>standard. None one in the card industry ignore that!
>
>There were a mistake in the examples of the GemXpresso 211 Kit (v 2.x), the
>samples of GemXPresso RAD III kit have been corrected ;)
>
>For memory here is an excerpt from the ISO 7816_3 standard:
>"INS is an instruction code in the instruction class. The instruction
>code is valid only if the least significant bit is 0, and the most
>significant half byte is neither 6 nor 9."
>
>The ACK with bit b0 set is only possible when VPP is used, and I agree this
>does not often happen with micro-chip cards (most of the time this is for
>memory cards), but once again beeing compliant with the standard is better.
>Somedays your card may encounter a reader which strictly apply the
>standard, and hence reject the card! It'll be to late!
>
>The following URL is interesting for information purpose only, do not
>considere it as a reference:
>http://www.scia.org/aboutSmartCards/iso7816_wimages.htm
>
>It may be considered as a mistake that the standard sometime mixes the TPDU
>level with APDU level (and I agree with that), but it's to late to get
>back, and this is not such a great trouble to have some constraints on INS
>byte.
>
>Hope this will help.
>Cheers,
>
>CH
>
>At 08:56 29/03/2001, Sebastien Jean wrote:
> > > INS must not be an odd one (1 3 5 ...) due to ACK protocol at transport
> > level.
> > > CLA Must no be any 6X or 9X, most of the time user app may use 00. ISO
> > > standards indicates partitions in CLA, with reserved, forbidden and free
> > > ranges.
> > > SW1 must be one of 6X or 9X
> > >
> > > Reading ISO 7816_3 and 7816_4 standards is strongly recommanded.
> > >
> > > 90 00 ;)
> > > CH
> >
> >I do not think that INS byte is so constrained, none of both GemXpresso211
>and
> >Sun's examples mention such parity.
> >The examples are running, and since the ack is INS (or !INS, i am just
> >awaken ;-)
> >), why the transport protocol should work only with odd INS numbers ?
> >I agree with you while saying that SW1 should be 6X (problem) or 9X
> >(normal), but
> >in the case of OCF use, it is possible to use SWs that are not compliant
> >to ISO if
> >needed.
> >Standards are just contexts, often broken, as bluetooth example.
> >
> >cheers,
> >Baz
> >
> >--
> >Sébastien Jean (a.k.a. Baz)
> >PhD candidate
> >LIFL - Université des Sciences et Technologies de Lille,
> >Batiment M3, bureau 111, F-59655 Villeneuve d'Ascq Cedex
> >France
> >Tel : (+33/0) 320 336 132 , Fax: (+33/0) 320 436 566
> >mailto:[EMAIL PROTECTED] , http://www.lifl.fr/~jean
> >"if you are aware...you can succeed(Jean-Claude Van Damme)"
> >
> >
> >
> >
> >---
> > > Visit the OpenCard web site at http://www.opencard.org/ for more
> > > information on OpenCard---binaries, source code, documents.
> > > This list is being archived at http://www.opencard.org/archive/opencard/
> >
> >! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
> >! to
> >! [EMAIL PROTECTED]
> >! containing the word
> >! unsubscribe
> >! in the body.
>
>
>
>---
> > Visit the OpenCard web site at http://www.opencard.org/ for more
> > information on OpenCard---binaries, source code, documents.
> > This list is being archived at http://www.opencard.org/archive/opencard/
>
>! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
>! to
>! [EMAIL PROTECTED]
>! containing the word
>! unsubscribe
>! in the body.
>
>
>---
> > Visit the OpenCard web site at http://www.opencard.org/ for more
> > information on OpenCard---binaries, source code, documents.
> > This list is being archived at http://www.opencard.org/archive/opencard/
>
>! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
>! to
>! [EMAIL PROTECTED]
>! containing the word
>! unsubscribe
>! in the body.
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
