F4HOF

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Binary Compressed Forward Version 0 ======

The compressed version of the protocol is an extension to the [[b2f:ascii|ASCII Basic Protocol]]. 

  * Compressed forward availability is reported by the letter ''B'' in 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 ''B'' but no ''F'' will be treated as if neither extensions have been advertised. 

The Binary Compressed Forward protocol MUST operate over a [[https://en.wikipedia.org/wiki/8-bit_clean|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 [[b2f:ascii#pending_mail_proposal|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 [[b2f:ascii#pending_mail_proposal|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 ====

FIXME 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:

<code abnf>
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 
</code>

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 ====

FIXME 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:

<code abnf>
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 
</code>

==== 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:

<code abnf>
BCFv0_CHUNK_SZ   = OCTET
BCFv0_CHUNK      = 1*256OCTET
BCFv0_DATA_BLOCK = %x02 BCFv0_CHUNK_SZ BCFv0_CHUNK
</code>

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:
<code abnf>
BCFv0_CHECKSUM = OCTET
BCFv0_EOF      = %x04 BCFv0_CHECKSUM
</code>

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 

<code>*** Erreur checksum</code>

===== Transaction flow =====

FIXME To be completed