led to the introduction of TeLink by Tom Jennings, author of the original FidoNet mailers. TeLink avoided MODEM7's problems by standardizing a new "zero packet" containing information about the original file. This included the file's name, size, and timestamp, which were placed in a regular 128 byte XMODEM block. Whereas a normal XMODEM transfer would start with the sender sending "block 1" with a <SOH> header, the TeLink header packet was labeled "block 0" and began with a <SYN>. The packet contained the file creation date and time, filename up to 16 characters, the file size as a 4-byte value, and the name of the program sending the file. A normal XMODEM implementation would simply discard the packet, the assumption being that the packet number had been corrupted. But this led to a potential time delay if the packet were discarded, as the sender could not tell whether the receiver had responded with a <NAK> because it did not understand the zero packet or because there was a transmission error. As TeLink was normally used only by FidoNet software, which demanded it as part of the FidoNet standards, this did not present a real-world problem as both ends would always support this standard. The basic "block 0" system became a standard in the FidoNet community, and was re-used by a number of future protocols like SEAlink and YMODEM. XMODEM-CRC The checksum used in the original protocol was extremely simple, and errors within the packet could go unnoticed. This led to the introduction of XMODEM-CRC by John Byrns, which used a 16-bit CRC in place of the 8-bit checksum. CRC's encode not only the data in the packet, but its location as well, allowing it to notice the bit-replacement errors that a checksum would miss. Statistically, this made the chance of detecting an error less than 16 bits long 99.9969%, and even higher for longer error bit strings. XMODEM-CRC was designed to be backwardly compatible with XMODEM. To do this, the receiver sent a C (capital C) character instead of a <NAK> to start the transfer. If the sender responded by sending a packet, it was assumed the sender "knew" XMODEM-CRC, and the receiver continued sending C's. If no packet was forthcoming, the receiver assumed the sender did not know the protocol, and sent an <NAK> to start a "traditional" XMODEM transfer. Unfortunately, this attempt at backward compatibility had a downside.