The ASCII Basic Protocol was developed for greater efficiency, when compared to the historical MBL/RLI protocol. Its design reduced the number of necessary transactions, which proves its convenience on high latency links, or in situations where radio/modem turnaround is particularly expensive (half-duplex links).

Commands and payload exchange is reduced to a minimum by pipelining multiple requests at a time. In typical transactions, up to five requests/messages are sent at once.

F4HOF's note: The maximum admissible size of each block isn't specified, will need to dig on some actual implementations.

• The protocol availability is indicated by the F letter in the SID.
• All protocol command lines start in first column with the F character (0x46).
• All protocol command lines are terminated by a Carriage Return (CR) character (0x0d).

ABNF Grammar:

ASCII_MESG_TYPE = "P" / "B"
ASCII_PEND_PROPOSAL = "F" "B" WSP ASCII_MESG_TYPE WSP  0x0D
ASCII_PEND_PROMPT = "F" ">" 0x0D
ASCII_XFER_PEND = 

The no message pending proposal (FF) is used to notify the remote party that no further message are enqueued on our side.

Format:

FF

ABNF Grammar:

ASCII_XFER_NOPEND = "F" "F" 0x0D

The selective message retrieval command (FS) is issued by the party which has been offered several pending messages.

It is used to tell the remote party how to process the proposed messages. A FS command MUST have as many +,-, or = signs as lines in the related proposal.

Format:

FS <tokens>

ABNF Grammar:

ASCII_XFER_RETR = "F" "S" %x20 1*RETR_TOKEN %x0D

This command is exclusively sent by the called party, and signals the calling station the bearer can be torn down.

Format:

FF

ABNF Syntax:

ASCII_XFER_DISC = "F" "F" %x0D

ABNF Grammar:

clarify the SUB end of message: is it %x1A %x0D or %x0D

ASCII_MESG_PROPOSAL = 1*1( ASCII_XFER_PEND / ASCII_XFER_NOPEND / ASCII_XFER_RETR / ASCII_XFER_DISC) %x0D
 
ASCII_MESG_HEADER = 1*(WSP / VCHAR) %x0D
ASCII_MESG_BODY = 1*( 1*(WSP / HTAB / VCHAR) %x0D )
 
ASCII XFER_FRAME = 1*5( ASCII_MESG_HEADER ASCII_MESG_BODY %x1A %x0D) ASCII_MESG_PROPOSAL

A transaction happens as following:

1. The calling party establishes a reliable delivery bearer, that provides (either a TCP session, an AX.25 virtual circuit, or a raw ARQ/SACK modem connection).
2. The called party sends its SID banner, optional text messages, then a line that ends with the character > (0x3E).
3. The calling party answers with its SID banner, and either a proposal for messages pending expedition followed by the F>, or the empty message queue notification FF command (skip to the penultimate step in this case).
4. The called party issues a FS command to select messages it is interested in receiving.
5. The calling party transfers the selected messages, then drop and defer the other messages according to the called party's request, and finally follows with either an empty message queue notification, or a list of the next pending message proposals. In the latter situation, we jump back to the last step.
6. The called party sends either a list of pending message proposals, or we jump to the penultimate step.
7. The calling party issues a FS command to select messages it is interested in receiving.
8. The called party transfers the selected messages, then drop and defer the other messages according to the calling party's request, and finally follows with either an empty message queue notification, or a list of the next pending message proposals. In the latter situation, we jump back to the last step.
9. The called party requests for the bearer teardown using the FQ command.
10. The calling party initiates the bearer teardown.

msc {
  wordwraparcs=on; 

  a [label="Alice"], c [label="Carol"];

  --- [label=" Alice opens reliable delivery bearer "];
  c => a [label="[Carol-1.33.7-FHM$]"];
  c => a [label="Welcome Alice"];
  c => a [label=">"];
  a => c [label="[Alice-1.73-FHM$]"];
  a => c [label="FF"];
  c => a [label="FQ"];
  --- [label=" Alice tears down the bearer "];
}