[Top] [All Lists]

Re: comments on draft-crocker-email-arch-01

2005-01-06 08:00:21

On Thu December 30 2004 18:50, Tony Finch wrote:

Analogies between the software world and the real world are usually
not perfect.

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.

If it is necessary to distinguish SMTP MAIL FROM,
RCPT TO, etc. from DATA, I would suggest that referring
to the former as "instructions" or as "routing information"
and the latter as simply "data" would be such an
appropriate distinction.  Or one could refer to them
as comprising part of the "envelope", provided one does
not exclude other types of envelope information.
The draft under discussion is about the overall architecture
rather than a nitty-gritty detail peculiar to SMTP
protocol.  From an architectural point of view it is
important to distinguish the end-to-end, author/sender-to-
recipient information from ancillary notations (to
specify who/what may set/read which portions of a message),

I agree that this is necessary. However you cannot use the term "envelope"
for the transport-related header fields because "envelope" already means
something else in the context of Internet email. If you want to subdivide
the message header, please choose new terms to describe its parts.

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.

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.

There may in fact be another reason to choose a term other
than "envelope" (or at least to clearly define how that
term is used in the document under discussion); 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.

This is an important architectural misfeature of Internet email. It is
best to talk about Internet email as it is, and not to talk about it by
shoehorning it into some idealization that doesn't apply in the real

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