Table of Contents
Binary Compressed Forward Version 0
The compressed version of the protocol is an extension to the ASCII Basic Protocol.
- Compressed forward availability is reported by the letter
Bin the SID extensions field. - As it is an extension of the basic protocol, the SID extension field MUST also advertise the ASCII Basic Protocol with the letter F. A SID with the letter
Bbut noFwill be treated as if neither extensions have been advertised.
The Binary Compressed Forward protocol MUST operate over a 8-bit clean communication bearer, which provides reliable and ordered delivery.
Commands
The command list almost stays the same as the ASCII Basis Protocol.
The main change is the pending mail proposal is replaced by the following proposals.
| Proposal | Usage |
|---|---|
FA | Pending ASCII Message Proposal |
FB | Pending Binary File Proposal |
The proposal format stays the same as the one described in the pending mail proposal specification:
Pending ASCII Message Proposal
Pending Binary File Proposal
Transfer Mode
The message/file payload is transferred using a different format from the ASCII Basic Protocol.
Each message is made up of a header, blocks of data, an end-of-message marker, and a checksum.
Unlike YAPP transfers, there is no individual packet acknowledgement during the transmission of messages. The protocol is thus simpler and more efficient.
As with the underlying protocol, the channel direction is immediately reversed after the completion of a transfer batch.
ASCII Message Transfer Header
proposal format definition
Message header format:
| 0x01 | Attributes size | Message title | 0x00 | Offset | 0x00 |
|---|---|---|---|---|---|
| 1 byte | 1 to 80 bytes | 1 to 6 ASCII digits | |||
| Attributes size | |||||
ABNF Grammar:
BCFv0_ASCII_ATTR_SZ = %x04-%x58 BCFv0_ASCII_HDR_TITLE = 1*80( WSP / HTAB / VCHAR ) BCFv0_ASCII_OFFSET = 1*6DIGIT BCFv0_ASCII_HEADER = %x01 BCFv0_ASCII_ATTR_SZ BCFv0_ASCII_HDR_TITLE %x00 BCFv0_ASCII_OFFSET %x00
Security considerations:
- If you're using a memory-unsafe language, you SHOULD pay extra care with the attribute size field to avoid buffer overflow attacks.
Binary File Transfer Header
proposal format definition
Message header format:
| 0x01 | Attributes size | Filename | 0x00 | Offset | 0x00 |
|---|---|---|---|---|---|
| 1 byte | 1 to 80 bytes | 1 to 6 ASCII digits | |||
| Attributes size | |||||
ABNF Grammar:
BCFv0_BIN_HDR_SZ = %x04-%x58 BCFv0_BIN_HDR_TITLE = 1*80( WSP / HTAB / VCHAR ) BCFv0_BIN_OFFSET = 1*6DIGIT BCFv0_BIN_HEADER = %x01 BCFv0_BIN_HDR_SZ BCFv0_BIN_HDR_TITLE %x00 BCFv0_BIN_OFFSET %x00
Data Transfer Block
Block format:
| 0x02 | Data chunk size | Data chunk |
|---|---|---|
| 1 byte | 1 to 256 bytes | |
| equals 0 if chunk is 256 bytes long |
ABNF Grammar:
BCFv0_CHUNK_SZ = OCTET BCFv0_CHUNK = 1*256OCTET BCFv0_DATA_BLOCK = %x02 BCFv0_CHUNK_SZ BCFv0_CHUNK
The last data block is followed by the end of file specifier and the checksum.
End of file Block
| 0x04 | Checksum |
|---|---|
| 1 byte |
ABNF Grammar:
BCFv0_CHECKSUM = OCTET BCFv0_EOF = %x04 BCFv0_CHECKSUM
The checksum is the sum of all the transmitted file' data bytes, modulo 256 (8 bits) and then two's complemented.
To perform validation, compute the sum of data and checksum bytes, modulo 256. The checksum is considered valid if the result of the last calculation equals 0.
In case of a checksum error:
- The message or the file is ignored.
- The following comment is sent back.
- The system issues a disconnect request
*** Erreur checksum
Transaction flow
To be completed