Re: Patch: smsc_smpp.c

This is true that SMPP spec don't define DLR format but give only  
recommendation but this recommendation was adapted
by 99% SMSC maker and is quasi standard. If someone think that he can  
ignore such fact we will ignore this SMSC maker
and user who connecting such SMSC have to ask SMSC operator/maker why  
they ignore quasi standard.
The more people ask the more SMSC operator/maker will think about to  
fix this issue.

Thanks,
Alexander Malysh

Am 23.10.2009 um 11:43 schrieb Nikos Balkanas:

> Unfortunately mail archives list only first few mails. Many  
> experienced contributors, like Alejandro, Milan and Seikath, hold  
> the opinnion that this recommendation is an example, not an SMPP  
> spec, and therefore more flexible. I myself consider it more  
> strictly, as a spec.
>
> However, no matter how you look at it, it is an ommision in the  
> code, if the old parser considers only spaces and neglects string  
> endings. I am not talking about free text parsing here. I still  
> consider formal tags mandatory. Besides the change in code is  
> trivial and minimal.
>
> From the discussion, both Stanic and Seikath have branched off with  
> their own versions. This is unfortunate.
>
> I am attaching the last mail, which includes most previous ones.  
> Please take the time to read some of it.
>
> BR,
> Nikos
> ----- Original Message -----
> From: Alexander Malysh
> To: Nikos Balkanas
> Cc: [email protected] Devel
> Sent: Friday, October 23, 2009 12:03 PM
> Subject: Re: Patch: smsc_smpp.c
>
> Hi Nikos,
>
> ok got it...
>
> We have such discussions many times already and we always got to  
> decision that kannel can't and should't
> support things that are not standard except it easy to integrate and  
> has no impact on the code readability,
> security etc.
>
> I don't think we have to patch DLR parsing in SMPP due to this clear  
> SMSC bug. This is some homegrown SMSC
> just don't accept quasi standard. This SMSC should be fixed and not  
> kannel...
>
> Thanks,
> Alexander Malysh
>
> PS: I think we should have this configurable and regex group  
> matching should do it...
>
> Am 22.10.2009 um 19:24 schrieb Nikos Balkanas:
>
>> Sure.
>>
>> http://www.mail-archive.com/[email protected]/msg17659.html
>> ----- Original Message -----
>> From: Alexander Malysh
>> To: Nikos Balkanas
>> Cc: [email protected] Devel
>> Sent: Thursday, October 22, 2009 5:58 PM
>> Subject: Re: Patch: smsc_smpp.c
>>
>> can you please give me link to this discussion?
>>
>> Thanks,
>> Alexander Malysh
>>
>> Am 22.10.2009 um 13:17 schrieb Nikos Balkanas:
>>
>>> Hi,
>>>
>>> Oh boy. You missed all the fun :-)
>>>
>>> Original email by Latitude Test on 13/10/2009, where DELIVERD DLRs  
>>> are misreported by kannel as failures (type 2). There was quite a  
>>> discussion about whether it was a kannel bug, or an out of spec  
>>> DLR. In the end it was a consensus that kannel needed a patch.
>>>
>>> Bottom of the line: Spec is very loose at this point about DLR  
>>> fields. Kannel expects either an exact format (sscanf) or it  
>>> reverts to a more flexible old style search. Problem is that in  
>>> the search it assumes that the value of each field is followed by  
>>> space, and that is not necessarily true (if field is last in DLR).
>>>
>>> Seikath also said that he has a couple of cases like that.
>>>
>>> BTW, I have asked Latitude to test it, because I cannot, but he  
>>> seems to get disappeared after creating all this stir :-(
>>>
>>> BR
>>> Nikos
>>> ----- Original Message -----
>>> From: Alexander Malysh
>>> To: Nikos Balkanas
>>> Cc: [email protected] Devel
>>> Sent: Thursday, October 22, 2009 11:08 AM
>>> Subject: Re: Patch: smsc_smpp.c
>>>
>>> Hi Nikos,
>>>
>>> could you please explain why we need this patch?
>>>
>>> Thanks,
>>> Alexander Malysh
>>>
>>> Am 19.10.2009 um 18:30 schrieb Nikos Balkanas:
>>>
>>>> Hi,
>>>>
>>>> A trivial patch, that should be able to handle all DLRs as long  
>>>> as they keep formal tags.
>>>>
>>>> Please test.
>>>>
>>>> BR,
>>>> Nikos<smsc_smpp.diff>
>>>
>>>
>>
>>
>
> <Re_ getting delivery report_ delivery failure.txt>