On 20 April 2010 22:55, Denis Kenzior <[email protected]> wrote: >> > So I re-read that part of the spec, and I can see why we might want it. >> > However, this quote seemed rather interesting: "Le set to '00' indicates >> > that the terminal expects to receive at most the maximum number of bytes, >> > i.e. 256, in the response ADPU. The UICC may return any number of bytes >> > in the range 1 to 256." >> > >> > Shouldn't that 'FF' be changed to '00'? Also, you might want to include >> > the relevant passage or Spec/Section reference in this code so we don't >> > wonder where it came from in the future. >> >> Attached patch adds a comment and changes the FF to 00. I guess it is >> largely theoretical right now. The issue again with "any number of >> bytes in the range 1 to 256" is that this prohibits an empty response, >> which we want to allow too :) Maybe this should be a parameter of >> driver->envelope() > > "The maximum number of bytes expected in the data part of the response APDU is > presented in the parameter Le, which is optional. This means that if the > terminal does not expect any data in the response APDU Le is absent from the > command"
Well, this is an "if" without "only then" so it doesn't tell us the meaning of Le being absent. Additionally the whole passage is later invalidated in 11.2.2.2, so the SIM implementer really has all the possible options. > > The question really becomes, do we actually want a response and know what to > do with it? We only use envelope in CBS data download right now which expects no response, we could indicate that in a parameter. Best regards _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
