Air Force MARS
TRANSCON Digital Network
Home | Introduction
Subject: PACKET/DIGITAL MESSAGE FORMAT
(Updated 17 DEC 03 - original 04 JUL 01)
SUBJECT: GENERAL MARS DIGITAL/PACKET MESSAGE FORMAT
1. All messages or traffic entered into the MARS
digital/packet network will be accomplished in accordance with the current MOD.
Digital/Packet messages will follow the standard mars message format for MARS
traffic in general. This includes messages entered into the packet/digital
system to include autonomous forwarding by PACTOR, GTOR or other advanced
2. Messages sent entered into digital/packet will be sent one at a time. No books or blocks (i.e. Groups of messages of messages will be sent. At the end of each message the command "/EX" or a "control Z" function will be sent.
3. All messages will be made in UPPERCASE letters.
4. Do not enter more than ten (10) words per line of text. In situations where 10 words will not fit on a single line, enter a carriage return (CR) the line should be extended to another line. For ease of counting groups multiples of 5 or 10 words per line should be used excepting the last line of a paragraph or message.
5. Optionally the entire message may be configured with only five groups per line and the last line containing the one to four group(s), if any groups remain.
6. The format of formal digital/packet traffic shall conform to examples to be sent in part 3 of this message to follow.
End of part 1.
Subject: RESPONSIBILITY FOR TRAFFIC.
1. Traffic arriving from overseas in block (i.e. Messages grouped by region) format shall be broken down to single messages at the gateway station, before being introduced into the CONUS digital network. If an affiliate station chooses to receipt, through the gateway station, for blocked traffic originating from overseas, then the affiliate assumes responsibility for breaking down these blocks of messages into single message transmissions.
2. The responsibility of traffic handling on the packet/digital network rests with each of the system operators (SYSOP) of the BBS or mailboxes into which the traffic is placed. It is expected that every member and SYSOP will be diligent to ensure traffic going into the digital system, BBS or mailboxes needs no human intervention to accomplish the relay. If messages are going to another digital/packet station they will be sent on digital/packet nets or refiled into another mode, either directly on TRANSCON frequencies or via the MARS region network to an appropriate TRANSCON network. Messages will not be left sitting in BBS or mailboxes, unless the particular BBS or mailbox is that
message's final destination.
3. The mars station (whether a SYSOP or mailbox
user) will utilize the K or KT command to erase traffic taken for delivery or
refile to another mode. Under no circumstances will traffic be serviced back as
undeliverable, unless its destination is local to the station removing the
traffic, and a valid reason for its non-delivery exists (i.e. Addressee moved
or is deceased, invalid address, no phone number on message, and number not
available through the local phone company (if message originated in
4. Messages and traffic should sit unmoved on a BBS station for no more than 24 hours.
End of part 2
Subject: PACKET/DIGITAL MESSAGE EXAMPLES.
1. There are several types of messages used in AF MARS, broadcasts/bulletins, traffic, private messages, and service messages.
("SB") are "flood messages", meaning they are sent as
unaccountable "official" messages. These messages (get flooded)
go everywhere in all modes. They are public messages, and everyone sees them.
b. Traffic ("ST") is MARS format messages that can be handled by any MARS organization/trained member on any mode to get the traffic to its destination. This type traffic is moral, official and EEI / ECOM messages. These messages are seen, downloadable and "KT" by everyone. (Note: not all BBS systems support KT depending on SYSOP settings)
c. A service message is usually sent as traffic but can be sent as a private message if the addressee has a known routable address on the digital system.
d. Private messages are unaccountable personal messages between sysops and/or members that have known addresses routable directly on the MARS digital systems. Do not use "S" or "SP" or "CC" to send traffic. Messages originated using "S" or "SP" or "CC" cannot be seen on the various digital systems by the users, they can be seen only by the addressee or by the SYSOP if he is looking for a specific private message or messages usually. There is some variation on how the SYSOP sees private messages from system to system.
e. If a private message is sent to an incorrect address or is undeliverable for any reason, it often sits for extended periods time, occasionally indefinitely. Due to the fact the general members/users of a digital system (BBS) can not see messages sent as private (sent using "S", "SP" or "CC"), private messages have no guarantee of being delivered. It is important to note, those checking the BBS or digital system for traffic messages do NOT see private messages. To be seen by traffic handlers, a message MUST be sent as traffic ("ST").
2. When sending any type of message on the MARS digital systems, there are two addresses to contend with. The digital address and the MARS message address.
a. The first address is what
is entered at the BBS prompt to originate routing of the message to a system on
the network closest to its point of delivery.
b. This is the address entered at the BBS prompt following the "ST", "SB", "SP" or "S" command. If the addressee is a local user of the same system the message is being originated on, then the addressee need only be a member or official's call or a message category in the case of a bulletin or B'cast. AFA1II and AFA1YP are users of the same local BBS, AFA1II would enter "SP AFA1YP" to send a message to AFA1YP. This becomes a local message and it is not forwarded on the network.
c. If the message is be routed beyond the local system, then the address will have two or more parts, the first part separated from the following parts of the address by the "@" (at) symbol. If AFA1II at AFA1HN.MA (his local BBS) wishes to send AFF1C a private message and AFA1II knows AFF1C receives MARS digital traffic at AFA1UN.PA BBS, AFA1II would enter
at the BBS prompt. This originates routing for this
message. This address contains the "@"(AT) symbol and will be
forwarded over the network to the destination specified following the
"@"(AT) symbol. In this case, AFA1UN.PA is the destination BBS.
3. The second address is in the MARS traffic format message header, this address is the individual or office that is to receive the message or delivery address.
a. In the case of EEI messages, most often the second address or MARS format message address is "DOMS".
b. In the case of Bulletins and broadcasts this is often "ALL MARS MEMBERS". There may or may not be secondary address information in this part of the message depending on the type of message. What addressing does appear in the MARS traffic format message header is independent from the digital routing used in the 1st address above. The address that appears in the MARS traffic format message header is not used by the digital system and is usually a delivery address outside the MARS digital system.
4. In the AFA1II message to AFF1C, the procedure would be:
<AFA1HN BBS:> SP
<Subject:> NCS TRAINING
DE AFA1II@AFA1HN.MA NR 01
R 310100Z JUN 01
FM LEE RAND AFA1II MA
TO RICHARD MOWERY AFF1C
LANCASTER PA TEL 555-5555
WHEN IS THE NEXT NCS TRAINING SESSION?
SGD LEE AFA1II
As this is a private ("SP") message, it will only be delivered by AFF1C logging into the AFA1UN BBS and reading this message. If this message gets to a BBS on the route to AFA1UN BBS that can not make the next link and forward this message, the message stalls and as this is a private message, no other traffic handlers will see it and it is stalled.
5. Why using the "ST" command to originate traffic is required. Had this message been originated as traffic, ("ST"), it is now listed as traffic, another member in the area might log onto the BBS where the message is stalled, see the message, download the message, "KT", take the message to the VHF repeater or another voice net, and give it to another traffic handler who in turn might put it on the AFA1UN.PA BBS or call the telephone number and AFF1C receives the
6. Why "BOOK" traffic and "CC" will not work in the MARS Digital traffic system. Not all message systems support the 'CC' function. A 'CC' generated message is sent as a private message, it is not traffic. In the case of the use of 'CC' to generate a message, 'CC' does not generate a traceable, accountable piece of traffic according to MARS message format specifications. There is no obligation to anyone to account for a 'CC' created message, it has a duplicate serial number (message number) to the original MESSAGE. The official MARS message in the 'CC' generated digital message body has the same delivery address as the original message. There is no control of whether this message gets delivered to the addressee of the digital "CC" field or as a duplicate to the addressee of the official MARS message.
7. The same is true for using the term "INFO" and/or "ZEN". These are not directives to generate or deliver traffic. They only serve to inform the final recipient that copies of the message were sent to those listed as "INFO" or "ZEN" recipients. It is up to the originator to send a copy of the message to each of these people.
8. The format of formal packet/digital traffic shall conform to the following example. BBS prompts indicated for clarity. The use of ZIP Code@ZIPcode in the ST line is required for NTS type traffic. This could also be sent as ST <call_sign>@<bbs_call.state.rgnX> if going to a specific member with a known digital system address.
At the packet BBS prompt, you enter the following:
<BBS prompt:> ST
<subject:> garden grove,ca/714-638(CR)
DE AFA1NC NR 100(CR)
R 182321Z NOV 89(CR)
FM ROD FOWLER(CR)
341 LINCOLN AVE(CR)
BEVERLY, NJ 08010(CR)
TO GARDNER HARRIS(CR)
11791 LOARA STREET(CR)
GARDEN GROVE CA 92640-2321(CR)
TEN GROUPS PER LINE EXCEPT LAST LINE WHICH WILL CONTAIN(CR)
Note: (CR) in the example indicates carriage return function signifying to the BBS "end of line".
9. Note: data within the circumflexes < > would be supplied by the BBS when typing a message directly into a mailbox. Text enclosed in circumflexes is convenience prompts issued by the BBS or mailboxes themselves. They are not part of the message.
End of part 3.
Subject: OFFICIAL BULLETINS AND BROADCASTS ON PACKET.
1. Sending official bulletins and broadcasts at the national level may only be sent by or with the approval of Chief of MARS, or at region level, the RMD. Only AGA3C and those Appointed by him with a call of AFNxxx are authorized to send bulletins, broadcasts and official messages to "ALL@AFMARS".
If you have a need to send a message addressed to
"ALL@AFMARS" or "ALL@CONUS" and are not a national appointed
official with an AFNxxx call, your message must be forwarded to the Chief of
MARS or his designee for approval and release.
2. Bulletins, broadcasts and official messages at the region level may only be sent by or with the approval of AFFxC region mars director and those appointed by him with a call of AFFxx are authorized to send bulletins, broadcasts and official messages to "ALRGNx@ALRGNx". All other messages to be sent to ALRGNx@ALRGNx must be sent to the region RMD AFFxC or his designee for approval and release.
3. Alternate format for official bulletin headers. Official bulletins etc. will differ by the way they are addressed and have a unique bid. Where as MARS traffic is normally addressed in the BBS or mailbox command line as:
<BBS prompt:> ST zipcode@zipcode(CR)
Sending an official bulletin or traffic differs as
follows, the "ST" command is replaced with "SB", and the
message header also changes. See sample below in Item 5.
4. Any bulletins or broadcasts that are distributed to more than one BBS station to be entered into the packet/digital system must have a unique official BID$ or "bulletin identification number". This BID$ number prevents bulletins from being duplicated by different BBS systems during mail forwarding. This number can be any unique identification as long as it starts with "$" which is followed by the unique BID id.
For all Appointed officials or offices, there is a
prescribed BID$ Number format that identifies the office. If you study the
headers on packet messages from region and national officials you will see the
variations used by the different officials. If you are sending a bulletin
originated at a single BBS station, you do not need an official bid, the BBS
will assign its own bid automatically.
5. The following is a header from an actual ECOM broadcast:
<BBS prompt:> SB ALL @
AFMARS < AFN1EC $ECST_0105(CR)
<subject:> USAF MARS ECOM BROADCAST - NR 05(CR)
DE AFN1EC NR 005(CR)
R 210030Z JAN 01(CR)
FM AFN1EC SHAW AFB SC(CR)
TO ALL USAF MARS STATIONS(CR)
INFO AGA3C SCOTT AFB IL(CR)
ZEN CHIEF ARMY MARS(CR)
ZEN CHIEF NAVMARCOR MARS(CR)
NOTE: TEXT OF MESSAGE FOLLOWS STANDARD MARS FORMAT.(CR)
6. In the first line entered into the BBS in the above example, notice the last entry in the line, $ECST_0105, this is the unique bid for this bulletin.
As another example, Chief of mars broadcasts use
$MBC_YYNN(N) as a bid format. The $MBC identifies the Chief of MARS office, the
number following the underscore is the year and message number, $MBC_0105
= year 01, message number 05. You
will also notice the "FM" and "TO" entries in the header
are simplified as compared to the packet traffic sample in part 3 above.
End of part 4.
Subject: ROUTINE, SERVICE, AND GENERAL MEMBER MESSAGES
1. For messages between members, and for service messages, GRNC (group no count) is acceptable for digital/packet messages. If you know which BBS that member receives packet mail at, the header uses the format:
<bbs prompt:> sp email@example.com(CR)
<subject:> problem with lan1 node(CR)
DE AFF1K@AFA1HN.MA NR 007(CR)
R 220100Z JAN 01(CR)
FM MITCH HILL AFF1K/AFA1HN MA(CR)
TO DICK MOWERY AFF1C/AFA1UN PA(CR)
DICK, I THINK YOU NEED TO CHECK THE NODE, IT(CR)
IS NOT RESPONDING.(CR)
SGD MITCH AFF1K / AFA1HN(CR)
2. If you know the BBS where this person receives mail, use "SP" or "S" to originate the message command on the BBS. This message will only be seen or read by the recipient or a SYSOP. This will be a private message.
If you are not sure or don't know, use the ST
<zip_code>@<zip_code> address format, and include his telephone number
in the message..
3. If you put the "@bbs.st.rgnX" in the "SP" line the packet network will auto-route the message without delay.
4. If the person is not on packet the message
should be sent as traffic ("ST"), if sent as private ("S"
or "SP") it may not be deliverable. If sent as traffic
("ST"), the message will be forwarded to the closest BBS in the
addressee's state or region and a traffic handler will download the message and
take it to a regional or local voice net or contact the addressee in person as
is done with regular traffic.
5. A powerful advantage of the MARS packet/digital system is the forwarding system auto-routing of messages based on call sign, zip code, or @bbs.st where ".st" is the U.S. postal two letter code for state abbreviation.
6. It is possible to send a packet/digital message to any member by only his call sign (assuming you know he is a packet/digital system user/operator and he has registered his home BBS on your local BBS system).
Knowing only the call, the digital routing
system will ONLY route this message if the member has registered on your local
BBS and has listed his home BBS. The system works best if you can include more
data in the "To" line such as state or in the "SP" BBS
command line such as "sp firstname.lastname@example.org" however the system will get a
message addressed by call only to a system that can identify the call and
determine where the message should be delivered. There is no guarantee a
message sent to just a member call sign can be delivered regardless of message
7. IMPORTANT - messages sent as private cannot be guaranteed deliverable. These are unaccountable messages, and cannot be considered official or accountable traffic for this reason.
End of part 5.