On Thu, 6 Jan 2005, Bruce Lilly wrote:
Perfection isn't necessarily the goal, but maintaining
the fundamental distinction between end-to-end sender
to recipient communication and added notation is a
valid consideration. Received fields, Return-Path,
Disposition-Notification-{to,Options} etc. are clearly
not part of the end-to-end sender-recipient communication;
they are analogous to markings made on the envelope
of physical mail, and it seems perfectly reasonable to
refer to them as (partially) comprising the "envelope"
of email.
Many header fields do not clearly fall into one of user-level or
transport-level - see my message
http://www.imc.org/ietf-smtp/mail-archive/msg01384.html
and Dave's response
http://www.imc.org/ietf-smtp/mail-archive/msg01385.html
I note that the current full Standard for SMTP (STD 10,
a.k.a. RFC 821) nowhere uses the term "envelope", and there
have been few if any relevant changes to the SMTP protocol and
its provisions for scribbling on message content since STD 10.
As I've already explained in some detail, the term "SMTP evelope" is
defined by RFC 1123 (STD 3). In the context of Internet email "envelope"
has been used in this sense consistently throught the 15 years since then.
It is too late to redefine the term now. See my message
http://www.imc.org/ietf-smtp/mail-archive/msg01398.html
If you have a specific suggestion other than "envelope" for
describing those parts of a message which are not part
of the end-to-end communication, please let's discuss it.
"transport-related header fields" and "user-related header fields".
IMAP uses the term for a specific structure which incorporates message
header information which is clearly part of the header and not analogous
to physical mail envelope, such as the RFC [2]822 Subject, From, and To
header fields.
As I've already explained, this is because that part of IMAP predates the
definition of the standard meaning of "envelope" in Internet email. Again,
see http://www.imc.org/ietf-smtp/mail-archive/msg01398.html
Agreed. In the real world, there are transfer protocols other
than SMTP. That includes past protocols (FTP, MTP) which may
be instructive in terms of architectural considerations, other
current but less popular open protocols (UUCP, EMSD), concurrent
but architecturally distinct protocols (POP variants, IMAP),
proprietary protocols used over the Internet (on top of IP
or via VPNs), protocols that interact with Internet email
protocols at gateways (X.400, etc.), and possible future
protocols.
Of these, only POP and IMAP are part of the Internet email architecture.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
MULL OF KINTYRE TO ARDNAMURCHAN POINT: SOUTHWEST 6 TO GALE 8, INCREASING
SEVERE GALE 9 FOR A TIME. RAIN OR SHOWERS. MODERATE OR GOOD, PERHAPS POOR IN
HEAVIER BURSTS OF RAIN. ROUGH OR VERY ROUGH, LOCALLY HIGH.