Air Force MARS
TRANSCON Digital Network
Subject: PACKET/DIGITAL MESSAGE FORMAT
(Updated 17 DEC 03 - original 04 JUL 01)
Part 1.
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
digital modes.
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.
====================================================
Part 2
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
CONUS),etc.).
4. Messages and traffic should sit unmoved on a BBS station for no more than 24
hours.
End of part 2
====================================================
Part 3.
Subject: PACKET/DIGITAL MESSAGE EXAMPLES.
1. There are several types of messages used in AF MARS, broadcasts/bulletins,
traffic, private messages, and service messages.
a. Bulletins/broadcasts
("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
"SP AFF1C@AFA1UN.PA"
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
AFF1C@AFA1UN.PA
<Subject:> NCS TRAINING
<Enter Message:>
DE AFA1II@AFA1HN.MA NR 01
R 310100Z JUN 01
FM LEE RAND AFA1II MA
TO RICHARD MOWERY AFF1C
LANCASTER PA TEL 555-5555
GRNC
BT
WHEN IS THE NEXT NCS TRAINING SESSION?
SGD LEE AFA1II
BT
/EX
Message Queued
<AFA1HN BBS:>
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
message.
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
92640@92640(CR)
<subject:> garden grove,ca/714-638(CR)
<enter message:>
DE AFA1NC NR 100(CR)
R 182321Z NOV 89(CR)
FM ROD FOWLER(CR)
341 LINCOLN AVE(CR)
BEVERLY, NJ 08010(CR)
609-387-1155/AFA1NC NJ(CR)
TO GARDNER HARRIS(CR)
11791 LOARA STREET(CR)
GARDEN GROVE CA 92640-2321(CR)
714-638-8807(CR)
GR12(CR)
BT(CR)
TEN GROUPS PER LINE EXCEPT LAST LINE WHICH WILL CONTAIN(CR)
THE REMAINDER(CR)
BT(CR)
/EX(CR)
<BBS prompt:>
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.
====================================================
Part 4.
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)
<enter message:>
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 SHARES(CR)
ZEN CHIEF ARMY MARS(CR)
ZEN CHIEF NAVMARCOR MARS(CR)
BT(CR)
NOTE: TEXT OF MESSAGE FOLLOWS STANDARD MARS FORMAT.(CR)
BT(CR)
/EX(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.
====================================================
Part 5.
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 aff1c@afa1un.pa(CR)
<subject:> problem with lan1 node(CR)
<enter message:>
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)
GRNC(CR)
BT(CR)
DICK, I THINK YOU NEED TO CHECK THE NODE, IT(CR)
IS NOT RESPONDING.(CR)
SGD MITCH AFF1K / AFA1HN(CR)
BT
/EX
<BBS Prompt>
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 call@bbs.st" 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
type
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.
====================================================