Re: please reconsider the +0 you gave the patches

Peter Christensen <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel,gmane.spam.detected
Message-ID <[email protected]>
Hi,

Apparently the patch was not as self-explanatory as I expected (or my 
English is poor :p)...

The cp1252 patch break absolutely nothing, as far as I see. It does 
change default charset from being ISO-8859-1 to WINDOWS-1252. People 
familiar with the two charsets will know that WINDOWS-1252 (or CP1252) 
is in fact ISO-8859-1 with the control characters 0x80 - 0x9F used for 
printable characters. (See http://en.wikipedia.org/wiki/Windows-1252 and 
  http://en.wikipedia.org/wiki/Iso-8859-1). So the actual only 
difference is that you can transmit the € character (with value 0x80).
The funny thing is that the charset_latin1_to_gsm() and 
charset_gsm_to_latin1() have always assumed WINDOWS-1252 as the 
character set, so I actually assumed that it was a mistake that you used 
ISO-8859-1.
I personally give the cp1252 patch a +1

I am somewhat ambivalent about the alpha_gsm patch. It encodes the 
source_addr with charset_latin1_to_gsm() if the address is alphanumeric, 
which is actually expected on all the "correct" gateways I've tried. But 
there is probably just as many gateways which does NOT expect this 
behavior, and although these are gateways that often break several other 
things from the SMPP spec, and the conversion is probably the correct 
thing to do, there should probably be an option to turn this feature on/off.
European mBlox gateways will still be able to work, as they are already 
forced to set alt_charset=iso-8859-1 (and thus the source_addr is also 
encoded as such).
The most significant problem with the alpha_gsm patch is that the GSM 
charset is not suitable for zero-termination due to the encoding of the 
@ character. Actually the SMPP spec says nothing about what charset is 
expected in the source_addr, nor does it strict the "default charset" to 
anything, so in a way, using iso-8859-1 or windows-1252 in source_addr 
is just as correct as using GSM. Question is really what is most common 
around the world.
My personal vote is +0 for this patch.
It is a definite improvement when used with the bunch of gateways, I'm 
using at a regular basis (those which did not work usually had bad 
coverage, limited features, or simply broke a lot of other specs - 
remember my pack_udh patch for instance, gah), but at the cost of the @ 
character. On the other hand, I fear that there is a large amount of 
gateways out there, which will not agree with this behavior.

-- 
Med venlig hilsen / Best regards

Peter Christensen

Developer
------------------
Cool Systems ApS

Tel: +45 2888 1600
  @ : [email protected]
www: www.coolsystems.dk


Stipe Tolj wrote:
> Hillel wrote:
> 
>> Dear Alex,
>>
>> Please if the diffs from Peter are in the correct format will you 
>> consider
>> installing into CVS the kannel.smpp.cp1252.diff and
>> kannel.smpp.alpha_gsm.diff.
>>
>> I've been emailing Peter and he explained the two patches gives 
>> support for
>> € in both alphanumeric numbers as
>> well as the actual message body. Its also helps to send many other
>> characters.
>>
>> This is very useful.
>>
>> Please re-consider your +0 you gave the patch.
> 
> from my perspective, I'm also +0 for this, actually even +1 if it really 
> does not break any "common behaviour".
> 
> What impact does the CP1252 charset patch actually have?
> 
> I'd like to have a bit more "explanation" arround it before digging into 
> it deeper.
> 
> 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
> -------------------------------------------------------------------
>
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.