Folks,
It's turned into a cliche, to note the significance of John's and my agreeing.
However, what has turned that into a cliche in the last few years has been
IETF process issues.
Our agreeing on some aspect of a technical *solution* remains rare enough to
be non-existent.
In light of that, I'll note that anyone suggesting a term other than "trace
information" is going to have to put forward a pretty strong argument...
d/
John C Klensin wrote:
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.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net