and ″empty″ message_id. SMPP 3.3 explicitly states about the message_id field ″If absent this field must contain a single NULL byte″. The length of the PDU is at least 17 octets. SMPP 3.4 contains an unfortunate note in the SUBMIT_SM_RESP section ″The submit_sm_resp PDU Body is not returned if the command_status field contains a non-zero value.″ Then the length of the PDU is 16 octets. SMPP 5.0 just specifies that message_id is a mandatory parameter of the type C-Octet string of the submit_sm_resp message. According to the section 3.1.1 NULL Settings, ″A NULL string ″″ is encoded as 0x00″. The length of the PDU is at least 17 octets. For the best compatibility, any SMPP implementation should accept both variants of negative submit_sm_resp regardless of the version of SMPP standard used for the communication. Message ID in SMPP 3.3 SMSC Delivery Receipts The only way to pass delivery receipts in SMPP 3.3 is to put information in a text form to the short_message field; however, the format of the text is described in Appendix B of SMPP 3.4, although SMPP 3.4 may (and should) use receipted_message_id and message_state TLVs for the purpose. While SMPP 3.3 states that Message ID is a C-Octet String (Hex) of up to 8 characters (plus terminating '\0'), the SMPP 3.4 specification states that the id field in the Delivery Receipt Format is a C-Octet String (Decimal) of up to 10 characters. This splits SMPP implementations to 2 groups: Implementations using the decimal representation of an integer Message Id in the id field of the Delivery Receipt body and the hexadecimal representation of an integer Message Id in message_id and receipted_message_id fields Implementations using the same hexadecimal number (or even the same arbitrary string) both in message_id parameter and in the id field of the Delivery Receipt body The SMPP 3.4 specification does however state that the delivery receipt format is SMSC vendor specific, and therefore the format included in the specification is merely one possibility. As noted above, when using SMPP 3.4 receipted_message_id and message_state TLVs should be used to convey the outcome of a message. Extensibility, compatibility and interoperability Since introduction of TLV parameters in version 3.4, the SMPP may be regarded an extensible protocol. In order to achieve the highest possible degree of compatibility and interoperability any implementation should apply the Internet robustness principle: ″Be conservative in what you send, be liberal in