This version of the BBS specification has been cleaned up and updated from the version released in November of 1993. Additional information is included in several appendices.

Introduction *

The above exchange represents a simple example of connecting, establishing a common protocol, forwarding and reverse forwarding. This document examines in detail each of these phases of the process of data interchange between packet BBS systems.

In the text the BBS initiating the connect is referred to as the MASTER and the remote BBS to which it connects is referred to as the SLAVE.

Each command and exchange is presented in BNF (Backus-Naur Form) which is a context-free grammar widely used to describe the syntax of formal languages. All commands and fields are case insensitive.

Throughout this document we present a verbose translation of the grammar highlighting any points that may not be obvious but could have significant affect. There are also examples illustrating what can actually be expected in practice.

When connecting to a BBS the first line the BBS sends must be the SID (System Identifier). The SID is used to determine what features are supported by each BBS. The existence of the SID implies that the system supports reverse forwarding and OK/NO message rejection. There still exist old BBS programs that do not present a SID at connect. Refer to Section 4 for information on handling these old style BBS systems.

The SID as sent by both MASTER and SLAVE:

The AUTHOR_ID and FEATURE_SET must be present. If the optional AUTHOR_DATA is present it must be separated from the other two fields by a '-' character. AUTHOR_DATA may contain the '-' character. The AUTHOR_ID is typically a portion of the authors callsign or BBS name. The AUTHOR_DATA is typically the version number of the software. Each FEATURE consists of a letter, denoting the feature and an optional following number, denoting the feature level. The absence of a version number implies version zero. If BID's are supported, '$' must be the last symbol in the FEATURE_SET. The recommended minimal support is BID and hierarchical location identifiers. These are necessary for the proper operation of the network.

The original prompt received from the SLAVE BBS may contain additional information intended for users. As soon as the SID is received by the SLAVE BBS it should respond with an abbreviated PROMPT, with the ASCII_STR field being empty.

A message can be accepted of rejected by the SLAVE. There are many reasons that the SLAVE may choose to reject a message. The most common is a duplicate BID, indicating the SLAVE already has the message. Any use of a NO response other than to indicate a duplicate BID is discouraged since it will cause loss of messages. Here is an overview of the exchange.

The SLAVE indicates it is prepared to accept a command by issuing a PROMPT. The PROMPT is also used as an acknowledgment of correct reception of the previous message. The MASTER initiates the message exchange by issuing a SEND_CMD. This command contains all the information necessary for the SLAVE to decide whether to ACCEPT or REJECT the message. It contains message type, destination, originator and possibly a bid.

Message Types:

Type B is a bulletin to be distributed to all BBS system. Type P is a personal message destined to one recipient. Type T is an NTS traffic message destined outside the Amateur Radio Service.

HLOC is a hierarchical location of the system. It is defined by the document "INTERNATIONAL ROUTING DESIGNATORS", ARRL Networking Conference Proceedings.

The TO field commonly takes the following forms:

The first two are seen most often, but the other two forms are seen occasionally. The first two forms are also normally associated with the message type of PERSONAL and BULLETIN respectively. White space is required on either side of the '@' and between the '<' and the senders callsign. There cannot be white space between the '$' and the BID.

EXAMPLE

A "BID" (Bulletin Identifier) is associated with each Bulletin, and may be associated with any Personal message. If a BID is not given explicitly when the message is entered into the system, and the message type requires a BID, one is created automatically from the message number and callsign of the system into which the message was initially entered.

NOTE:

It is suggested that a generated BID have the form nnn_BBS, where nnn is the message number at the originating BBS system, and BBS is the callsign of the originating BBS system.

BBS programs are free to create whatever form they wish as long as the length does not exceed 12 characters.

Messages to a distribution, whether they are bulletins or personal messages, must have a BID. Personal messages to a specific user may carry a BID if the originator supplied one, but will not be given a default BID. NTS message never carry a BID.

The SLAVE BBS determines from the SEND_CMD whether or not to accept the message. The reason for rejection is usually that the message already exists on the SLAVE system (i.e. a duplicate BID). It may also indicate a system problem.

Sent by SLAVE in response to SEND_CMD (or by MASTER if in reverse forward mode).

NOTE:

EXAMPLE

Master: SB WANT @ ALLCAN < N6ZFJ $4567_N0ARY

Slave: NO duplicate bid

Slave: >

Master: SB WANT @ ALLCAN < N6ZFJ $4567_N0ARY

Slave: OK #32190

Master: message body

Master: Control-Z

Slave: Message being held for sysop review

Slave: >

"OK" and "NO" must be followed by white space or EOL. If this is not done, some BBS programs will fail to recognize them.

EXAMPLE

Master: SB WANT @ ALLCAN < N6ZFJ $4567_N0ARY

Slave: NO, already have it

Slave: >

This would fail with some existing BBS programs due to the comma following the "NO" string.

If the SLAVE BBS responds with a REJECT condition the message should not be sent and the MASTER should ignore any response from the SLAVE until PROMPT is encountered. The MASTER can then submit a new SEND_CMD, initiate reverse forwarding or disconnect.

Once the SLAVE has issued the ACCEPT response, the MASTER BBS should immediately send the message subject, routing headers, message body and EOMA. The SLAVE will acknowledge with PROMPT once it receives an EOMA.

Note:

EXAMPLE

Example message

The message body goes here. The blank line above separates the body from the routing headers. The BODY should be terminated with EOMA, but EOMB is allowed to support some existing codes for example WinLink and AA4RE.

Notes:

Both forms of the header described above are seen, and should be parsed. In either case there may be comments found at the end of the header line, or between the BBS and the MSG_NUM entries in HEADER2.

HEADER2 is derived from the header form used in early BBS programs. It allows additional information to be passed in the header and parsed if desired. Some examples of these additional optional fields are:

Notes:

The time stamp in the routing header must be in GMT. Some existing BBS programs provide the time stamp in other than GMT, and may include a time zone indicator after the time stamp. This should be considered in the design of header parsers. The design of future BBS programs should conform to this specification.

Each system that handles the message places it's routing header at the top of the message headers before passing the message to the next BBS.

The headers must begin in column 1. A blank line separates the routing headers from the body of the message.

The first (oldest) routing header shows the BBS where the message originated. This header is the only source for this information. The information about the originating BBS is used to create a return address for reply messages.

Here are two examples of the same header, in the two different formats:

These examples show the different syntax for the message number and originating BBS address. All fields not shown in the examples are optional at the discretion of the BBS author or the individual sysop.

Once all messages have either been successfully forwarded from the MASTER to the SLAVE, or been rejected by the SLAVE, the MASTER may accept messages from the SLAVE. The MASTER and SLAVE exchange roles. This is called "reverse forwarding".

The reverse forwarding phase is optional and is under the control of the MASTER. It can be terminated by any of the following:

If the SLAVE does not return a SID then it is assumed that it will not support BIDs, hierarchical location designators or OK/NO message rejection.

The SLAVE indicates it is prepared to accept a command by issuing a PROMPT. This PROMPT is also an acknowledgment that the previous message has been received.

The MASTER initiates the message exchange by issuing a SEND_CMD with no HLOC or BID. The SLAVE has no way to reject the message so the MASTER proceeds to send the message subject and body without expecting acknowledgment from the SLAVE.

Since the SLAVE assumes a user is entering the message, it will display prompts to lead the user through the message sending process, asking for a subject, prompting for the message body, etc. The MASTER should consider this text to be part of the PROMPT and ignore it.

As in Section 2, the MASTER waits until PROMPT is received. This is the acknowledgment that the message has been received and the next message can be sent.

When the MASTER has no additional messages to send it disconnects from the SLAVE. Reverse forwarding is not supported in this situation.

When two BBS systems communicate over a half duplex link, the following two conditions apply: 1) on link initiation, the SLAVE shall send the first data over the link. 2) The station sending data shall relinquish the link when it has finished sending. In the case of TOR, for example, this means the SLAVE is ISS when the link is established and ISS always issues the OVER.

When either the MASTER or the SLAVE detects an error, it shall disconnect at once, without issuing a PROMPT or any other data.

Supports BIDs. This feature must be supported.

F6FBB Acknowledge for personal messages.

F6FBB Binary messages supported.

Supports automatic distribution of current date / time. (W0RLI, K0ZXF) This feature is obsolete:

F6FBB Batch forwarding protocol supported.

Supports Hierarchical Location designators. This feature must be supported.

Some transport mechanisms do not identify the calling station in the protocol, as does AX.25. To handle this situation, a "null command" is defined as a line beginning with ';'. This allows the sending station to send callsigns to satisfy the regulations for station identification.

EXAMPLE

The receiving station must ignore such lines.

G1NNA – Compression supported.

For AA4RE systems:

Basic level ("M0")

Every message has a MID. The MID looks like a "generated" BID (example 12345_AA4RE). The "M" letter in the SID indicates that a MID is to be transmitted with messages that have no BID. Processing: If a send command is received by a BBS with a MID, the program should determine if it is a duplicate. If it is, the program should respond with the usual "NO" as if it was matching a BID.

Note:

This protocol will on occasion cause the loss of messages. Its use is discouraged.

AA4RE - Extended reject responses.

OK

NO

REJECT

LATER

The LATER is useful when you are already receiving a bulletin on one connect and someone else tries to send you the same bulletin.

Rejected messages should be called to the attention of the SYSOP to see why the reject occurs.

The difference between NO and REJECT is whether or not SYSOP attention is needed.

Abbreviations are allowed: 1 Letter only ... O N L R

There must be a blank after the word or letter. This one is fine:

This one is not correct:

The comma is not allowed.

AA4RE - Extended "S" commands supported.

WinLink.

WinLink.

Supports ihave/iwant compressed batch forwarding. Defines the syntax and use of commands SS, SX, SY. Uses lzh compression

For iwant:

Note that the SS command must terminate with CR, without LF.

The optional checksum is computed by summing all the bytes in the file as unsigned integers. Example code:

{

int byte;

unsigned int sum;

sum = 0;

for (all bytes in file) sum += byte;

}

RFC-822 header fields used are:

bn are BIDs (or MIDs if the message has no BID). m: is master, s: is slave.

In the case of any error, the station noticing the error must disconnect immediately.

Import/Export files may contain any number of messages. Each message is terminated by EOMB

The standard RFC-822 keywords, which must be supported, are:

Extension keywords, which must be supported, are:

Produced by W0RLI systems

Produced by JNOS systems