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
> -------------------------------------------------------------------
>