> > - 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.
