2002-02-16 21:38:40 +00:00
|
|
|
<HTML>
|
|
|
|
|
<!-- $Id$ -->
|
|
|
|
|
<HEAD>
|
|
|
|
|
<TITLE>Specifications for the ^aFLAGS field.</TITLE>
|
|
|
|
|
</HEAD>
|
|
|
|
|
|
|
|
|
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
|
|
|
<BODY
|
|
|
|
|
BGCOLOR="#FFFFFF"
|
|
|
|
|
TEXT="#000000"
|
|
|
|
|
LINK="#0000FF"
|
|
|
|
|
VLINK="#000080"
|
|
|
|
|
ALINK="#FF0000"
|
|
|
|
|
>
|
|
|
|
|
<PRE>
|
|
|
|
|
Document: FSC-0053
|
|
|
|
|
Version: 002
|
|
|
|
|
Date: 08-Dec-92
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specifications for the ^aFLAGS field
|
|
|
|
|
|
|
|
|
|
Joaquim H. Homrighausen
|
|
|
|
|
2:270/17@fidonet or joho@ae.lu
|
|
|
|
|
|
|
|
|
|
December 8, 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Status of this document:
|
|
|
|
|
|
|
|
|
|
This FSC suggests a proposed protocol for the FidoNet(r) community,
|
|
|
|
|
and requests discussion and suggestions for improvements.
|
|
|
|
|
Distribution of this document is unlimited.
|
|
|
|
|
|
|
|
|
|
Fido and FidoNet are registered marks of Tom Jennings and Fido
|
|
|
|
|
Software.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Purpose
|
|
|
|
|
|
|
|
|
|
To explain and document the existing usage of the ^aFLAGS field used
|
|
|
|
|
by many software packages, including FrontDoor, TosScan, and
|
|
|
|
|
D'Bridge. And to inform software authors of its proper usage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Prologue
|
|
|
|
|
|
|
|
|
|
One of the problems with the FTS-1 (stored) message format is its
|
|
|
|
|
limitations in regards to message attributes. Several bits are used
|
|
|
|
|
(reserved) by SEAdog, another by several packers and editors - even
|
|
|
|
|
though most mailer authors don't support them, they remain. One
|
|
|
|
|
reason would be backward compatibility with older software.
|
|
|
|
|
|
|
|
|
|
Unfortunately, this presents a problem for software authors that
|
|
|
|
|
would like to pass extended message attributes for use and handling
|
|
|
|
|
by other software.
|
|
|
|
|
|
|
|
|
|
Some software packages have been using an alternate method called
|
|
|
|
|
"FLAGS" which is 7-bit ASCII placed behind <SOH>FLAGS somewhere near
|
|
|
|
|
the beginning of a message. The various flags will now be described.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Flags
|
|
|
|
|
|
|
|
|
|
The FLAGS string should be placed somewhere near the beginning of
|
|
|
|
|
the message text, and is preceeded by a <SOH> (^a) character. There
|
|
|
|
|
is no need to support all or any of the below mentioned flags.
|
|
|
|
|
|
|
|
|
|
If flags are stripped when a message passes through a system, all
|
|
|
|
|
relevant and correct FTS-1 status bits should be updated to indicate
|
|
|
|
|
the original contents of the FLAGS field.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Flag Brief Long description
|
|
|
|
|
--------------------------------------------------------------------
|
|
|
|
|
PVT Private Indicates that the message may only be read
|
|
|
|
|
by its addressee and author.
|
|
|
|
|
|
|
|
|
|
HLD Hold Message should be held for pickup by its
|
|
|
|
|
destination system.
|
|
|
|
|
|
|
|
|
|
CRA Crash High-priority mail.
|
|
|
|
|
|
|
|
|
|
K/S Kill/Sent Remove message after it has been success-
|
|
|
|
|
fully sent.
|
|
|
|
|
|
|
|
|
|
SNT Sent Message has been successfully sent (used
|
|
|
|
|
for message without Kill/Sent status).
|
|
|
|
|
|
|
|
|
|
RCV Received Message has been read by its addressee.
|
|
|
|
|
|
|
|
|
|
A/S Archive/Sent Place message in "sent mail" archival
|
|
|
|
|
system after it has been successfully sent.
|
|
|
|
|
|
|
|
|
|
DIR Direct Message must be sent directly to its
|
|
|
|
|
destination and may not be routed.
|
|
|
|
|
|
|
|
|
|
ZON Zonegate Send message through zonegate (if
|
|
|
|
|
possible).
|
|
|
|
|
|
|
|
|
|
HUB Hub/Host-route Host- or Hub-route message (as
|
|
|
|
|
appropriate).
|
|
|
|
|
|
|
|
|
|
FIL File attach Message has one or more files attached to
|
|
|
|
|
it.
|
|
|
|
|
|
|
|
|
|
FRQ File request Message has one or more file requests in
|
|
|
|
|
subject field.
|
|
|
|
|
|
|
|
|
|
IMM Immediate NOW!-priority mail. Send at first
|
|
|
|
|
opportunity, override any transmission
|
|
|
|
|
restrictions enforced by events, costs, or
|
|
|
|
|
qualification.
|
|
|
|
|
|
|
|
|
|
XMA Xmail Message has alternate form of compressed
|
|
|
|
|
mail attached.
|
|
|
|
|
|
|
|
|
|
KFS Kill file Remove attached file(s) after they have
|
|
|
|
|
been successfully sent. Only valid for file
|
|
|
|
|
attach message.
|
|
|
|
|
|
|
|
|
|
TFS Truncate file Truncate attached file(s) to zero length
|
|
|
|
|
after they have been successfully sent.
|
|
|
|
|
Only valid for file attach message.
|
|
|
|
|
Primarily used by Conference Mail
|
|
|
|
|
processors.
|
|
|
|
|
|
|
|
|
|
LOK Lock Prevent message from being processed.
|
|
|
|
|
This includes sending, deleting,
|
|
|
|
|
purging, and editing.
|
|
|
|
|
|
|
|
|
|
RRQ Receipt REQ When the mailer/packer at the message's
|
|
|
|
|
final destination unpacks the message, it's
|
|
|
|
|
asked to generate a receipt to the author
|
|
|
|
|
of the message that indicates that the
|
|
|
|
|
message arrived at its final destination.
|
|
|
|
|
|
|
|
|
|
CFM Confirm REQ When message is read by its addressee, a
|
|
|
|
|
Confirmation Receipt should be generated to
|
|
|
|
|
the author of the message.
|
|
|
|
|
|
|
|
|
|
HIR HiRes FAX: Hi-Resolution image.
|
|
|
|
|
|
|
|
|
|
COV CoverLetter FAX: Cover sheet.
|
|
|
|
|
|
|
|
|
|
SIG Signature FAX: Signature.
|
|
|
|
|
|
|
|
|
|
LET LetterHead FAX: LetterHead.
|
|
|
|
|
|
|
|
|
|
| FAX Fax image The filename specified in the message's
|
|
|
|
|
| subject field contains a fax document that
|
|
|
|
|
| should be viewed using software capable of
|
|
|
|
|
| doing so.
|
|
|
|
|
|
|
|
|
|
| FPU Force pickup Treated as a message with an IMM flag. This
|
|
|
|
|
| instructs the mailer to keep calling the
|
|
|
|
|
| destination system, if the connection is
|
|
|
|
|
| aborted for some reason, until a valid "End
|
|
|
|
|
| of files" signal is received (i.e. no more
|
|
|
|
|
| files remain to pick up).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Notes
|
|
|
|
|
|
|
|
|
|
Xmail is related to the ARCmail 0.60 standard as adopted by the FTSC.
|
|
|
|
|
The exception is that any type of compression method may be used and
|
|
|
|
|
the naming convention isn't necessarily limited to that of the
|
|
|
|
|
ARCmail 0.60 standard.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Epilogue
|
|
|
|
|
|
|
|
|
|
Feedback would be appreciated and can be sent to me at the addresses
|
|
|
|
|
specified on the title page. Please send feedback via netmail.
|
|
|
|
|
</PRE>
|
|
|
|
|
|
|
|
|
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
|
|
|
|
|
|
|
|
|
|
</BODY>
|
|
|
|
|
</HTML>
|
|
|
|
|
|
|
|
|
|
|
