what you accept″. It should use a minimal set of features which are necessary to accomplish a task. And if the goal is communication and not quibbling, each implementation should overcome minor nonconformities with standard: Respond with a generic_nack with command_status=3 to any unrecognised SMPP command, but do not stop the communication. Ignore any unrecognised, unexpected or unsupported TLV parameters. The borders of PDUs are always given by the PDUs' command_length field. Any message field must not exceed the end of PDU. If a field is not properly finished, it should be treated as truncated at the end of PDU, and it should not affect further PDUs. Information applicable to one version of SMPP can often be found in another version of SMPP, for example with the case of SMPP 3.4 describing the only mechanism of delivery receipts in SMPP 3.3 described above. Security The SMPP protocol is designed on a clear-text binary protocol which needs to be considered if using for potentially sensitive information such as one-time passwords via SMS. There are, however, implementations of SMPP over secure SSL/TLS if required. See also Universal Computer Protocol/External Machine Interface (UCP/EMI) Computer Interface for Message Distribution (CIMD) Rich Communication Services References External links Short Message Peer-to-Peer Protocol Specification v3.3 Short Message Peer-to-Peer Protocol Specification v3.4 Short Message Peer-to-Peer Protocol Specification v5.0 SMPP v3.4 Protocol Implementation guide for GSM / UMTS SMPP v3.4 Implementation Guide for WAP SMPP implemented in Java SMPP Wireshark GSM standard Mobile technology Network protocols