Re: Resent- fields

On Sun January 16 2005 16:57, Philip Hazel wrote:

> it is impossible to distinguish
> between different sets of "resent-" header lines. For example, if you
> receive
> 
> resent-from: X
> resent-to: Y
> resent-date: Z
> resent-cc: Q
> resent-from: A
> resent-to: B
> 
> to which set do "date:" and "cc:" belong?

*If* the header fields have erroneously (i.e. in violation of
RFC 2822 section 3.6) been jumbled, one cannot tell. Under
normal conditions it is simple: the initial recipient will
have a Return-Path field, followed by one or more Received
fields, followed by other fields.  When resending, the
Resent- fields are prepended in a block (RFC 2822 section 3.6,
3.6.6, 3.6.7).  Likewise if that message is received and
subsequently resent.  I.e. each block of Resent- fields will
be separated from the others by one or more trace (Received
and Return-Path) fields.  Moreover, each block of Resent-
fields will include its own Resent-Date field (it is mandatory)
so to answer your question, one would simply group the fields
bottom-up (your example is malformed as it does not contain
as many Resent-Date fields as Resent-To and Resent-From
fields).

> Incidentally, one of these days we should perhaps bring the 
> specification's terminology in line with what everybody actually uses. 
> Pretty well everybody, when they write "header" mean a single header 
> line (as you seem to above).

No, "header" in the mail standards has a very clear meaning:
is is a group of fields separated from body content by an
empty line.  The same term has the same meaning in HTTP and
SIP protocols, though each of those protocols' transactions
begins with a "start line" which has no equivalent in the
mail protocols.  In a message, one has the message header
and may have zero or more MIME-part headers (some of the
MIME-part headers might contain no fields).  The term
"header" was first defined that way in RFC 561 more than
three decades ago and has been used that way consistently
in its successors through RFC 2822.  It is directly analogous
to the use of the term "header" in IP, TCP, etc. packets;
people who are not clueless regarding packet communications
do not refer to individual IP header (bit) fields as "headers".
We should expect no less of technical communication regarding
messaging protocols and formats.

> The RFC actually calls this a "header  
> field":

The term "field" was formalized in RFC 724, if not earlier
(RFC 680 is not online), more than a quarter century ago,
and has also been used consistently (as has "field body")
by its successors.

> I have been trying to 
> remember to use "header line" consistently, but the colloquial use of
> "header" is so prevalent that I think it's a losing battle

It is important to distinguish colloquial use from precise
terminology used in professional technical communication.
The primary purpose of technical standards is to ensure
interoperability, and that is best achieved by using
precise, well-defined terms. That is why we have RFC 2119
for example, which provides precise definitions of several
commonly used terms in IETF documents.

> I propose that next time there's a big revision, we should go with the 
> current actual usage, and find a new name for the collection of
> "headers".

The term for the collection of (message and MIME-part) headers
is in fact "headers".  The term for the collection of (message
and MIME-part) headers in a collection of messages is "headers".
The definitions have been in use consistently for so long that
an attempt to redefine them would be disastrous.  It would be
equivalent to saying something like "when I say 'white', I don't
really mean white, I mean black, and when I say 'black', I don't
really mean black, I mean 'red', and when I say 'red' I don't
really mean red, I mean white.  Such circumlocutions would only
cause confusion.  Instead we should continue to use the well-
defined terms "field body", "field", "header", and "headers" as
they have been used for decades, encourage the correct use of
those terms in technical communications, and actively discourage
incorrect use in technical communications.  Some education of
semi-technical people in the correct definitions and usage would
reduce confusion and may have a peripheral positive effect on
interoperability.  Your proposal, which is to replace precise,
well-defined terms with poorly-defined colloquialisms, would
have a negative effect on interoperability and on general
understanding of messages and messaging protocols.