[Pcsclite-muscle] What's responsible to filter out Le in Case 4 C-APDUs under T=0?

[Francois Grieu]

I have a confirmed case where passing to SCardTransmit a valid "Case 4(S)" 
Command-APDU, with incoming data followed by Le, leads to a "mute card" error. 
That's under Windows 10, with an IdBridge K30 (SIM-format) reader, specifically 
it's manufacturer-supplied GemCCID 4.1.4.0 driver as obtained thru Windows 
Update, and several T=0 card types.

     00xx xxxx 06 xxxxxxxxxxxx 08
      \    \    \  \            \_ Le
       \    \    \  \_ data in
        \    \    \_ Lc
         \    \_ P1P2
          \_ CLA INS

The problem vanishes, with the card answering SW=6108 (then a Get Response 
getting the 8 bytes of data and final SW as expected) when I either
- remove Le = 08 from the C-APDU
- change the driver to Microsoft's WUDF driver

I understand why the problem occurs and can depend on the driver: the T=0 
protocol is such that the card should not receive the 08, and something has to 
filter it out from the C-APDU (which includes it, see ISO/IEC 7816-3:2006 
section 12.1.1).

My question is: in the PC/SC stack, who should do this filtering ?
1. the application, when it senses that T=0 is used (and then, how)
2. winscard / pcsclite's SCardTransmit function
3. the driver
4. the reader (perhaps per CCID)

References appreciated since in options 2/3/4 I'd want to file a bug report to 
whoever is responsible.

   Francois Grieu