One, two, three, four, one, two...
 Let me tell you how it will be, All.

Please, send all comments (especially with correction of english) to my
net- or e-mail.

=== Cut from fsp-xxxx-1.001 ===
**********************************************************************
FTSC                             FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************

Publication:    FSP-xxxx
Revision:       1
Title:          FidoNet Text Packet/Message format
Author:         Gennady Kudryashoff
Revision Date:  unknown
Expiry Date:    unknown
----------------------------------------------------------------------


Status of this document
-----------------------

    This document is a Fidonet Standards Proposal (FSP).

    This document specifies an optional Fidonet standard protocol
for  the  Fidonet  community,   and   requests   discussion   and
suggestions for improvements.

    This document is released to the public domain,  and  may  be
used, copied or modified for any purpose whatever.

    Implementation of this document obsolete all  documents  (all
of them,  or only parts of  the  documents),  anyhow  bound  with
presentation and network layers of data  definition  in  FidoNet.
There is: FTS-0001, C1, E1 paragraphs, FTS-0004 and further.

Contents
--------

    0. Foreword.
    1. Basics.
    1.1. FidoNet addressing, according to this standard.
    1.2. Definitions (message, echoconference, packet, bundle).
    2. Message.
    3. Netmail message and it's header fields.
    4. Echomail message and it's header fields.
    5. Message body.
    6. Packet.

    0. Foreword.
    ------------

    This  standart  describe  text  messages  and  packets.  This
standard was born after a hard'n'heavy flame wars in  FTSC_PUBLIC
and  SU.FIDOTECH  FidoNet  conferences.   I'm  thankful  for  all
subscribers of all this echoes.

    This standard is NOT intended to dictate the internal formats
used by sites, the specific message system features that they are
expected to support,  or  any  of  the  characteristics  of  user
interface programs that create or read FidoNet messages.

    A distinction should be made between what  the  specification
REQUIRES and what it ALLOWS.  Messages can be  made  complex  and
rich with formally-structured components of information or can be
kept small and simple, with a minimum of such information.  Also,
the standard simplifies the interpretation  of  differing  visual
formats in messages;  only the visual  aspect  of  a  message  is
affected and not the interpretation  of  information  within  it.
Implementors may choose to retain such visual distinctions.

    This standard is based on ideas,  formed  and  formulated  in
RFC-822 ARPANet standard.

    All comments and suggestions are welcome.

    1. Basics.
    ----------

    1.1. FidoNet addressing, according to this standard.

    FidoNet address consist of four  components:  Zone,  Network,
Node and Point. Formal record of FidoNet address is:

    Zone:Network/Node.Point. Example:

    2:5020/1159.0
    7:1130/994.23
    832:23/82.1

    This is 4D-addresses.

    If Point number is equal to 0,  so we have node  address,  or
3D. 3D-systems only can carry echomail between each other, points
should connect to their nodes.  When 3D-address used '.0' may  be
ignored. Example:

    2:5020/1159
    7:1130/994

    Domains are not used in this standard,  except From:  and To:
fields of netmail messages, and From:  and Comment-To:  fields of
echomail messages (see below).

    1.2. Definitions.

    1.2.1. Message.

    Messages consist of lines of text.  No special provisions are
made for encoding  drawings,  facsimile,  speech,  or  structured
text. No significant consideration has been given to questions of
data compression or to transmission and storage  efficiency,  and
the standard tends to be free with the number of  bits  consumed.
For example, field names are specified as free text,  rather than
special terse codes.

    A general "memo"  framework  is  used.  That  is,  a  message
consists of some information in a rigid format,  followed by  the
main part of the message,  with a format that is not specified in
this  document.   The   syntax   of   several   fields   of   the
rigidly-formated  ("headers")  section   is   defined   in   this
specification;  some of these fields  must  be  included  in  all
messages.

    1.2.2. Echoconference.

    Conference have it's name (or tag, echotag) message (echomail
message) can  belong  to.  Each  conference  can  be  distributed
widely, and not only sender and receiver of messages can read it,
but other subscribers of this conference too.

    1.2.3. Packet.

    Packet is a file, that consist of messages send from one node
to another (or from node to point, or from point to node).

    2. Message.
    -----------

    Formal view of message is a number of strings, separated each
other by CRLF (0D0A) characters.  Message consist of  header  and
body separated each other  by  empty  line,  i.e.,  a  line  with
nothing preceding the CRLF.

    Fields may be  viewed  as  being  composed  of  a  field-name
followed  by  a  colon  (":"),  followed  by  a  field-body,  and
terminated by a carriage-return/line-feed. The field-name must be
composed of printable ASCII  characters  (i.e.,  characters  that
have values between 33.  and 126.,  decimal,  except colon).  The
field-body may be composed of any ASCII characters,  except CR or
LF.

    Certain field-bodies of headers may be interpreted  according
to an internal syntax that some systems may wish to parse.  These
fields are called "structured fields".  Examples  include  fields
containing dates and addresses.  Other fields,  such as "Subject"
and "Comments", are regarded simply as strings of text.

    Note:  Any field which has a field-body that  is  defined  as
other than simply  is to be treated as a structured field.

    To aid in the creation and reading of structured fields,  the
free insertion of linear-white-space (which  permits  folding  by
inclusion of CRLFs) is allowed between lexical tokens.

    Header field definition:

    field       =  field-name ":" [ field-body ] CRLF

    Example:

    From: Gennady Kudryashoff 
    Flags:
    Conference: AREA.TAG

    Fields  names  are   not   case-preserved,   and   would   be
case-insensitive.

    Some field names reserved by this standard,  some  by  others
(some kludge lines in prev. standards can be considered as fields
as they are useful to use with this standard) standard.  There is
common 'fieldspace', beginning with 'X-'. It's guaranteed that no
one FTSC standard will describe field, beginning with 'X-'.

    3. Netmail message and it's header fields.
    ------------------------------------------

    3.1. Basic header fields.

    There is minimal  number  of  basic  header  fields  to  make
netmail message valid. Here they are:

    3.1.1. From:

    Syntax:

    From: name string 

    "name string" is any string.  If '' or '\'  characters
are present in  this  string  they  would  be  escaped  with  '\'
character.
     is an fidonet address in angular  brackets.  Syntax
of address is:

    address = address[{at}domain],  where domain must  be  not  more
than eight symbols.

    Example:

    From: Gennady Kudryashoff 
    From: Eugene Kadushin 
    From: Some Name \ 

    This field describes sender of message:  name and  his  (its)
address.

    3.1.2. To:

    This field is built like From: field,  and describes receiver
of message: name and his (its) address.

    3.1.3. Date:

    This field contains date of the message. Syntax:

    Date: DATE TIME TimeZone

    where DATE  is  a  date  of  generating  of  the  message  in
DD/MM/YYYY form,  and TIME is a time of generating of the message
in HH:MM:SS form.
    Syntax of TimeZone:

    [+|-]hhmm

    Example:

    Date: 23/02/1999 12:12:03 +0300
    Date: 24/08/2001 23:03:11 -0100
    Date: 01/10/2003 23:55:00 0000

    3.1.4. Simple netmail message.

    Simple netmail message looks like that:

    =========
    From: Gennady Kudryashoff 
    To: Alexander S. Tokareff 
    Date: 23/02/1999 12:12:03 +0300

    Here is text of the message.
    .
    =========

    (what point is, see below in the section '5. Message body')

    or
    =========
    From: SomeMail Robot 
    To: Gennady Kudryashoff 
    =========

    3.2. Additional fields.
    3.2.1. Message-ID:

    Syntax:

    Message-ID: string{at}address

    string is any string,  that contain only  alphanumeric  ASCII
characters.
    address is address, as used in From: field.

    Examples:

    Message-ID: SomeString_6277251{at}2:5020/1159

    From: John Gladkih 
    Message-ID: 72981661{at}2:5051/16{at}fidonet

    Message-ID:  field body must be unique  for  at  least  three
years after generating.

    3.2.2. Replying-ID:

    Replying-ID:  is a field used when editor  (or  another  mail
generating   program)   generate   reply   to   someone's   mail.
Replying-ID:  is a  copy  of  Message-ID:  field  of  originating
letter.

    3.2.3. Reply-To:

    Reply-To:  is a field used to reply to another address,  than
used in From: field. For example, internet address or local point
address can be used here.

    3.2.4. Subject:

    Subject: field is unstructured text field.

    3.2.5. Comments:

    Comments:  field is unstructed text field used for  comments,
inserted by human or mail program.

    Example:

    From: somename \ 
    Comments:      ^         ^ was not ESCaped on 2:5050/43

=== Cut fsp-xxxx-1.001 ===

* Crossposted in NET_DEV

    Gennady Kudryashoff.                            [Team The Beatles]
--- E-Mail: genka{at}bum.elektra.ru