ATTRIBUTE NAMES & CODES

	There are basically 2 different sorts of attributes
to consider: those which are "coded", and those which aren't.
Coded attributes are represented within the mailer by a
code of up to 9 bits; all others by a special code which
holds the attribute name, followed by its value.  NO processing
whatever should be performed by the mailer on an uncoded attribute,
other than simply passing it along, even if the attribute name
matches the P-name (see below) of a coded attribute.
	For every coded attribute there exists a unique "printout
name" or P-name.  However, there are several ways of representing
them on readin.  One class is completely internal to the mailer
and these attributes have NO readin representation at all;
there is no way to produce such a coded attribute by readin
means.  These are "internal" attributes.  For those
which can produce coded attributes, there are the following
ways:
	(1) Input Request (IRQ) file.  (e.g. a MAIL >)  The
existing standard mechanism uses names unique to IRQ readin
to produce various attributes as it sees fit, in an implementation-
independent fashion.  However, one can specify a particular
attribute and its value by means of the IRQ-name ATTRIB, which
is parsed just like an EQV entry (i.e. with LISP-like structure).
Normal IRQ reading does not resume until the list is completely
parsed, i.e. it is not necessary to use the <IRQ-name>;<cnt>
construct.  Thus, an entire message may be composed of a single
ATTRIB: with no other IRQ-names present.  The attrib names used
within an ATTRIB: are the same as those used for EQV readin, as
below:

	(2) ASCII Equivalence (EQV) file.  (e.g. NAMES >).
The format of this file is as described in the EQV-readin documentation,
i.e. LISP-style with a few special shortcuts.  The attribute
names used here are exactly the same as the "printout names",
so that an EQV-name = P-name.  However, this is NOT NECESSARY; it
merely saves the space and trouble of an extra name table. (this
may be changed later to extol virtues of similarity, and freeze it)
If an EQV-name does not correspond to any external P-name, it is
compared to a list of "known EQV-names" which are understood to
be attributes, but which are merely passed on into the
structure as uncoded attributes.  If not on this list, the name is
flagged as an error (the only reason for the list)
but read in anyway as an uncoded attribute.

	(3) Network Mail headers (NET).  These certainly
specify some attributes, but they do so in haphazard and by no means
syntactically valid fashion.  Thus, their parsing must be done with
caution, and no assumptions can be made about the reasonableness of
the sending program's choice of attribute names.  There is very
little chance that all such attributes will have the same name for
the same thing, or in the same format, thus these CANNOT be parsed
as simply as EQV-names.  Parsing of a NET header will produce
a list of uncoded attributes, but these will use a different
code from the "normal uncoded" attribute code (if you can follow
this).  Then it's up to the whim of the mailer whether to believe
in the given values, and duplicate the information into standard
coded/uncoded attribs.  The original "provisionary" attribs will
stay around for possible reference, though.

Problems:
	The main problem with attribute names/codes has to do with
creating new coded attributes.  If a new coded attribute is created,
then a new P-name is also created and a new EQV-name can be read in and codified.
This will screw things if an uncoded-attrib EQV-name already existed with that
P-name, unless mailer processing is done as before (i.e. simply
passes it along, rather than munging in some fashion (which is illegal for
uncoded attribs))
	The code values also must remain constant over time, particularly
over version changes, so that data in the files remains valid.  If
the code #'s were to be shuffled, obviously any file data using these
codes is instantly rendered obsolete, with no indication of the fact.
Fixing the values permanently is one solution, but perhaps a special
conversion routine will be necessary someday to convert from an old
to new regime.  Or perhaps the normal attrition & turnover 
of messages and data will suffice to remove all traces of an obsolete
code value, after which it can be re-used for something else.
(this same problem would happen with strings as attrib names, if the string names
were changed or removed)