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:malys...@googlemail.com] 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: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] 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 > ------------------------------------------------------------------- >
smime.p7s
Description: S/MIME cryptographic signature
