Re: Mail and Resent-fields (was: Re: HELP!)

Dave Crocker <dcrocker@mordor.stanford.edu> Mon, 09 August 1993 12:24 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01512; 9 Aug 93 8:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id bs00886; 9 Aug 93 8:24 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa20656; 8 Aug 93 12:16 EDT
Received: from Mordor.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-12) id <AA06196>; Sun, 8 Aug 1993 09:05:19 -0700
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA01676; Sun, 8 Aug 93 09:05:07 -0700
Message-Id: <9308081605.AA01676@Mordor.Stanford.EDU>
To: John C Klensin <KLENSIN@infoods.mit.edu>
Cc: braden@isi.edu, ietf-hosts@isi.edu
Subject: Re: Mail and Resent-fields (was: Re: HELP!)
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Sat, 07 Aug 93 19:40:52 -0400. <744766852.196433.KLENSIN@INFOODS.UNU.EDU>
Date: Sun, 08 Aug 1993 09:05:06 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker@mordor.stanford.edu>
X-Mts: smtp

Bob, et al,

Long ago, off in a distant planet, email had a flat set of headers and
one (really?  only one?) flat body.  The concept of deep structure to
either was beyond the willingness, ability, appreciation, ... of The
Community.  (As I recall, it did exist at the time, but certainly not
in Common Practise.)

I haven't a clue who suggested (or was already doing) Resend when
RFC822 was written.  It might even have been in RFC733, but I don't
remember.  But it had/has a clear function in human communication,
distinct from Forward.  Resend expands the scope of discussants.  It
lets the new discussants participate with the original folks.  Forward
creates a barrier.  In effect, if merely informs the new folk about a
separate activity.  Hence, the new communication is between the
forwarding person and the new recipient(s).  With Resend, the
forwarding person is acting as an agent of the original set of people.

We could debate nomenclature, but the communications distinction is
clear.

Unfortunately, most of us often fail to make the distinction and one
certainly could argue that the human factors of much email softwear
doesn't help.

One could argue that the new world of Mime gives us an opportunity to
re-think some of the approaches we have taken to encoding assorted
human communications schemes into our email.  I, for one, believe we
should consider the richer world of global addressing, beyond email.
RFC822 seems to be rich enough to handle any of the email addressing
requirements folks are coming up with (and I think we can comfortably
assert that X.400 tests that belief), but Fax and Postal (especially
postal) push things to an unreasonable limit, I believe.  (The current
remote printing experiment shows that core fax addressing works fine.
But my discussions with some fax folks, including at ISI, suggest that
there is Handling information that can't be included.  See my I-D on
Personal Contact Information (PCI) for the list.

In particular, RFC822 does not allow 2-dimensinal addresses, as needed
for Postal, and does not allow attachment of per-recipient Handling
information.

Bob's note raises additional questions about the need to think through
and re-do some of the user-to-user protocols (what X.400 calls P2) more
carefully.

My guess is that this has to be done in an upward compatible fashion,
however, which will certainly limit our choices.

Dave