RE: Kannel is suffering [Really idea for dealing with SMPP TLV andEMI TTLLDD)]

> 
>  - SMPP and EMI both have extra parameters or options that can
>    be passed back and forth between the SMSC Servers and the
>    SMSC clients.
>  - The extra parameters are proprietary to the SMPP or EMI
>    specifications and cannot be abstracted to be used by other
>    SMSC client implementation.

And I am seeing them used more and more in real live situations,
particularly for premium billing in networks. They are here to
stay and becoming more popular.

>  - Kannel development Standard Operation Procedure is to keep
>    SMSC specific features and capabilities out of the abstract
>    representation of an SMS as declared by the SMS Msg structure.

This is a great *objective*.

Historical note - back in 2001 I provided an extensions mechanism for
the Msg struct to the list. It was rejected at the time but I used it
and continue to use it for the purposes described above.

I've worked with protocols and encodings for a long long time. And each
one has displayed symptoms as described above. Consider that HTTP and
SMTP have X- headers for ad-hoc extensibility, X.509 has extensions etc.

IMHO, anything thats used in the real world needs a bit bucket to
support
the various business cases that evolve around it.