ietf-smtp
[Top] [All Lists]

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

2004-12-23 15:13:49

Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
On Wed, 22 Dec 2004, Bruce Lilly wrote:

Yes.  I remarked on that a half-year ago on the mail-ng
list (http://www.imc.org/mail-ng/mail-archive/msg00715.html),
and the issue came up recently on the ietf-822 list
(http://www.imc.org/ietf-822/mail-archive/msg05290.html).

I agree that the 822 message header is uncomfortably stuck doing two jobs,
but I disagree that this implies that the term "envelope" should include
any header fields.

   Tony, like many of us, has acquired a habit of referring to the STMP
stuff that comes before the DATA command as "envelope" information.

   Dave's draft gives a quite different meaning to "envelope":
] 
] 5.1 Envelope
] 
] Information that is directly used or produced by the email transfer
] service is called the "envelope". It controls and  records handling
] activities by the transfer service. Internet mail has a fragmented
] framework for handling this "handling" information. The envelope exists
] partly in the transfer protocol SMTP [RFC2821] and partly in the message
] object [RFC2822].
] 
] Direct envelope addressing information, as well as optional transfer
] directives, are carried in-band by MTAs. All other envelope information,
] such as trace records, is carried within the content headers. Upon
] delivery, SMTP-level envelope information is typically encoded within
] additional content  headers, such as Return-Path and Received (From
] and For).

   I find Tony's usage far more comfortable -- in that I can actually
explain it to someone and hope to get the idea across. IMHO, Dave is too
hung up on parallels to postal mail, and is thinking "envelope information"
should mean anything which would normally be recorded on the envelope.
Personally, I'd prefer to reserve "envelope" for Tony's meaning, and coin
another term -- perhaps something akin to "routing information" for Dave's
meaning.

   Obviously, everone's mileage-may-vary...

   But I think there's a very good case for defining separate terms for
these two meanings.

--
John Leslie <john(_at_)jlc(_dot_)net>