Markus Stumpf wrote:
On Wed, Feb 25, 2004 at 11:11:47AM -0500, Bruce Lilly wrote:
The obvious answer is because this is a mailing list (not a BBS, or a
web-log, or a newsgroup). Clearly the focus of this mailing list is
on "the next generation of mail".
The answer isn't obvious at all.
If you look at
http://www.imc.org/mail-ng/mail-archive/msg00562.html
what do you see?
A HTML page. Is it still an email? If not, why not?
It's not, because I cannot do things with it that I can do with email
(e.g. reply to the sender, submit a follow-up with correct References).
Also precisely because it is text/html and not message/rfc822 (there
is a somewhat related ongoing discussion on the ietf-822 list, by the
way).
Less formally, the "duck" test (if it looks like a duck, walks like a
duck, and quacks like a duck, it's a duck) indicates it's not email:
it doesn't look like email, it's not accessed like email, and it can't
be replied to, forwarded, etc. like email.
What defines something to be an email?
A combination of the message format and the means of transport as
it relates to functionality specific to email (sending, receiving,
replying, etc.).
Should this definition also hold for "the next generation of mail"?
From the goals/requirements/desiderata thus far discussed, there
would seem to be a need for some type of message format (to indicate
language and other metadata in addition to the raw content). And so
far as email is a form of communication distinct from BBS', web-logs,
newsgroups, etc., I expect that there will be email-specific transport
considerations.
The message format will evidently need to be different from today's
in some respects. Whether or not some existing format can be used, or
a new format which might also be applicable to other services (as e.g.
current use of RFC 822 message format for fax, voice mail, Usenet news,
etc.), or an email-specific format remains to be seen. Likewise for
transport protocols.
So in general terms, yes, next-generation email will be defined in
terms of its format and transport as they relate to email functionality.
Of course, the details will be different from today's email in some
respects. The basic functionality (some message content sent from
one entity, perhaps on behalf of a small number of individuals, to
specific recipients, with the ability for resending, replies, and
so on) will have to remain -- otherwise it's not email -- though
some new functionality might be added.