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

Stipe Tolj <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Organization tolj.org system architecture
Message-ID <[email protected]>
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
-------------------------------------------------------------------
smime.p7s (application/pkcs7-signature, 5.8 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.