ietf-smtp
[Top] [All Lists]

Re: Consensus call: draft-crocker-email-arch -- envelope vs. trace vs. ...?

2007-05-14 22:54:30



--On Monday, 14 May, 2007 22:22 -0700 Dave Crocker
<dcrocker(_at_)bbiw(_dot_)net> wrote:



Folks,

I'm coming to believe that any attempt to have the word
"envelope" refer to more than the SMTP Envelope is doomed.
Anyone feeling otherwise is strongly encouraged to speak up.

Concur.

That leaves the choice of terms for this non-SMTP handling
information.

I think that "Extended Envelope" and "Trace Information" are
both entirely reasonable.  On reflection, I'm inclined towards
the latter, but would like folks to comment.

Here's my logic:  A term that differs from another core term
only by having an added qualify probably invites
misunderstanding, even if we say the "SMTP Envelope" is a
subset of "Extended Envelope".

"Trace Information" has two advantages:  1) it is an entirely
different term, and b) it accurately describes the core set of
information... Or does it?  Is there anything that one would
include in this set, other than Received and Return-Path?
Does this additional information make the term "trace"
inappropriate?

It has a third advantage.  One of the things that I've found a
little scary about this architectural description effort is that
is introduces terminology and concepts that do not appear in the
core email specifications.  For the reader, untangling those
differences may lead to more, rather than less, confusion.
While some terminology or conceptual differences may be
unavoidable, I think they should be avoided where possible.  And
"trace information" is exactly the term used to describe that
material in 2821, whose prose even allows it to be extended to
include additional information provided as part of the transport
process.

If anyone wants a term other than trace information, please
speak up.

     john