Dziugas,
Finally got around to reading the STI spec! Comments below.
On May 13, 2005, at 13:17, Dziugas Baltrunas wrote:
Hi Paul,
thanks for the comments.
GSM networks always pick up IMEI for one reason or another, and
relating that to IMSI/MSISDN should not be a problem. Going from IMEI
to phone model, from what I've seen, is messy, not least of all
because you have to keep an up-to-date database mapping IMEI to phone
model. (To complicate matters further, IMEI format changed at some
point in 2003, so you need to be able to parse multiple formats.)
It actually _seems_ that GSM Association provides IMEI-to-phone
database for their members. I hope to clearify this soon.
One would tend to think that the UAProf approach is actually much
nicer. It places responsibility on the device to announce its
capabilities. If that information is faulty, then surely we cannot
blame the MMSC! UAProf does not assume that the device is a mobile
phone either, hence IMEI/MSISDN are not mandatory.
So, a thought: What about keeping a mapping between MSISDN and
UAProf? This information can be collected on-the-fly for later use.
I agree with such aproach in case we have request-response model. But
what to do when we're going to deliver some content using the pull
(WAP push) or similar model? Another problem is that such database
must be kept up to date as users have a habit to change their device
sever times per day, still using the same MSISDN.
Paul, what about your objections on OMA-STI?
STI is actually quite interesting at first read. By specifying a
standardised protocol between an application and a content adaptation
server, we can see a situation where the content servers (MMSCs,
photo servers, etc) are simplified. STI also provides for much more
generalised content adaptation (for images 'mirror' and 'sharpen',
among others, are defined). It would be interesting to see who's
using this standard.
From what I can see though, the question of device capabilities
(profile) is not answered. One still has to find out the device
capabilities some way other!
--
Dziugas
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org
