The uniqueness of the message identifier is guaranteed by  the
        host  which  generates  it.  This identifier is intended to be
        machine readable and not necessarily meaningful to humans.   A
        message  identifier pertains to exactly one instantiation of a
        particular message; subsequent revisions to the message should


     August 13, 1982              - 23 -                      RFC #822
 

 
     Standard for ARPA Internet Text Messages


        each receive new message identifiers.

     4.6.2.  IN-REPLY-TO

             The contents of this field identify  previous  correspon-
        dence  which this message answers.  Note that if message iden-
        tifiers are used in this  field,  they  must  use  the  msg-id
        specification format.

     4.6.3.  REFERENCES

             The contents of this field identify other  correspondence
        which  this message references.  Note that if message identif-
        iers are used, they must use the msg-id specification format.

     4.6.4.  KEYWORDS

             This field contains keywords  or  phrases,  separated  by
        commas.

     4.7.  OTHER FIELDS

     4.7.1.  SUBJECT

             This is intended to provide a summary,  or  indicate  the
        nature, of the message.

     4.7.2.  COMMENTS

             Permits adding text comments  onto  the  message  without
        disturbing the contents of the message's body.

     4.7.3.  ENCRYPTED

             Sometimes,  data  encryption  is  used  to  increase  the
        privacy  of  message  contents.   If the body of a message has
        been encrypted, to keep its contents private, the  "Encrypted"
        field  can be used to note the fact and to indicate the nature
        of the encryption.  The first  parameter  indicates  the
        software  used  to  encrypt the body, and the second, optional
         is intended to  aid  the  recipient  in  selecting  the
        proper  decryption  key.   This  code word may be viewed as an
        index to a table of keys held by the recipient.

        Note:  Unfortunately, headers must contain envelope,  as  well
               as  contents,  information.  Consequently, it is neces-
               sary that they remain unencrypted, so that  mail  tran-
               sport   services   may   access   them.   Since  names,
               addresses, and "Subject"  field  contents  may  contain


     August 13, 1982              - 24 -                      RFC #822
 

 
     Standard for ARPA Internet Text Messages


               sensitive  information,  this  requirement limits total
               message privacy.

             Names of encryption software are registered with the Net-
        work  Information Center, SRI International, Menlo Park, Cali-
        fornia.

     4.7.4.  EXTENSION-FIELD

             A limited number of common fields have  been  defined  in
        this  document.   As  network mail requirements dictate, addi-
        tional fields may be standardized.   To  provide  user-defined
        fields  with  a  measure  of  safety,  in name selection, such
        extension-fields will never have names  that  begin  with  the
        string "X-".

             Names of Extension-fields are registered with the Network
        Information Center, SRI International, Menlo Park, California.

     4.7.5.  USER-DEFINED-FIELD

             Individual users of network mail are free to  define  and
        use  additional  header  fields.   Such fields must have names
        which are not already used in the current specification or  in
        any definitions of extension-fields, and the overall syntax of
        these user-defined-fields must conform to this specification's
        rules   for   delimiting  and  folding  fields.   Due  to  the
        extension-field  publishing  process,  the  name  of  a  user-