Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 0841

Specification for message format for Computer Based Message Systems

Pages: 117
Unclassified
Obsoletes:  0806
Part 2 of 4 – Pages 35 to 69
First   Prev   Next

ToP   noToC   RFC0841 - Page 35   prevText
      3.2.2.2  Assignment

           Assignment is the process of designating responsibility.  In
      some  organizations, formal message traffic is distributed to one
      or more parts of the organization (called offices)  where  it  is
      directed  to  the  appropriate  individuals  or other offices for
      final disposition.  Assignment is done  by  reissuing  a  message
      with   the   Reissue-Type   field  containing  the  ASCII  string
      "Assigned."  A  message  which  contains  this  field  is  to  be
      interpreted as meaning that the addressees in the "To" field have
      had  the  reissued message assigned to them for some action.  Any
      addressee in the "Cc" field has  had  the  message  assigned  for
      information.    The "From" field records who assigned the message
      and  the  "Posted-Date"  field  records  when  the  message   was
      assigned.


      3.2.3  Reply generation


           Reply  generation  involves creating a new message in direct
      reply to some other message by drawing on the contents of  fields
      in  the  other  message  to fill fields in the new message.  Many
      CBMSs provide reply facilities that determine the intended recip-
      ients of a reply.

           A Reply-To field is defined by this message format  specifi-
      cation.    When  a  message  contains  a Reply-To field, the CBMS
      should send replies to the recipients designated in the  Reply-To
      field  instead of to the recipients designated in the From field.
      This statement applies to original messages only, not to reissued
      messages.     The   message   format   specification   makes   no
      recommendations concerning replies to reissued messages.

           Reply-To has several possible applications:


        o  The  individual(s) responsible for the message might not
           have regular access to a  CBMS  and  would  indicate  an
           alternate recipient, for example, a secretary.

        o  The people responsible for receiving responses might not
           be  the  people  who  were  responsible for creating the
           message.

        o  Discussion and conference groups could use this  feature
           to  ensure  correct  distribution  of  any submission by
           having the conference group  itself  designated  in  the
           Reply-To field.
ToP   noToC   RFC0841 - Page 36
           When  the  message  does  not  contain a Reply-To field, the
      recipient should reply to the originators enumerated in the  From
      field.   The sender and authors should not be added automatically
      to the list of those receiving the reply.

           Replies could also be sent to the other  recipients  of  the
      original  message.    Vendors might offer additional reply facil-
      ities, depending on their view of users' organizational  require-
      ments.


      3.2.4  Cross-referencing


           A  CBMS  message  may  include  designator(s) which identify
      other message(s).  The designators are used to refer  to  related
      messages so that all information in a chain of correspondence can
      be  determined  by  a CBMS user.  The designator used to identify
      and cross-reference messages can take either of two forms, unique
      identifiers or serial numbers.


      3.2.4.1  Unique identifiers

           Unique identifiers are machine-generated  and  are  intended
      primarily  for  processing  by  computers.    While they could be
      examined by a human user, unique identifiers are not  necessarily
      useful or convenient for people.

           Unique  identifiers  occur  in  several  contexts.  They are
      often used  to  identify  the  contents  of  idual  messages
      unambiguously.    When unique identifiers are used this way, they
      are called message identifiers.  Different versions of a  message
      receive  new message identifiers; an example of this is reissuing
      a message with comments.

           When a CBMS generates a message identifier, it must be  able
      to  guarantee  that  it  is unique, both within the domain of the
      individual CBMS and globally, across all connected CBMSs.   CBMSs
      could  generate  globally unique identifiers in several ways, all
      of which require prior  agreement  on  behalf  of  the  connected
      CBMSs.    One  method  is  to assign each connected CBMS a unique
      code.  A CBMS then generates unique identifiers by using its code
      as a prefix to some other value  that  it  can  guarantee  to  be
      unique  within its domain.  (This second value could be a counter
      or a timestamp/user-id combination.)

           A CBMS can provide functions for tracing  chains  of  corre-
      spondence  by  using  unique  identifiers.    The  message format
      specification defines fields for which  a  CBMS  provides  unique
      identifiers   as   values.    They  are  Message-ID,  References,
      Obsoletes, and In-Reply-To.  (See Section 3.1.6.)
ToP   noToC   RFC0841 - Page 37
      3.2.4.2  Serial numbering

           Serial  numbers  are  for  users to maintain a personal num-
      bering system for messages.  The numbers  are  composed  of  both
      letters  and  digits so that users could maintain several sets of
      sequences concurrently (for example, A1, A2, A3...  and  B1,  B2,
      B3...).

           Serial  numbers  are  assigned  at  a  defined  point in the
      history of a message.  Serial numbers are not unique identifiers;
      they differ from unique identifiers in that they are  not  neces-
      sarily generated or processed by a CBMS.  They are designed to be
      entered and read by CBMS users.  They can be as simple or complex
      as  the user requires.  Serial numbers are intended to be used to
      designate messages about a specific topic, or  messages  a  given
      user  has  sent.    Serial numbers are intended to be a permanent
      part of the message, just as unique identifiers are.

           A CBMS can provide functions  allowing  originators  to  add
      serial  numbers  to  messages.    Originator-Serial-Number is the
      field provided for an originator to add  a  serial  number  to  a
      message before sending it.


      3.2.5  Life span functions


           Messages  have life spans, usually delimited by the creation
      date and the time when the last copy of the message is destroyed.
      Messages could be meaningless before a certain time or irrelevant
      after a certain time.   For  example,  a  reminder  to  attend  a
      meeting  on  5  June  loses  most  of  its  value on the sixth; a
      reminder to attend that same meeting may be of little  use  on  5
      May (although not for the same reason).

           A CBMS can define a message's life span explicitly using the
      Start-Date  and  End-Date  fields.   A third field, Warning-Date,
      when used in conjunction with the End-Date, may be used to signal
      the approach of the End-Date.  Warning-Date may also stand  alone
      and be used by a periodic warning (alarm clock) mechanism.

           A  CBMS  could  use  these fields to help users manage their
      message stores.  For example, a message whose start date has  not
      yet  passed  could  be bypassed by a retrieval command unless the
      user requested such messages explicitly.  A CBMS  could  use  the
      end  date  to  help  with  message  store  housekeeping either by
      archiving or deleting the expired messages  automatically  or  by
      asking the user for some action to be taken on them.  The warning
      date  could  be  used  to  remind  the  user  automatically of an
      impending end date, such as a meeting reminder.
ToP   noToC   RFC0841 - Page 38
      3.2.6  Requests for recipient processing


           Recipients  have  a  wide variety of needs for examining and
      processing a message,  ranging  from  automatic  output  on  some
      specified  device  to  the execution of a program embedded in the
      message  itself.    Because  many  of  these  needs  are   highly
      specialized,  and  support  for them not widely implemented, this
      message format specification does not constrain the requests  for
      processing that may be included in a message.

           The  message  format  specification  does provide two fields
      that permit an originator to request circulation list  processing
      from the recipient.  These fields are Circulate-To and Circulate-
      Next.


      3.2.6.1  Message circulation

           Message  circulation  involves serial distribution of a mes-
      sage to its recipients, based on a distribution list that is part
      of the message.  The message is  delivered  first  to  the  first
      recipient  on  the distribution list.  This recipient, or someone
      the recipient delegates, sends  the  message  on  to  the  second
      recipient  on  the list, perhaps after commenting on or adding to
      the  message.    This  continues  until  all  recipients  on  the
      distribution list have received the message.

           This  message  format  specification  provides two fields to
      support message circulation.  The Circulate-To field contains the
      complete distribution list, indicating the  full  set  of  recip-
      ients,  and  the  Circulate-Next field indicates which recipients
      have not seen the message.   See  Figure  3  for  an  example  of
      message circulation using these two fields.



      3.3  Multiple Occurrences and Ordering of Fields


           Most  message  fields may occur more than once in a message;
      the  exceptions  are  the  Posted-Date,  Sender,  and  Message-ID
      fields, which may occur once, at most.  What this means is that a
      received  message  may  contain  any  number  of  instances  of a
      particular field (such as the "To" field).  If a message contains
      more than one instance of a particular field, that field  "occurs
      multiply"  and  that  message  has "multiple occurrences" of that
      field.

           A particular instance of a message field is  not  superseded
      by later instances of the same field.  The To field is an example
      of this.
ToP   noToC   RFC0841 - Page 39
      -----------------------------------------------------------------


           A  message  originator wishes to circulate a message to
           recipients A, B  and  C. The  originator  includes  the
           following fields in the message:

                     To:              A
                     Circulate-To:    A, B, C
                     Circulate-Next:  B, C


           When  recipient  A  or  someone  A delegates causes the
           message to be further circulated, the message  is  sent
           to  the  first address in the Circulate-Next field, and
           that name is removed from that field:

                     To:              B
                     Circulate-To:    A, B, C
                     Circulate-Next:  C


           B now sends the message on to its final recipient:

                     To:              C
                     Circulate-To:    A, B, C


      FIG. 3.  EXAMPLE OF MESSAGE CIRCULATION


      -----------------------------------------------------------------


           Multiple occurrences of a field are not  necessarily  equiv-
      alent  to  a single field containing the concatenated contents of
      the several instances of the given field.  For example, with  the
      Text field, concatenating the contents of several instances might
      lose  important  distinctions  between  the  contents.   A single
      message could be used to send three different documents, each one
      in a different Text field.  However, putting the three  documents
      into  a  single  Text  field would make it much more difficult to
      extract any individual document.

           Encapsulated  messages  are  exceptions  to   the   multiple
      occurrences  rule.   For example, the To field in an encapsulated
      message is not a multiple occurrence  of  the  To  field  in  the
      enclosing message.

           The fields found in a single message may occur in any order.
      The  order  in  which they occur does not necessarily reflect the
ToP   noToC   RFC0841 - Page 40
      order  in  which  they  were  created.  Nor does it constrain the
      order in which the  message  recipient  examines,  processes,  or
      displays them.
ToP   noToC   RFC0841 - Page 41
      4.  SYNTAX


           This section begins with an introduction to the concepts and
      elements  that  constitute  the  syntax for messages.  The second
      section presents an overview of the encoding scheme.   The  third
      section describes in detail the elements of the message syntax.



      4.1  Introduction


           This  specification  defines syntactic requirements for mes-
      sages when they are  passed  from  one  CBMS  to  another.    The
      specification is designed to meet the following goals.


        o  Provide a concise, flexible representation scheme.

        o  Simplify message parsing.

        o  Support non-textual components in messages (for example,
                                         3
           facsimile, graphics, or speech ).


      4.1.1  Message structure


           Messages   have   two  classes  of  components,  fields  and
      messages.  A field corresponds to one of the semantic  components
      defined  in  this  message  format  specification.   A message is
      simply another message.

           The type of a field in a message determines both its meaning
      and the form for its contents.  (See Section 4.3.2.)

           Fields in a  message  are  composed  of  syntactic  elements
      called  data  elements.    A  Message  data  element  is  used to
      represent messages; a Field data element  is  used  to  represent
      fields.    (The  term  "field"  is  simply  a semantic construct,
      distinct  from  "Field  Data  Element,"  which  is  a   syntactic

      _______________

        3
         While  this message format specification is not intended to be
      used as a basis for the interchange of all facsimile information,
      it does  recognize  that  CBMS  messages  may  contain  facsimile
      components.
ToP   noToC   RFC0841 - Page 42
      construct.)    Many  of the fields defined in this message format
      specification are restricted to containing only one kind of  data
      element.  (See Section 4.3.2.)

           Each  field defined in this message format specification has
      been assigned  a  unique  numeric  identifier  that  is  used  in
      conjunction  with  the  Field data element.  Separate identifiers
      are provided for vendor-defined  fields  and  for  extending  the
      identifier  encoding  space.    A  list of fields and identifiers
      appears in Section 4.3.2 and in Appendix C.

           Throughout the  message  format  specification,  fields  are
      referred  to  by  label name rather than by their numeric identi-
      fiers.  Field labels are names like "Sender," "Warning-Date,"  or
      "Circulate-To."    The  field labels chosen for the specification
      are names  that  are  in  common  use  in  current  CBMSs.    The
      specification  does  not require a CBMS to use these field labels
      in displaying fields to the user.  


      4.1.2  Data elements


           For the purpose of determining compliance  with  the  syntax
      defined in this specification, data elements are divided into two
      groups:


      BASIC     All   message  receiving  systems  must  process  these
                syntactic elements, interpreting their values according
                to the message format specification.

      OPTIONAL  Message  receiving  systems  need  not  process   these
                syntactic elements in order to be in compliance.


           In   addition,   complying   CBMSs  must  meet  requirements
      regarding their ability to process the  components  found  inside
      data  elements.    These  requirements  are  discussed in Section
      4.2.2.

           This message format specification  classifies  data  element
      types  as  either  primitives  or  constructors.   Primitive data
      elements,  such  as  ASCII-String,  are  basic  building  blocks.
      Constructor  data  elements, such as Message or Sequence, contain
      one or  more  primitive  or  constructor  data  elements.    Some
      constructors, such as Sequence, may be composed of any other data
      element.    Some,  such as Message, may contain only certain data
      elements. Two data elements, Extension and Vendor-Defined, may be
      classified as either primitives or constructors, depending on how
      they  are  used  to  extend  this  specification.    The  general
      syntactic form for data elements is discussed in section 4.3.1.
ToP   noToC   RFC0841 - Page 43
      4.1.2.1  Primitive data elements

           A   primitive   data   element  contains  a  basic  item  of
      information; it is not composed  of  other  data  elements.    In
      current  CBMSs,  the most commonly used primitive data element is
                                                 4
      ASCII-String, a series of ASCII characters.  Other primitive data
      elements are Integer,  2's  complement  integers;  Bit-String,  a
      series of bits; and Boolean, either True or False.

           One primitive data element, End-Of-Constructor, is used only
      as  a structural element within constructor data elements and has
      no meaning by itself.  End-of-Constructor is used to  provide  an
      end  marker  for  constructor  data  elements that do not have an
      explicit length; any other use is not valid syntactically.


      4.1.2.2  Constructor data elements

           The Data  Element  Contents  of  constructor  data  elements
      contain  one  or  more data elements.  The most general form of a
      constructor is a Sequence or a Set, since both Sequences and Sets
      may contain any data element.  Other constructors are specialized
      forms of sequences.

           A Message data element is a constructor.    It  may  contain
      only  Field  data  elements,  other  Message  data  elements,  or
      encrypted or data compressed forms of these elements.    A  Field
      data  element  can  contain  any data element.  It also indicates
      which specific field is being represented.  The contents of  some
      fields  are  restricted to a single type of data element, such as
      ASCII-String or Date.


      4.1.3  Properties


           Any data element may have associated  with  it  a  Property-
      List, which contains properties such as a Printing-Name or one or
      more  Comments.    Comment  A mechanism to support vendor-defined
      properties has been supplied by this specification, as well as  a
      mechanism to extend the list of property identifiers.


      _______________

        4
         An  ASCII-String  is  not limited to ASCII characters however.
      The  ASCII  code  table  can  be  extended  through  standardized
      techniques as described in FIPS Pub 35, Code Extension Techniques
      in 7 or 8 Bits [NatB-75].
ToP   noToC   RFC0841 - Page 44
      4.1.3.1  Printing-names

           Printing-Names  are  used  to  provide  labels  that  can be
      displayed  along  with  their  respective  data  elements.    For
      example, a message originator may use a Printing-Name property to
      request that the To field of a message be labeled "Distribution:"
      when it is printed by its recipients.


      4.1.3.2  Comments

           The  Comment  property  is  used  to  allow  comments  to be
      associated with any data element  without  affecting  its  actual
      contents.    For example, someone reviewing the text of a message
      could add the comment "This looks good" to the Text field without
      either altering the body itself  or  adding  a  separate  comment
      field.


      4.1.4  Data compression and encryption


           Two  constructor  data  elements,  Compressed and Encrypted,
      have  been  provided  for  use  by  a  CBMS  that  supports  data
      compression  or  encryption.    They  may  be  used  to  hold the
      compressed or encrypted contents of any data  element,  including
      Messages  and  Fields, and may occur wherever their compressed or
      encrypted contents may appear.  A mechanism is included to  allow
      the user to identify the encryption or compression algorithm used
      (Sections 4.3.4 and 4.3.5).



      4.2  Overview of Syntax Encoding


           This  section  provides  an  overview  of  the  notation and
      terminology  used  to  represent  the  syntactic  elements  (data
      elements) defined in this message format specification.

           All  data  elements consist of a series of components.  Each
      of the components is composed of a series of 8-bit groups  called
      octets.    In  this document, the bits are numbered starting from
      the low-order bit.  That is, the low-order (or least significant)
      bit is called "bit 0" and the high-order  (or  most  significant)
      bit is called "bit 7."  

           Five different components may appear in a data element.


        o  Identifier  octet  (identifying  particular type of data
           element)
ToP   noToC   RFC0841 - Page 45
        o  Length  Code  (specifying  number  of octets that appear
           following it in a data element)

        o  Qualifier (supplying additional identifying information)

        o  Property-List component (a  Property-List  data  element
           containing Property data elements)

        o  Data  Element  Contents  (containing  actual data of the
           data element)


      These components always appear in this order.  Not all components
      are present in all data elements, but  the  components  that  are
      present maintain this relative order.


      4.2.1  Identifier Octets


           The  identifier  octet  is  a numeric code containing infor-
      mation that identifies a data element.  It is  always  the  first
      component  in  a  data  element.  The Identifier octet contains a
      one-bit flag, indicating whether or not the data element contains
      a Property-List, and a  7-bit  unique  identifier  for  the  data
      element.  The value of the data element identifier also indicates
      whether the data element has a Qualifier.

           The  most significant bit (Bit 7) of the identifier octet is
      set to 1  if  there  are  properties  associated  with  the  data
      element;  it  is  set  to  0  if  there  are  none.   This bit is
      independent of the remaining seven bits in the identifier  octet,
      which  are  called  the  identifier, and provide unique identifi-
      cation  for  data  elements.    The  associated  properties   are
      specified in a Property-List component.

           The  second  most  significant bit (Bit 6) of the identifier
      octet  (the  most  significant  bit  of  the  identifier  itself)
      signifies  whether  or  not the data element has a Qualifier.  If
      the bit is set to 1, then the data element has a Qualifier; if it
      is a 0, the data element does not have a Qualifier.    The  seven
      bits of the identifier uniquely identify the data element.

           Table  2  shows  the  settings of the high-order bits of the
      identifier  octet  and  their  associated  meaning.    Figure   4
      demonstrates the bit-level structure of the identifier octet.  In
      this figure, bit 7 is indiciated with P to show its special use.
ToP   noToC   RFC0841 - Page 46
      -----------------------------------------------------------------


           bit 7 6 5 4 3 2 1 0
              +---------------+
              |P 0 x x x x x x|     0xxxxxx uniquely identifies a
              +---------------+     data element without a Qualifier.

              +---------------+
              |P 1 x x x x x x|     1xxxxxx uniquely identifies a
              +---------------+     data element with a Qualifier.



      FIG. 4.  STRUCTURE OF IDENTIFIER OCTETS


      -----------------------------------------------------------------





          Bit Value     Meaning

           7    0   The data element does not have properties asso-
                      ciated.
                1   The data element has properties associated.

           6    0   The data element does not have a Qualifier.
                1   The data element has a Qualifier.



          TABLE 2.  HIGH-ORDER BITS IN THE IDENTIFIER OCTET





      4.2.2  Length code and Qualifier components


           The Length Code and the Qualifier are both usually one octet
      in  length.    They use an encoding scheme that permits extending
      the component to the size necessary to represent  the  length  of
      the data element or the value of the Qualifier component.

           The  most  significant  bit  of the Length Code or Qualifier
      components determines whether it is  one  or  several  octets  in
      length.  When the most significant bit is 0, the component is one
ToP   noToC   RFC0841 - Page 47
      octet  in  length.  When the most significant bit is 1, the other
      seven bits of the first octet encode the number of octets in  the
      rest of the component.  The actual value begins in the next octet
      and is interpreted as an unsigned integer.

           A  single  octet  is  sufficient  for  most  Length Code and
      Qualifier components.  For those cases where  the  value  of  the
      Length  Code  or  the  Qualifier  must be greater than 127, extra
      octets can be added, up to a maximum of 127  octets.    Figure  5
      shows  the encoding scheme, as well as an example of a value less
      than 127 and one greater than 127.


      -----------------------------------------------------------------


           bit 7 6 5 4 3 2 1 0
              +---------------+
              |0 x x x x x x x|                   xxxxxxx is the value.
              +---------------+

              +---------------+------//-------+
              |1 n n n n n n n|y y y y y y y y|          nnnnnnn is the
              +---------------+------//-------+        number of octets
                                                       that contain the
                                                        value yyyyyyyy.

              +---------------+
              |0 0 0 0 1 0 0 1|               This is an example with a
              +---------------+                   value of 9 (decimal).

              +---------------+---------------+
              |1 0 0 0 0 0 0 1|1 0 0 0 0 0 1 0|      This example has a
              +---------------+---------------+ value of 130 (decimal).


              +---------------+---------------+
              |1 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1|
              +---------------+---------------+

                              +---------------+
                              |0 0 1 0 1 1 0 0|      This example has a
                              +---------------+ value of 300 (decimal).



      FIG. 5.  ENCODING MECHANISM FOR QUALIFIERS AND LENGTH CODES


      -----------------------------------------------------------------
ToP   noToC   RFC0841 - Page 48
           In  order  to comply with this message format specification,
      CBMSs must be able to determine the value of any length  code  or
      qualifier  that  is  expressed  in  three  octets  or less.  (The

       16
      2  -1).    This message format specification places no limitation
      on the value of a length code or qualifier generated  by  a  CBMS
      (except  for  the  absolute  limitation inherent in the represen-
      tation scheme).  However, the use of length codes and  qualifiers
                                                                  32
      with  larger  values  (particularly  values  in  excess of 2  -1)
      should be avoided unless it is known that  the  receiving  system
      can handle them.  

           Both  Length  Codes and Qualifiers have a special convention
      for dealing with special situations.  Length  Codes  can  specify
      that  a  data  element  has indeterminate length; a Qualifier can
      specify that a data element is  implementation  defined.    These
      cases are explained further in the next two sections.


      4.2.2.1  Length Codes

           The length code component immediately follows the identifier
      octet.    It  is  present in every data element.  The Length Code
      indicates the number of octets following it  in  a  data  element
      (that  is,  excluding  the  identifier  octet and the length code
      itself).  Length Codes appear in one  of  three  formats:  short,
      long, and indefinite.

           A short Length Code is one octet long.  Its most significant
      bit  (Bit  7) is set to 0 and its value is in the range 0 through
      127.

           A long Length Code is at least two octets long.   The  first
      octet  always has its most significant bit (Bit 7) set to 1.  The
      other seven bits of this  octet  contain  the  number  of  octets
      making  up  the rest of the Length Code, and these octets contain

        1016
      (2     - 1) (that is, 127 octets to represent the value).

           An  indefinite  Length  Code  is  one  octet long.  Its most
      significant bit (Bit 7) is set to 1 and its other bits are all 0.
      (See Figure 6.)  An indefinite Length Code  may  appear  only  as
      part  of  a  constructor  data  element;  it  may  not occur in a
ToP   noToC   RFC0841 - Page 49
      -----------------------------------------------------------------


           bit 7 6 5 4 3 2 1 0
              +---------------+
              |0 x x x x x x x|             xxxxxxx is the value of the
              +---------------+                            length code.

              +---------------+------//-------+
              |1 n n n n n n n|y y y y y y y y|   nnnnnnn is the number
              +---------------+------//-------+  of octets that contain
                                                the value of the length
                                            code; these are represented
                                                            as yyyyyyy.
              +---------------+
              |1 0 0 0 0 0 0 0|            The "indefinite" length code
              +---------------+


      FIG. 6.  REPRESENTATION OF LENGTH CODES


      -----------------------------------------------------------------


                              5
      primitive  data  element .    A  constructor data element with an
      indefinite length code has an End-Of-Constructor data element  as
      the  last data element in its Data Element Contents.  (The length
      of such a constructor data element is unrestricted,  although  it
      must  contain at least one data element -- the End-of-Constructor
      that terminates it -- in its Data Element Contents.)


      4.2.2.2  Qualifier

           If present,the Qualifier component immediately  follows  the
      code  component.   It is used to provide information essential to
      the interpretation of the data element contents  that  is  beyond
      that  encoded  in  the  identifier  octet  or  length  code.  For
      example, the identifier octet could contain the code for a field,
      and the Qualifier component would specify what kind of field.

           The Qualifier component appears in only a few data elements.

      _______________

        5
         This is the result of most primitive elements  being  able  to
      contain  any  bit  pattern  (including the identifier for End-Of-
      Constructor).
ToP   noToC   RFC0841 - Page 50
      In the Bit-String data element, it indicates the number of unused
      bits  in  the  final  octet of the Data Element Contents.  In the
      Field and Property data elements, it  indicates  which  field  or
      property  the  data  element  represents.   In the Compressed and
      Encrypted  data  elements,  it  indicates  which  compression  or
      encryption algorithm has been used.  In the Message data element,
      it indicates the type of message.

           The  length  of  the  Qualifier  component  depends  on  the
      encoding of the Qualifier.  (See Figure 7.)  A short Qualifier is
      one octet long.  Its most significant bit is 0 and its  value  is
      in  the  range  0  through 127.  A long Qualifier is at least two
      octets in length.  The most significant bit is always 1  and  the
      other  7  bits  indicate the number of octets in the value of the
      Qualifier.


      -----------------------------------------------------------------




               +--------+--------+--------+
               |10000010|00000001 00001010|        Qualifier with value
               +--------+--------+--------+              266 (decimal).

               +--------+--------+--------+--------+
               |10000011|00000000|00000001 00001010|     Vendor-Defined
               +--------+--------+--------+--------+     Qualifier with
                                                             value 266.

               +--------+
               |10000000|              Undefined value for a Qualifier.
               +--------+



      FIG. 7.  EXAMPLES OF QUALIFIER VALUES


      -----------------------------------------------------------------


           This message format specification allows implementations  to
      define  their  own values for Qualifiers.  A vendor-defined Qual-
      ifier is any long Qualifier in which the first octet in the value
      is 0.    The  value  used  to  identify  this  Qualifier  is  not
      guaranteed  to  be  unique  and  the  same  value  may be used by
      different implementations to define different Qualifiers.
ToP   noToC   RFC0841 - Page 51
      4.2.3  Property-List


           A  Property  is  an attribute being associated with, but not
      essential  to  the  interpretation  of,  a  data  element.    The
      properties currently defined by this message format specification
      are  Printing-Name  and  Comment.  A Property-List component of a
      data element is represented by a Property-List data element  that
      in turn contains Property data elements.

           A data element contains at most one Property-List.  The most
      significant  bit  in  the  identifier  octet  of the data element
      indicates whether a Property-List is present.


      4.2.4  Data Element Contents


           The Data Element Contents component of a data element is the
      actual data or information represented by a data element.    (The
      other  components  provide  the information necessary to identify
      and interpret the Data Element Contents.)

           In a primitive data element, the Data Element Contents is  a
      series  of  octets  interpreted according to the identifier octet
      and any qualifier.

           In a constructor data element, the Data Element Contents  is
      a  series  of data elements.  When the Length Code component of a
      constructor data element is "indefinite," the last  data  element
      in the constructor's Data Element Contents is End-of-Constructor.

           The  length  of the Data Element Contents (in octets) is the
      difference between the value of the Length Code and  the  sum  of
      the following:


        o  the  length  of  the Qualifier component (depends on the
           data element)

        o  the length of the Property-List component.



      4.3  Data Element Syntax


           This message  format  specification  defines  nineteen  (19)
      different data elements.  Section 4.3.1 defines the encoding form
      for  data  elements  in  general  and  the  syntax  for each data
      element.  Section  4.3.2  describes  the  use  of  specific  data
ToP   noToC   RFC0841 - Page 52
      elements  as  part  of  the Data Element Contents of a Field data
      element.  A summary of the syntactic form appears in Appendix  F;
      summaries of the data element syntax appear in Appendix G.


      4.3.1  Data elements


           This  section  presents  the  general syntactic form for all
      data elements defined by this message  format  specification  and
      the detailed syntax for each data element.  The data elements are
      presented  by  syntactic  class: primitive data elements (Section
      4.3.1.1), constructors (Section 4.3.1.2), and data elements which
      can be either (Section 4.3.1.3).

           For convenience, the following terminology is used  in  this
      section.


                  Term            Meaning

              Primitive       a Primitive Data Element

              Constructor     a Constructor Data Element

              Element         any Data Element


           The  syntax  of  each  Element is presented in graphic form.
      The following conventions apply in the diagrams.  A single  octet
      is represented as follows.


          +--------+
          |        |
          +--------+


           Components that vary in length are represented as follows.


          +---//---+
          |        |
          +---//---+


           Each  Element  has  up to five components:  an Identifier, a
      Length Code, a Qualifier, a Property-List, and the  Data  Element
      Contents.

               In the diagrams, the contents of the identifier octet is
ToP   noToC   RFC0841 - Page 53
      shown  as  a "P" followed by an identifier represented in binary.
      (See Figure 4.)

      A length code is always represented in the following manner:


          +---//---+
          |Lxxxxxxx|
          +---//---+


      A qualifier is always represented in the following manner:


          +---//---+
          |Qxxxxxxx|
          +---//---+


      A Property-List (if  present)  always  immediately  precedes  any
      occurrence of Data Element Contents.

      The  Data  Element  Contents  appears  in  diagrams as one of the
      following:


        o  "element(s)", which may be any data element(s)

        o  "anything," which is undefined and  may  be  any  combi-
           nation of bits

        o  a specific data element

        o  the  interpretation to be applied to the bits within the
           octets that constitute the element  (such  as  ASCII  or
           Integer)


           Two  data  elements have been reserved for special purposes.
      The Extension data  element  is  provided  to  allow  for  future
      expansion of the possible data elements.  The Vendor-Defined data
      element  allows  CBMS  vendors to define their own data elements.
      Vendor-Defined data elements are not  guaranteed  to  be  unique,
      since  two  implementations  could define different data elements
      using the same identifier.  Vendor-Defined data  elements  should
      be used and interpreted by prior agreement.

           In  the  following  sections, each element is presented with
      its name, compliance  classification  (BASIC  or  OPTIONAL),  its
      identifier   (both   in   hexadecimal  and  in  octal),  a  brief
      description of its use, and a graphic representation.  Each  data
      element description has the following form.
ToP   noToC   RFC0841 - Page 54
      -----------------------------------------------------------------


      Data Element             (Compliance)   identifier   identifier
          Name                 ( Category )    octet         octet 
                                                    16            8

                     Description of the syntax of the data element.



                 +---//---+
                 |        |     Diagram representing data element
                 +---//---+






      -----------------------------------------------------------------


      4.3.1.1  Primitives

           The   data   elements   in  this  section  are  arranged  in
      alphabetical order by name.  (Appendix C presents the identifiers
      in numeric order.)

      ASCII-String             (BASIC)        02        002 
                                                16         8
                   This  data  element  contains  a  series  of   ASCII
                characters [NatB-80], each character right-justified in
                one  octet.    For  7-bit  ASCII  characters,  the most
                significant bit of each octet must be 0.

           Note: The ASCII code  table  can  be  extended  through
                standardized  techniques [NatB-75]  to  introduce addi-
                tional 7-bit or 8-bit  characters  or  additional  code
                tables.


                 +--------+---//---+----//-----+
                 |P0000010|Lxxxxxxx|ASCII chars|
                 +--------+---//---+----//-----+
ToP   noToC   RFC0841 - Page 55
      Bit-String               (OPTIONAL)     43        103 
                                                16         8
                This  data  element contains a series of bits.  It uses
                the Qualifier data  element  component  to  record  the
                number  of  bits  of  padding (as an eight bit unsigned
                integer) needed to fill the final  octet  of  the  Data
                Element  Contents  to  an  even  octet boundary.  These
                padding bits have no meaning and occur in the low order
                bits of the final octet.   The  valid  values  for  the
                Qualifier  component  are  0  through 7.  The number of
                bits in the Data Element Contents  is  calculated  from
                the following formula.


                8   *   number of octets   -   value of
                        in the Data            Qualifier component
                        Element Contents


                 +--------+---//---+---//---+---//---+
                 |P1000011|Lxxxxxxx|Qxxxxxxx|  bits  |
                 +--------+---//---+---//---+---//---+

      Boolean                  (OPTIONAL)     08        010 
                                                16         8
                This  data  element  contains  one octet whose value is
                either true or false.  False is represented by all bits
                being 0; true  is  represented  by  all  bits  being  1
                (although  any  non-zero value should be interpreted as
                true).


                 +--------+---//---+--------+
                 |P0001000|Lxxxxxxx| T or F |
                 +--------+---//---+--------+

      End-of-Constructor       (BASIC)        01        001 
                                                16         8
                This data element terminates the Data Element  Contents
                in  a  constructor  data  element  that  has indefinite
                length.  This data element has no  Contents  component.
                (Use of this element is described in Section 4.2.2.1.)


                 +--------+---//---+
                 |P0000001|Lxxxxxxx|
                 +--------+---//---+
ToP   noToC   RFC0841 - Page 56
      Integer                  (OPTIONAL)     20        040 
                                                16         8
                This  data element contains a 2's complement integer of
                variable  length,  high  order  octet  first.    It  is
                recommended  that the data element contents be either 2
                or 4 octets long whenever possible.


                 +--------+---//---+---//---+
                 |P0100000|Lxxxxxxx| Integer|
                 +--------+---//---+---//---+

      No-Op                    (OPTIONAL)     00        000 
                                                16         8
                This data element does nothing.  No-Op is used whenever
                it is necessary to include a data  element  that  means
                "no operation."  It is a short placeholder.


                 +--------+---//---+
                 |P0000000|Lxxxxxxx|
                 +--------+---//---+

      Padding                  (OPTIONAL)     21        041 
                                                16         8
                This data element is used to fill any number of octets.
                The  contents  of  a  Padding element are undefined and
                convey no information.


                 +--------+---//---+---//---+
                 |P0100001|Lxxxxxxx|anything|
                 +--------+---//---+---//---+


      4.3.1.2  Constructors

           The data elements in this section  are  arranged  in  alpha-
      betical order.
ToP   noToC   RFC0841 - Page 57
      Compressed               (OPTIONAL)     46        106 
                                                16         8
                This  data  element  must  contain  a  Bit-String  data
                element.  It is used to represent  any  data  that  has
                been   compressed;   it   may   be  used  wherever  its
                uncompressed contents may appear.    A  Qualifier  data
                component  appears  in each Compressed data element; it
                contains a  compression identifier  (CID)  to  identify
                the  compression  algorithm used.  (See Section 4.3.5.)
                The Data Element Contents contains the product  of  the
                compression process.


                 +--------+---//---+---//---+--------//--------+
                 |P1000110|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
                 +--------+---//---+---//---+--------//--------+


      Date                     (BASIC)        28        050 
                                                16         8
                This   data   element  contains  an  ASCII-String  data
                element, which is a representation of a date  and  time
                formatted   in   accordance   with   PUBS  4 [NatB-68],
                58 [NatB-79a] and 59 [NatB-79b].  The use of  time  and
                time  zone is optional.  It is recommended that numeric
                offsets be used  to  indicate  time  zone  rather  than
                alphabetic abbreviations.


                 +--------+---//---+------//------+
                 |P0101000|Lxxxxxxx| ASCII-String |
                 +--------+---//---+------//------+


      Encrypted                (OPTIONAL)     47        107 
                                                16         8
                This  data  element  must  contain a Bit-String.  It is
                used to represent any data that has been encrypted;  it
                may  be  used  wherever  its  unencrypted  contents may
                appear.  A Qualifier data  component  appears  in  each
                Encrypted  data  element;  it  contains  an  encryption
                identifier (EID) identifying the  encryption  algorithm
                used.   The Data Element Contents is the product of the
                encryption process.


                 +--------+---//---+---//---+--------//--------+
                 |P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
                 +--------+---//---+---//---+--------//--------+
ToP   noToC   RFC0841 - Page 58
      Field                    (BASIC)        4C        114 
                                                16         8
                This   data  element  uses  a  Qualifier  data  element
                component.  The Qualifier component  contains  a  Field
                Identifier  (FID)  indicating  which  specific field is
                being represented.


                 +--------+---//---+---//---+---//---+
                 |P1001100|Lxxxxxxx|Qxxxxxxx|elements|
                 +--------+---//---+---//---+---//---+

      Message                  (BASIC)        4D        115 
                                                16         8
                This data element may contain  Field  or  Message  data
                elements.    Its Qualifier component contains a Message
                type (MID) indicating the type of the  message.    (The
                MID is completely different from the message identifier
                in the Message-ID field and should not be confused with
                it.)


                 +--------+---//---+---//---+
                 |P1001101|Lxxxxxxx|Qxxxxxxx|
                 +--------+---//---+---//---+

                 +--------//---------//---------//---------//--------+
                 | Field, Message, Encrypted, or Compressed Elements |
                 +--------//---------//---------//---------//--------+

      Property-List            (OPTIONAL)     24        044 
                                                16         8
                This  data  element  contains a series of Property data
                elements to be associated with another data element.


                 +--------+---//---+-------//--------+
                 |P0100100|Lxxxxxxx|Property Elements|
                 +--------+---//---+-------//--------+

      Property                 (OPTIONAL)     45        105 
                                                16         8
                This  data  element  uses  a  Qualifier  data   element
                component.       The   Qualifier   component   contains
                a  Property-Identifier (PID) to indicate which specific
                property is being represented.


                 +--------+---//---+---//---+---//---+
                 |P1000101|Lxxxxxxx|Qxxxxxxx|elements|
                 +--------+---//---+---//---+---//---+
ToP   noToC   RFC0841 - Page 59
      Sequence                 (OPTIONAL)     0A        012 
                                                16         8
                This data element contains any series of data elements.
                Sequence  differs  from  Set  in that the data elements
                making up the Data Element Contents must be  considered
                as  an  ordered  sequence  (according to their order of
                appearance in the sequence.)


                 +--------+---//---+---//---+
                 |P0001010|Lxxxxxxx|elements|
                 +--------+---//---+---//---+

      Set                      (OPTIONAL)     0B        013 
                                                16         8
                This data element contains any series of data  elements
                with  no  ordering  of the elements implied.  (Sequence
                provides  an  ordered  series.)    Although  the   data
                elements   contained   in   a   Set   must   be  stored
                sequentially, the order in which they are stored is not
                defined and not processed.


                 +--------+---//---+---//---+
                 |P0001011|Lxxxxxxx|elements|
                 +--------+---//---+---//---+

      Unique-ID                (OPTIONAL)     09        011 
                                                16         8
                This data element is a unique identifier.  It need  not
                be human-readable.  The Data Element Contents may be an
                ASCII-String, a Bit-String, or an Integer.


                 +--------+---//---+---//---+
                 |P0001001|Lxxxxxxx| element|
                 +--------+---//---+---//---+


      4.3.1.3  Data Elements that Extend this Specification

           There  are  two  data  elements that are used to extend this
      specification.  They can be classified  as  either  primitive  or
      constructor data elements, depending on the extension.
ToP   noToC   RFC0841 - Page 60
      Extension                (OPTIONAL)     7E        176 
                                                16         8
                This  data  element  is  used  to  extend the number of
                available  data  elements  beyond  the  128  that   are
                possible   using  a  7-bit  identifier.    A  Qualifier
                component extends the encoding space  for  identifiers.
                (Extension and Vendor-Defined have the same syntax.)


                 +--------+---//---+---//---+---//---+
                 |P1111110|Lxxxxxxx|Qxxxxxxx|Anything|
                 +--------+---//---+---//---+---//---+

      Vendor-Defined           (OPTIONAL)     7F        177 
                                                16         8
                This  data  element  is  used  to represent vendor- and
                user-defined data  elements.    A  Qualifier  component
                extends  the  encoding  space  for  identifiers.    The
                Qualifier component is  not  guaranteed  to  be  unique
                among all interconnected systems.  This data element is
                interpreted   according   to  prior  agreement  between
                systems.  (Extension and Vendor-Defined  data  elements
                have the same syntax.)


                 +--------+---//---+---//---+---//---+
                 |P1111111|Lxxxxxxx|Qxxxxxxx|Anything|
                 +--------+---//---+---//---+---//---+


      4.3.2  Using data elements within message fields


           The Data Element Contents of a particular field in a message
      must  contain  at  least  one  data  element.   The types of data
      elements that can appear in the Data Element Contents of a  field
      are restricted according to what kind of field it is.  Appendix A
      (the  master  reference  appendix  for fields) defines which data
      elements are valid as the Contents for each of the fields.

           Some fields have  a  Data  Element  Contents  that  contains
      "originators"  or  "recipients."   No data element represents the
      identities of originators or recipients (because that encoding is
      not within the  scope  of  this  message  format  specification.)
      These  descriptions  simply  list  "originators" or "recipients",
      implying no restrictions on how the identifiers  for  originators
      or recipients are represented.
ToP   noToC   RFC0841 - Page 61
      4.3.3  Properties and associated elements


           This message format specification defines two properties.

      Comment                                 01        001 
                                                16         8
                This  property may contain any series of data elements;
                it most commonly contains one or more ASCII-Strings.

      Printing-Name                           02        002 
                                                16         8
                This property contains one ASCII-String.  In this case,
                the ASCII-String may contain only  the  printing  ASCII
                characters plus the "space" character.


      4.3.4  Encryption identifiers


           This  message  format  specification  defines two encryption
      identification codes.

      Unspecified                             00        000 
                                                16         8
                Use of  this  encryption  identifier  as  part  of  the
                Encrypted  data  element  indicates that the encryption
                method being used was not specified  for  inclusion  as
                part of the data element.

      FIPS-Standard                           01        001 
                                                16         8
                Use  of  this  encryption  identifier  as  part  of the
                Encrypted  data  element  indicates  that  the  Federal
                Information   Processing   Standard   method  for  data
                encryption was [NatB-77].


      4.3.5  Compression identifiers


           This message format specification  defines  one  compression
      identification code for use with the Compressed data element.

      Unspecified                             00        000 
                                                16         8
                Use  of  this  compression  identifier  as  part of the
                Compressed data element indicates that the  compression
                method  being  used  was not specified for inclusion as
                part of the data element.
ToP   noToC   RFC0841 - Page 62
      4.3.6  Message types


           This message format specification defines message type (MID)
      codes  for use in classifying the type of a message.  The message
      type could  be  confused  with  the  message  identifier  in  the
      Message-Id field; they are completely distinct concepts.

      FIPS-Standard                           01        01 
                                                16        8
                This  message  type  marks  messages  defined  by  this
                message format specification.
ToP   noToC   RFC0841 - Page 63
                            SUMMARY OF APPENDIXES




      Appendix A  Defines  the  fields  in  the message format specifi-
                  cation.  This alphabetical appendix is for  reference
                  use   by   implementors.      It   contains  semantic
                  definitions of fields from  Section  3.1.    It  also
                  defines  Field  Identifier values and specifies which
                  data elements are valid as the Contents for  each  of
                  the fields.

      Appendix B  Defines  the  data  elements  in  the  message format
                  specification.  This alphabetically ordered  appendix
                  is  for  reference  use  by implementors.  It consol-
                  idates information from Section 4.3.

      Appendix C  Provides a reference table listing the data  elements
                  in numerical order by their identifier octets.

      Appendix D  Provides a reference table summarizing the components
                  of messages according to whether they are required or
                  optional for CBMSs implementing the specification.

      Appendix E  Provides  a  reference  table  organizing the message
                  components according to the functional class  of  the
                  components.

      Appendix F  Provides   an  overview  of  the  syntactic  elements
                  defined by this message format specification.

      Appendix G  Summarizes syntactic elements  according  to  whether
                  they are required or optional for a CBMS implementing
                  the message format specification.

      Appendix H  Examples  of  each syntactic element displaying their
                  syntax and describing their associated semantics.
ToP   noToC   RFC0841 - Page 64
                                 APPENDIX A
                  FIELDS -- IMPLEMENTORS' MASTER REFERENCE




           This  appendix  defines  all  of  the  fields in the message
      format specification for  reference  use  by  implementors.    It
      contains  semantics  definitions  of fields from Section 3.1.  It
      also defines Field Identifier values and which data elements  are
      valid  as  the  Contents  for  each  of  the  fields.   The field
      definitions appear alphabetically.

           Each field in the list has the following form:


      ------------------------------------------------------------


      Field Name               Compliance   identifier  identifier
                                              value       value 
                                                   16          8

                   Description of the field semantics.   Names  of
              data  elements  that  are  valid in the Data Element
              Contents of this kind of field.



      ------------------------------------------------------------


      Attachments              OPTIONAL       08        010 
                                                16         8
                This field  contains  additional  data  accompanying  a
                message.    It  is similar in intent to enclosures in a
                conventional mail system.  Contents of this  field  are
                unrestricted.

      Author                   OPTIONAL       0C        014 
                                                16         8
                This  field  identifies the individual(s) who wrote the
                primary contents of the message.   Use  of  the  Author
                field  is  discouraged  when the contents of the Author
                field and the From field would be completely redundant.
                This field contains one or more originator identities.
ToP   noToC   RFC0841 - Page 65
      Bcc                      OPTIONAL       0D        015 
                                                16         8
                This  field  identifies  additional  recipients  for  a
                message (a "blind carbon copies list").   The  contents
                of  this  field are not to be included in copies of the
                message sent to the primary and  secondary  recipients.
                See  section 3.2.1 for further discussion of the use of
                blind carbon copies lists. This field contains  one  or
                more recipient identities.

      Cc                       BASIC          06        006 
                                                16         8
                This   field  identifies  secondary  recipients  for  a
                message (a "carbon copies" list).  This field  contains
                one or more recipient identities.

      Circulate-Next           OPTIONAL       0E        016 
                                                16         8
                This field is used in conjunction with the Circulate-To
                field.    (See Section 3.2.6.1 for further discussion.)
                It identifies all recipients in a circulation list  who
                have not yet received the message.  This field contains
                one or more recipient identities.

      Circulate-To             OPTIONAL       0F        017 
                                                16         8
                This  field  identifies  recipients  for  a  circulated
                message.  (See Section 3.2.6.1 for further discussion.)
                It is  used  in  conjunction  with  the  Circulate-Next
                field.    This  field  contains  one  or more recipient
                identities.

      Comments                 OPTIONAL       10        020 
                                                16         8
                This field permits adding  comments  onto  the  message
                without   disturbing   the  original  contents  of  the
                message.  While the Comments field will usually contain
                one or more ASCII-Strings, there are no restrictions on
                its contents.

      Date                     OPTIONAL       11        021 
                                                16         8
                This  field  contains  a  date   that   the   message's
                originator  wishes  to  associate  with a message.  The
                Date field is to the Posted-Date field as the date on a
                letter is to the postmark added  by  the  post  office.
                This field contains one Date.
ToP   noToC   RFC0841 - Page 66
      End-Date                 OPTIONAL       12        022 
                                                16         8
                This  field  contains the date on which a message loses
                effect.    (See  also   Section   3.2.5   for   further
                discussion.)  This field contains one Date.

      From                     REQUIRED       01        001 
                                                16         8
                This  field  contains  the  identity of the originators
                taking formal responsibility for  this  message.    The
                contents  of  the  From field is to be used for replies
                when no Reply-to field appears  in  a  message.    This
                field contains one or more originator identities.

      In-Reply-To              OPTIONAL       13        023 
                                                16         8
                This  field designates previous correspondence to which
                this message is a reply.  The usual  contents  of  this
                field  would be the contents of the Message-ID field of
                the message(s) being replied to.  This  field  contains
                one or more Unique-IDs or ASCII-Strings.

      Keywords                 OPTIONAL       14        024 
                                                16         8
                This  field  contains  keywords  or  phrases for use in
                retrieving a message.  This field contains one or  more
                ASCII-Strings.   (Each keyword or phrase is represented
                by a separate ASCII-String.)

      Message-Class            OPTIONAL       15        025 
                                                16         8
                This field indicates the purpose of  a  message.    For
                example,  it  might  contain values indicating that the
                message is a memorandum or a  data-base  entry.    This
                field contains one data element, an ASCII-String.

      Message-ID               OPTIONAL       16        026 
                                                16         8
                This  field contains a unique identifier for a message.
                This identifier is intended for machine generation  and
                processing.    Further  definition  appears  in Section
                3.2.4.1.  Only one Message-ID field is permitted  in  a
                message.    This  field  contains  one  data element, a
                Unique-ID.

      Obsoletes                OPTIONAL       26        046 
                                                16         8
                This field identifies one or more  messages  that  this
                one  supplants.    This  field  contains  at  least one
                Unique-ID and may contain more than one.
ToP   noToC   RFC0841 - Page 67
      Originator-Serial-Number OPTIONAL       17        027 
                                                16         8
                This field contains one or more serial numbers assigned
                by  the  message's originator.  (Messages with multiple
                recipients should  all  have  the  same  value  in  the
                Originator-Serial-Number  field.    This field contains
                one or more ASCII-Strings.  (One ASCII-String  is  used
                for each serial number.)

      Posted-Date              REQUIRED       02        002 
                                                16         8
                This  field  contains  the  posting  date, which is the
                point in time  when  the  message  passes  through  the
                posting  slot into a message transfer system.  Only one
                Posted-Date field is permitted  in  a  message.    This
                field contains one Date.

      Precedence               OPTIONAL       18        030 
                                                16         8
                Ordinarily, message precedence or priority is a service
                request  to  a  message  transfer  system.    A message
                originator, however, can include precedence information
                in a message.  This field indicates the  precedence  at
                which  the  message  was  posted.    One  example  of a
                precedence  scheme  is  the  US   Military   categories
                "ROUTINE",  "PRIORITY",  "IMMEDIATE", "FLASH OVERRIDE",
                and  "EMERGENCY  COMMAND  PRECEDENCE".     This   field
                contains one ASCII-String.

      Received-Date            OPTIONAL       19        031 
                                                16         8
                This  field  is  also  called Delivery date.  It may be
                added to a message by the recipient's message receiving
                program.   It  indicates  when  the  message  left  the
                delivery  system  and  entered  the recipient's message
                processing domain.  This field contains one Date.

      Received-From            OPTIONAL       1A        032 
                                                16         8
                This field  contains  a  record  of  a  message's  path
                through    a    message    transfer    system.      The
                recipient's message receiving  program  may  store  any
                such   information  that  it  obtains  from  a  message
                transfer system in this field.  The  contents  of  this
                field are unrestricted.
ToP   noToC   RFC0841 - Page 68
      References               OPTIONAL       20        040 
                                                16         8
                This  field  identifies  other correspondence that this
                message  references.    If  the  other   correspondence
                contains  a  Message-ID  field,  the  contents  of  the
                References field must be the message identifier.   This
                field contains one or more Unique-IDs or ASCII-Strings.

      Reissue-Type             OPTIONAL       25        045 
                                                16         8
                This   field   is  used  in  conjunction  with  message
                encapsulating  (see  Section  3.2.2)  to  differentiate
                between messages being assigned or redistributed.  This
                field  contains  one  data  element,  usually an ASCII-
                String.

      Reply-To                 BASIC          03        003 
                                                16         8
                This field identifies any recipients for replies to the
                message.  This field contains  one  or  more  recipient
                identities.

      Sender                   OPTIONAL       22        042 
                                                16         8
                This  field  identifies the agent who sent the message.
                It is intended either for when the sender  is  not  the
                originator  responsible  for the message or to indicate
                who among a group of originators  responsible  for  the
                message  actually  sent it.  Use of the Sender field is
                discouraged when the contents of the Sender  field  and
                From  field  would  be  completely redundant.  Only one
                Sender field is permitted in a  message.    This  field
                contains one originator identity.

      Start-Date               OPTIONAL       23        043 
                                                16         8
                This  field  contains the date on which a message takes
                effect.  (See Section 3.2.5  for  further  discussion.)
                This field contains one Date.

      Subject                  BASIC          07        007 
                                                16         8
                This field contains whatever information the originator
                provided  to  summarize  or  indicate the nature of the
                message.   This  field  contains  one  or  more  ASCII-
                Strings.

      Text                     BASIC          04        004 
                                                16         8
                This field contains the primary content of the message.
                Contents of this field are unrestricted.
ToP   noToC   RFC0841 - Page 69
      To                       REQUIRED       05        005 
                                                16         8
                This field identifies primary recipients for a message.
                This field contains one or more recipient identities.

      Warning-Date             OPTIONAL       24        044 
                                                16         8
                This  field is used either alone or in conjunction with
                an End-Date field.  It  contains  one  or  more  dates.
                These  dates  could  be  used  by  a message processing
                program as warnings of an impending end-date  or  other
                event.    (See  Section  3.2.5 for further discussion.)
                This field contains one or more Dates.


(next page on part 3)

Next Section