Re: [PATCH] alt-charset handling in HTTP SMSC module

Hi,

I don't think there is some possibility to handle this the same way except to don't touch
UCS2 and binary data. There are even some http interfaces where you have to set UCS2
exactly and don't re-encode anything.

Thanks,
Alexander Malysh

Am 13.03.2011 um 17:04 schrieb Rene Kluwen:

> I think the feature "an-sich" (for the ones who speak German) is nice to
> have.
> But in that case, all smsc drivers should handle the case in the same way.
> 
> == Rene
> 
> -----Original Message-----
> From: Alexander Malysh [mailto:[email protected]] On Behalf Of
> Alexander Malysh
> Sent: Sunday, 13 March, 2011 13:59
> To: Rene Kluwen
> Cc: 'Stipe Tolj'; 'kannel_dev_mailinglist'
> Subject: Re: [PATCH] alt-charset handling in HTTP SMSC module
> 
> 100% agree with Rene...
> 
> Alex
> 
> Am 12.03.2011 um 20:11 schrieb Rene Kluwen:
> 
>> I see in both cases UCS-2 data doesn't get re-encoded in the smsc_smpp
> case,
>> according to what you just wrote.
>> What's the problem?
>> 
>> For the same matter, in the http-case, I think re-encoding can be left up
> to
>> the sender, just like in the smpp-case.
>> 
>> == Rene
>> 
>> 
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf
>> Of Stipe Tolj
>> Sent: Saturday, 12 March, 2011 17:08
>> To: kannel_dev_mailinglist
>> Subject: Re: [PATCH] alt-charset handling in HTTP SMSC module
>> 
>> Am 12.03.2011 16:52, schrieb Stipe Tolj:
>>> 
>>> I have reverted this patch due to Alex's veto. Alex tends that we do NOT
>>> re-encode if the coding=[1|2], meaning only msg payloads with coding=0
>> should be
>>> re-encoded.
>>> 
>>> I don't see that actually. Looking into gw/smsbox.c code we see that we
>> have 3
>>> options that a msg struct is bassed to bearerbox:
>>> 
>>> a) msg->sms.coding == 0 (aka DC_7BIT), .msgdata is UTF-8 encoded
>>> b) msg->sms.coding == 1 (aka DC_8BIT), .msgdata has binary data
>>> c) msg->sms.coding == 2 (aka DC_UCS2), .msgdata is UCS-2 encoded
>>> 
>>> ok, let's assume this call to sendsms HTTP interface:
>>> 
>>> http://...&coding=2&text=<url-encoded UCS data>
>>> 
>>> which is a legal injection of a MT message, resulting in a msg passed to
>>> bearerbox which is NOT re-encoded at this stage.
>>> 
>>> Now, if this hits the smsc_http and we have an 'alt-charset' set, which
>> means
>>> the user wants a re-encoding to a specific charset, then the OLD code
>> won't work
>>> out in the smsc_http module.
>>> 
>>> AFAIK, Alex argues that anything coming in with coding=2 should be
>> untouched.
>>> Well, this ASSUMES then that a UCS-2 payload can ONLY be injected this
>> way:
>>> 
>>> http://...&coding=0&text=<url-encoded UCS data>&charset=UCS2
>>> 
>>> to ensure smsbox re-encodes the UCS2 data to UTF-8 internally.
>>> 
>>> IF so, why the heck do we have then coding=2 exposed at the sendsms HTTP
>> interface?
>>> 
>>> Comments please.
>> 
>> ok, digging a bit more, I reviewed how our smsc_smpp code does things in
>> this
>> regard.
>> 
>> For the MT side, msg_to_pd(), the coding == DC_UCS2 is not re-encoded in
> any
>> case, means we send UCS2 payload in the .short_message field.
>> 
>> Now, on the MO side, pdu_to_msg(), we catch in a case statement
> data_coding
>> ==
>> 0x08 (ucs2), and don't re-encode. We set coding == DC_UCS2 here.
>> 
>> So, ergo: IF we expect the MT user to pass a UCS2 message the way I
>> mentioned
>> above to be re-encoded to UTF-8 internally, then we MUST assume the same
> for
>> the
>> MO side, which we don't do.
>> 
>> So, that's why I wanted to handle the coding == DC_UCS2 in the smsc_http
> to
>> be
>> able to re-encode that too for an alt-charset.
>> 
>> Stipe
>> 
>> -- 
>> -------------------------------------------------------------------
>> Kölner Landstrasse 419
>> 40589 Düsseldorf, NRW, Germany
>> 
>> tolj.org system architecture      Kannel Software Foundation (KSF)
>> http://www.tolj.org/              http://www.kannel.org/
>> 
>> mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
>> -------------------------------------------------------------------
>> 
> 
>