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

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