Skip to main content

Clarification of responsibility with respect to Host Detected CCIF Errors

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
2 replies [Last post]
khendry
Offline
Joined: 2004-08-13

I'd like to know if it is intended that the host detectable errors as defined in the CCIF are expected to be handled above or below the MPEOS layer. A number could be handled at either level since they seem to amount to timeouts firing after sending an APDU. What is the actual intent? Are all vendors porting the RI expected to detect the listed errors and post them to the POD event queue?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cpratt
Offline
Joined: 2008-12-18

I think this question partially needs to be taken up as part of the discussion surrounding CC reset (which are on-going I believe) since many of the host-detectable errors imply a reset (assuming you're talking about CCIF Annex B). A reset certainly needs to be induce-able from below the MPEOS layer and above. But I would expect that most of the conditions are detected (and a reset induced) below the MPEOS level.
In the particular case of APDU sending failures, MPE_POD_EVENT_SEND_APDU_FAILURE exists for signaling send failures. But seeing as there's no defined way to identify which APDU failed, I would think that the timeouts would necessarily need to be detected and handled by the entity which issued the APDU - whether above or below the MPEOS layer - in order to handle the condition appropriately.
Anyway, this is certainly not an answer - as there are 73 conditions in Annex B. However the list of conditions with Host Actions other than "None", "reset", or timeout-related are pretty small and should really be given some attention, IMHO. Are there particular conditions you're concerned about?

khendry
Offline
Joined: 2004-08-13

In particular I am interested in the conditions which state that the user must be informed of the event. The only way we'd be able to do that is to know what event happened at a layer of the stack capable of presenting a UI to the user with the information provided by the event. I'd think the stack would need to display something like the text described in the Annex after the table of events.