Differences

This shows you the differences between two versions of the page.

--- b2f:bcf_v0 [2025/02/14 08:58] – [Binary File Transfer Mode] f4hof
+++ b2f:bcf_v0 [2025/02/14 10:45] (current) – [Binary File Transfer Mode] f4hof
@@ Line 6: / Line 6: @@
   * 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.
-===== Transfer Modes =====
+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.
-The actual message content is transferred in a different format from the ASCII Basic Protocol.
+===== Commands =====
-The format used is derived from the YAPP protocol which is very reliable. Each message is made up of a header, blocks of data, an end of message marker and a checksum.
-This is directly equivalent to the transfer of one message in the ASCII Basic Protocol.
+The command list almost stays the same as the ASCII Basis Protocol.
-Unlike YAPP transfers, there is no individual packet acknowledgement during the transmission of messages, the protocol is thus simpler and more efficient.
+The main change is the [[b2f:ascii#pending_mail_proposal|pending mail proposal]] is replaced by the following proposals.
-==== ASCII Message Transfer Mode ====
+^ 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:
@@ Line 27: / Line 46: @@
 <code abnf>
-BCFv0_ASCII_HDR_SZ = %x04-%x58
+BCFv0_ASCII_ATTR_SZ   = %x04-%x58
 BCFv0_ASCII_HDR_TITLE = 1*80( WSP / HTAB / VCHAR )
-BCFv0_ASCII_OFFSET = 1*6DIGIT
+BCFv0_ASCII_OFFSET    = 1*6DIGIT
-BCFv0_ASCII_HEADER = %x01 BCFv0_ASCII_HDR_SZ BCFv0_ASCII_HDR_TITLE %x00 BCFv0_ASCII_OFFSET %x00
+BCFv0_ASCII_HEADER    = %x01 BCFv0_ASCII_ATTR_SZ BCFv0_ASCII_HDR_TITLE %x00 BCFv0_ASCII_OFFSET %x00
 </code>
-==== Binary File Transfer Mode ====
+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:
@@ Line 83: / Line 106: @@
 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 and the system issues a disconnect request after having sent the comment :
+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