Tomasz Knapik

Na TVN Warszawa był właśnie wywiad z Tomaszem Knapikiem. I nie dał się słuchać. Brzmiało jak wywiad z dubbingiem 😉

A Pan Tomasz będzie czytał komunikaty w autobusach. To w uzupełnieniu Ksawerego Jasieńskiego w metrze. Cekawe co będzie czytał Lucjan Szołajski (nie napisali nic o nim na wikipedziach!!! skandal!)…

Reklamy

Upgrade

Upgrejdnąłem WordPressa do najnowszej wersji. Duuuuże zaległości w tym temacie były. Śakiś inny jest od strony administracji jest. Chyba wszystko działa.

ajfon

Kilka pierwszych wrażeń z używania ajfona:

  • wreszcie telefon z pudełkiem w sensownym rozmiarze
  • ten kto wymyślił rozwiązanie z kartą SIM jakoś niespełna rozumu był; a już narzędzie do wyjmowania karty SIM rozwala mnie na maksa
  • iTunes jest koszmarnym programem; zwłaszcza do synchronizacji
  • nadal nie wiem jak zsynchronizować zdjęcia z ajfona do komputera (jak ktoś wie to się chętnie dowiem)
  • zdjęcia robi dość słabe, słabsze niż Nokia e71
  • można podłączyć tylko jeden serwer Exchange, ale udało mi się zsynchronizować i kalendarz i kontakty
  • AppStore to jakaś najbardziej przereklamowana rzecz na świecie; ani to wygodne, ani specjalnie ciekawych aplikacji nie ma; ale pewnie jak zawsze – nie jestem targetem…
  • konfiguracja ajfona nie jest tak intuicyjna jak podobno jest; ani bardziej intuicyjna od konfiguracji Nokii ani czegokolwiek innego; a suwaki pokazujące czy opcja jest włączona czy wyłączona doprowadzają mnie do szału:

iPhone

  • no i mnóstwo ukrytych funkcji, o których nie ma jak się dowiedzieć poza szukaniem w internecie (np. jak zrobić screenshota, jak wyjąć kartę SIM, …)
  • za to przeglądarka rządzi

No i póki co nadal używam Nokii e71 jako telefonu.

About specifications

Recently we had reported several problems regarding PDU SMS decoding in gnokii. Apparently gnokii was unable to decode several messages that included TP-Parameter-Indicator field. Together with Daniele we’ve come across a specification, namely ETSI TS 123 040. There in chapter 9.2.3.27 it describes this field. And I think it is not clear what it claims. At least we and Nokia have different interpretations.

The most significant bit in octet 1 and any other TP-PI octets which may be added later is reserved as an extension bit which when set to a 1 shall indicate that another TP-PI octet follows immediately afterwards.

So, does it mean that there could be several TP-PI octets in row? If so, which one is the valid one? And how does it relate to SMS-SUBMIT-LAYOUT (9.2.2.4) which says that it is just 1 octet?

SMS-STATUS-REPORT layout

Further reading brings more information:

If a Reserved bit is set to „1” then the receiving entity shall ignore the setting. The setting of this bit shall mean that additional information will follow the TP-User-Data, so a receiving entity shall discard any octets following the TP-User-Data.

I completely don’t understand what is the reason for that. We say that there is additional information but it should be ignored? It’s beyond my perception.

Getting back to the problem. The general layout of TP-PI looks as follows:

TP-PI layout

And we had the following octets in the problem report:

  1. 0x9F (1001 1111): extension bit set, 2 reserved bit set, TP-UDL set, TP-DCS set, TP-PID set

Now, depending on interpretation of the specification, we can interpret differently the sequent octets. There are three:

  1. 0xD6 (1101 0110)
  2. 0xE4 (1110 0100)
  3. 0x94 (1001 0100)

First interpretation, is that TP-PI can be followed by next TP-PI octet, based on value of bit 7. All these records have it set, so we go till the last octet which would be TP-PI as well, but then there’s no room for at least TP-UDL which should be set. Doesn’t look right.

So, second interpretation (along with SMS-STATUS-REPORT layout): TP-PID, TP-DCS and TP-UDL will follow TP-PI octet. So we have:

  1. TP-PID: 0xD6, indicating that it is message for SC (Service Centre) specific use
  2. TP-DCS: 0xE4, indicating Message Waiting type (however it uses bit 2 which is reserved)
  3. TP-UDL: 0x94, which does not make sense as there are no more octets

So this interpretation looks even worse than the previous one. I’m used to bugs in software but this one really confuses me: I have no idea what would be a good way to interpret the message from the report. I’m committing the change that incorporated the first interpretation and doesn’t bother with missing TP-PID, TP-DCS, TP-UDL octets.

To summarize: specifications are good, but not all of them. Really try to be precise and unambiguous when writing a specification.