This clause summarizes general aspects on AT commands and issues related to them. TE software implementors must take into account that future versions of this specification may include additional parameters beyond what is expected in any (final or intermediate) response to an AT set command, read command or test command, and beyond what is expected in any unsolicited result code. Implementations must therefore analyse all parameters provided from the TA and discard (ignore) any parameters received following the parameters expected by the TE software. For further information refer ITU-T Recommendation V.250 [14]. In the tables for the commands syntaxes, the possible response(s) are outlined as follows:

• the responses from ITU-T Recommendation V.250 [14] (like OK and ERROR) are normally not shown; and
• the final response +CME ERROR is shown when a final result code in clause 9.2 can be provided.

In certain implementations, AT commands are used as an internal interface within the physical handset, e.g. between the application and the radio interface layer 3 stack implemented on different processors. Certain AT commands transfer information in the clear that can be regarded as sensitive with regards to security or privacy. Care must be exercised in AT commands that:

• transfer passwords (e.g. +CLCK, +CPWD or +CPBS);
• transfer identities (e.g. IMSI) or details of a call (e.g. +COLP);
• transfer the current location of the phone (e.g. +CMOLR);
• reveal the IMEI (e.g. +CGSN);
• allow the TE to take unintentionally control over the SIM-MT interface (e.g. +CSIM);
• enable/disable access to commands protected by security mechanism (e.g. +CSCC); or
• exchange security related parameters and keys with the UICC (e.g. +CEAP and +CERP).

The above mentioned AT commands and parameters are examples to illustrate the concerns and is not meant to be a comprehensive list.

See Figure 2 for general structure of a command line. Standardized basic commands are found only in ITU-T Recommendation V.250 [14]. The commands in this specification use syntax rules of extended commands. Every extended command has a test command (trailing =?) to test the existence of the command and to give information about the type of its subparameters. Parameter type commands also have a read command (trailing?) to check the current values of subparameters. Action type commands do not store the values of any of their possible subparameters, and therefore do not have a read command.

If verbose responses are enabled with command V1 and all commands in a command line has been performed successfully, result code <CR><LF>OK<CR><LF> is sent from the TA to the TE. If numeric responses are enabled with command V0, result code 0<CR> is sent instead. If verbose responses are enabled with command V1 and subparameter values of a command are not accepted by the TA (or command itself is invalid, or command cannot be performed for some reason), result code <CR><LF>ERROR<CR><LF> is sent to the TE and no subsequent commands in the command line are processed. If numeric responses are enabled with command V0, result code 4<CR> is sent instead. ERROR (or 4) response may be replaced by +CME ERROR: <err> (refer to clause 9) when command was not processed due to an error related to MT operation.

The TA response for the example command line of Figure 2 could be as shown in Figure 3. Here, verbose response format is enabled with command V1. If numeric format V0 would have been used, <CR><LF> headers of information responses would have been left out and final result code changed to 0<CR>.

So called intermediate result codes inform about progress of TA operation (e.g. connection establishment CONNECT), and so called unsolicited result codes indicate occurrence of an event not directly associated with issuance of a command from TE (e.g. ring indication RING).

Table 1 summarizes ITU-T Recommendation V.250 [14] commands relating to command line and response formatting, and TA-TE interface operation. All are applicable to terminals specified by the present document.