Differences

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

--- b2f:bcf_v0 [2025/02/14 09:02] – [ASCII Message 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 35: / Line 54: @@
 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 Mode ====
+==== Binary File Transfer Header ====
+FIXME proposal format definition
 Message header format:
@@ Line 85: / 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