Transmission protocol mechanisms
Waiting time extension
If the smart card needs more time to generate a response than the maximum time allowed by the block waiting time (BWT), it can request a waiting time extension from the terminal. It does so by sending a special S block requesting an extension, and it receives a corresponding S block from the terminal in acknowledgement. The terminal is not allowed to refuse this request. A byte in the information field informs the terminal of the length of the extension. This byte, multiplied by the block waiting time, gives a new block waiting time. This extension is only valid for the most recently sent I block.

Block chaining
One of the essential performance features of the T = 1 protocol is the block chaining function. This allows either party to send data blocks that are larger than the size of its transmit or receive buffer. This is particularly useful in light of the limited memory capacities of smart cards. Chaining is permitted only for information blocks, since only such blocks can contain large amounts of data. In the chaining process, the application data are partitioned into individual blocks that are sent to the recipient one after the other. The application layer data must be partitioned such that none of the resulting segments is larger than the maximum block size of the recipient. The first segment is then placed in an information field in accordance with the T = 1 protocol, supplied with prologue and epilogue fields and sent to the recipient. The M bit (‘more data’ bit) is set in the block’s PCB field to indicate to the recipient that the block chaining function is being used and that chained data are located in the following blocks. As soon as the recipient has successfully received this information block with the first segment of the user data, it indicates that it is ready to receive the next chained I block by returning an R block whose sequence number N(R) is the same as the send sequence count N(S) of the next I block. The next block is then sent to the recipient. This reciprocal exchange of I and R blocks continues until the sender issues an I block with an M bit in the PCB field indicating that it is the last block in the chain (M bit = 0). After this block has been received, the recipient has all the application layer data and can process the full data block. There is a restriction with regard to the block chaining mechanism. Within a single command–response cycle, chaining may proceed in one direction only. For example, if the terminal is sending chained blocks, the card may not send chained blocks in response. There is another restriction that has nothing to do with the mechanism itself, but rather with the very limited amount of memory in smart cards. Implementing the block chaining mechanism involves extra overhead, and its usefulness is very limited, since commands and responses are not especially long and thus do not normally require chaining. If the card’s receive buffer in RAM is not large enough to store all of the data passed using block chaining, it must be moved to the EEPROM. This leads to a sharp reduction in the transmission rate, since the EEPROM (in contrast to the RAM) cannot be written at the full speed of the processor. Consequently, many T = 1 implementations have no block chaining function, as the cost/benefit ratio often does not justify it. This is a typical example of the fact that standards are often interpreted very liberally in actual practice. In this case, the interpretation amounts to considering block chaining to be a supplementary option in T = 1 that is not absolutely necessary. This can lead to significant compatibility problems in practice.

Error handling
The T = 1 protocol has elaborate error detection and handling mechanisms. If an invalid block is received, the protocol attempts to restore error-free communications by means of precisely defined procedures. Seen from the terminal’s perspective, there are three synchronization stages. In the first stage, the sender of a faulty block receives an R block indicating an EDC/parity bit error or a general error. The recipient of this R block (the original sender) must then retransmit the last block that it sent. If it proves impossible to restore an error-free connection using this mechanism, the next stage is invoked. This means that the smart card receives a resynchronization request from the terminal in an S block. The terminal expects a resync response in reply. The terminal and card then both reset their send and receive counters to zero, which corresponds to the protocol state immediately following the ATR. Starting from this situation, the terminal attempts to restore communications. The first two stages affect only the protocol layer. They have no effect on the actual application. However, the third synchronization stage does affect all layers in the smart card. If the terminal cannot establish an error-free connection using the first two synchronization stages, it triggers a smart card reset via the reset lead. This unfortunately means that all the data and states of the current session are lost. Following the reset, communications must be completely re-established from the bottom up. If even this procedure fails to produce a working connection after three attempts, the terminal deactivates the card. The user then usually receives an error message to the effect that the card is defective.