Bill McQuillan wrote:
Perhaps someone knows what the "Founders" (of email) conceptual models were
for a "message" (memo?) For instance, although I obviously do not understand
the "original intent" behind the "group of mailboxes" construct, I have long
wondered why the following is not valid:
Internet mail grew out of the standalone mail system that was running on BBN's
Tenex system, which had a message appearance similar to what we see today. I
haven't talked with the folks who created the Tenex system, to ask about their
particular choice. However I suggested an interpretation of it's perspective in
RFC 733, which formally codified the model:
A general "memo" framework is used.
...
Such a framework severely constrains document tone and
appearance and is primarily useful for most intra-organization
communications and relatively structured inter-organization
communication. A more robust environment might allow for multi-
font, multi-color, multi-dimension encoding of information. A
less robust environment, as is present in most single-machine
message systems, would more severely constrain the ability to add
fields and the decision to include specific fields. In contrast
to paper-based communication, it is interesting to note that the
RECEIVER of a message can exercise an extraordinary amount of
control over the message's appearance.
The incremental revisions to the model that were done in RFC 733, RFC 822, RFC
2822 and RFC 5322 have tweaked things, such as with the group construct you cite
and, of course, with multi-media attachments (MIME). These enable a broader
range of uses. So I'm not sure the 'founders' intent is all that informative or
constraining, 35 years on. I think it is more helpful to note the disparity
between what styles of communication email *can* support and what kinds it
*does* support.
Specifically, the point of my message was to note that IMF (Internet Message
Format) is used for only a subset of the functions it could be used for and that
(probably) it could support with no change and that. In fact, it has features
intended to support those additional functions but which remain almost
completely unexercised after all this time.
What prompted my note was the observation that having stray bits of unexercised
protocol features hanging around invites divergent implementations, as follow-on
enhancements are made. The current situation with ADSP is merely a concrete example.
By "divergent" I mean "non-interoperable". So as logically compelling as the
potential for those unused bits of capability are, the fact that they remain
unused is demonstrably problematic, which leads to the questions of possibly
deprecating them, and how to do it.
From: ACME Chief Officers:
Alice <ceo(_at_)acme(_dot_)example(_dot_)com>,
Bob <coo(_at_)acme(_dot_)example(_dot_)com>;
There must have been *some* concept of email that dictated that a message
could be sent *to* a group but not *from* one!
I don't remember whether this idea came up during discussions for RFC 733. I
don't think so, although it certainly seems to me to be as reasonable to be able
to apply the construct to the author field as to a recipient field. But since
the construct so infrequently used, I'm not sure it's all that helpful to
explore this "enhancement"...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf