AC> Instead of designing a new header, why not remove the header
AC> completely and replace it with a set of kludge lines?

RS> The main argument against doing that is that its a lot quicker
RS> with decent code to process the fixed header stuff for the fields
RS> that are appropriate in a fixed header. Basically those that are
RS> used in almost every message.

AC> The "mandatory" fields.  Now, what is required, and what is not?

No, not really mandatory fields, fields which are in fact there on
almost all messages, even if the message is still deliverable without
them. The time and date fields area good example where they are almost
always there, not absolutely essential in the sense that you have to
bin a message that doesnt have them. Since they are in almost all
messages it makes more sense speed wise to have them in a fixed header.

The only thing you need to be a bit careful about is that you dont
include things in a fixed header that may pass out of common use
over time coz that then wastes space. OTOH thats a bit theoretical
with all mail moving compressed, so there isnt any need to be ultra
safe there.

RS> Kludge lines are better for the stuff which is only used
RS> occasionally, optional fields like say the character set
RS> used in the message body and the variable length stuff
RS> where you may want repeated use of a particular one.

AC> If there is a need to design something that is to replace the
AC> existing system, I would prefer all fields to be optional.

Trouble is quite a few cant really be and still have a viable
deliverable message. So it makes sense to have the very commonly
seen fields in a fixed header for its more efficient processing.
But still have the optional fields for its convenient expandability
and for stuff which is only seen in a small percentage of messages.

AC> This might seem unusual, but could prove quite useful in my opinion.

It really doesnt have any particular advantage doing it like that
and has the processing speed disadvantage.

AC> I don't necessarily mean eliminating redunancy, either.

Yeah, thats a quite separate question.


The other thing thats important is a very robust delimiter between
messages so a mangled one can be recovered from very quickly and that only
results in a single message tossed into the problems bin and no others.

--- PQWK202