Re: visions

Markus Stumpf wrote:
> On Wed, Feb 25, 2004 at 01:39:44PM -0500, Bruce Lilly wrote:
> 
>>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.
> 
> 
> (you're unfair ;-))) you deleted my question about webmail ;-))

Oh, that's what the "hotmail" reference was!  I've only used "webmail"
a few times, and it's not like real email (for one thing, it's not
possible to search messages when offline).

> I think with the above statement all webmail users would say that
> their HTML pages are email.
> So you are really saying that just by adding a few more buttons to
>     http://www.imc.org/mail-ng/mail-archive/msg00562.html
> that would make it possibly to reply, forward would turn a HTML page
> into a email?

From a technical perspective I'd say that there are gateways between
email and webmail.

>>So in general terms, yes, next-generation email will be defined in
>>terms of its format and transport as they relate to email functionality.
> 
> 
> I don't agree with you here.
> You can transport nearly everything with what we now call email, so at
> least some kind of content-format is irrelevant.

Not really. An SMTP receiver will prepend a time-stamp line (a.k.a.
Received field), so even if SMTP servers never peeked at the DATA
content, it wouldn't be possible to directly transfer arbitrary
content (not to mention CRLF and line length issues).  Of course
it's possible to encode and package arbitrary content using MIME
methods within the RFC 822/2822 text message format, but that is
itself a very specific format, which has to be parsed at the
receiving end in order to recover what was transferred within the
email wrapper. That's the type of format -- the email wrapper
that carries the message data and metadata -- that it part of
what defines email.

> Also, if I have a Web-Interface where people can key in messages and
> the form appends it directly to my mailbox I will see it as email
> but the transport was HTTP and not SMTP. And if there is a field for the
> sender email address I can even reply.

Yes, there are transport methods other than SMTP (UUCP is another,
and a while back (before SMTP) mail was also sent via ftp), but
those typically do not support the types of features that have been
discussed (delivery/read notifications, for example), without
some application-layer support (e.g. BSMTP over UUCP).