On 8/26/23 01:40, Murray S. Kucherawy wrote:
What is "interactive email"?The short version is any email that the recipient can interact with. There were experiments done with interactive email at least as far back as the 1980s, for example with the Andrew Message System that Nathaniel Borenstein contributed to, but there were other systems also that I've never tried personally.
I still don't know what this means. Does it mean anything that contains more than text? I mean, I think a message thread such as this one qualifies for some definition of "interactive". Or do you mean forms? Or images or animations/videos? Executable payloads?
Interactive mail can (and already does) encompass many things.
It already exists as an industry term rather than as some specific
protocol or set of protocols. (to see how the industry uses the
term, just do a web search for "internet mail"). But what
interests me about interactive mail isn't so much advertising or
customer relations management, but opportunities for improved
collaboration.
If we had executable payloads for Internet email, they would
undoubtedly be used to implement interactive email. But this is
NOT the direction I would recommend that IETF or anyone else
pursue. There are of course risks with executable payloads in
email of various kinds that have always been recognized (at least
as far back as the 822ext working group discussions that led to
MIME, and I think earlier in the context of proprietary
interactive mail designs). There have been several efforts to
build "safe" environments for execution of payloads provided from
elsewhere (dating back to at least safeTCL, Java, _javascript_,
WebAssembly...) , and most (I suspect all) have failed to be
"safe" in the long run if/when used at scale. There always seems
to be "market pressure" for such environments to be able to do
more and more, either by exploiting limitations in the original
design and/or to relax the originally-imposed restrictions in ways
that cause harm to ordinary users. So I'm extremely skeptical
that executable payloads are the right way to implement
interactive email, even though we've learned a lot about VMs and
containers since the 1990s.
What I currently have in mind for implementation of interactive
email is (a) messages can include "objects" that are rendered as
text, images, buttons, forms, etc. by the recipient's mail
reader. The code to implement the interactions and display of
those objects isn't sent in the email and doesn't run on the
recipients' computers, but instead is resident on a server and
runs on that server (or in a container on that server). The
appearance of those objects is derived both from the original
email and also from data on the server that is associated with the
email message. Crucially, the appearance of those objects to a
reader can change not only when a recipient interacts with the
object, but also, when the data on the server is changed.
For example, let's say I email a technical proposal to an IETF WG
list. Other list participants could then vote up/down on that
proposal (or specific sections of that proposal) by clicking
buttons associated with a poll object in the email (e.g. "do you
prefer approach A or B?"). The current vote totals would always
be visible to anyone viewing that original email, and readers
could change old votes if/when the proposal text improved. Some
readers might offer annotations (comments, suggestions, etc.) to
specific portions of that proposal, or corrections to that
proposal which could be accepted or rejected. These would be
visible to any reader (or re-reader) of the original email.
I think our technical discussions would converge more quickly that
way, because people wouldn't have to read every single email and
try to keep track of all of the changes in their minds,and also
that it would be a lot easier to keep track of the evolution of
such a proposal than it is today. It would be somewhat like
collaborative editing of a single document (which we're familiar
with already) except that each email message would potentially be
such a document. The documents would be filed very much like
emails in folders, each automatically dated, with a subject and
other metadata, change history, and searchable. Anyone could see
the current state of the document just by (re)reading the message,
and also be able to see the history of each change.
And when combined with a mailing list, the same server can also
manage the mailing list and archive and allow interactive changes
to the subscriber list. For example:
- Say you send a message to a group of recipients and
accidentally leave someone out. You re-read the original email,
and click a button in that email that lets you add a recipient
to the To or CC list. The server then sends a copy of the
original message to that recipient, and adds that recipient to
its internal record of recipients for that message. The new
recipient is now able to read the message, vote, annotate, etc.
just like any other recipient.
- Similarly, you send a message to several recipients and
accidentally include a recipient who shouldn't be included. As
an author of the original message you can "remove" a
recipient. The copy of the message that was actually sent to
the recipient won't go away, but the accidental recipient won't
get followups, and the interactive features won't work any more
for that recipient.
- Or say that a mailing list subscriber is tired of reading a
thread and wants to opt-out of that thread. The recipient
clicks an "opt-out" button at the top of the message and the
server takes note, and doesn't forward any more messages from
that thread to the recipient. The messages will still be
readable from the archive, and the recipient can optionally
"opt-in" to that thread later if they want to resume receiving
messages from that thread.
- Or you send a message and fail to notice that you've said something inappropriate or unhelpful or embarrassing until after you've pressed "Send". You can go back and edit your own message to be more appropriate. Doing so won't erase the memories of those who have already read the message, and the original message will still be preserved in recipients' mailboxes and the archive. But subsequent readers will see the edited version. (The change history will presumably still be visible to readers who care to look at it, but at least there will be a way to "fix" some kinds of mistakes without calling more attention to those mistakes than necessary)
At least some approximation of all of this can be done now, with
HTML email and clever servers, but it's clunky. My idea of what
standards would look like would be to specify user agent behavior
(e.g. don't open a new browser window when clicking on a link in
an interactive email message), clean up some of the user
interactions (e.g. let new recipients appear in message headers
for newly added recipients; let readers cleanly specify
annotations to messages they're reading, flag messages that had
been updated since the most recent reading), maybe some
credentials management. For the sake of compatibility such
interactive messages would have to be at least somewhat functional
with today's existing HTML-capable user agents, but they'd work
better with MUAs designed to work with the new interactive mail
standards.
Why wasn't it further developed here?
I can't say for sure. One guess I have is that soon after the
MIME and SMTP extensions got out the door, the working groups were
shut down. There were some reasons for that, among which were
that there were LOTS of ideas for what to do next, with varying
levels of clue behind them, and for IETF to support a wide range
of such follow-on efforts would have spread IETF's participant
energy very thin and also overtaxed IESG, while probably also
producing some work of dubious value and perhaps even some work
that did harm. So I think that, for better or worse, there was an
explicit effort to "take the wind out of the sails" of these
follow-on efforts.
If it lost momentum, I'm not sure I'd agree with characterizing that as "failure"; maybe people just weren't interested, or their attention wandered.
What if instead of labeling these as "failures" I called them
"valuable opportunities that were lost or missed or unnecessarily
delayed to the point of making it harder to add such capability in
the future"? To me that's a kind of failure, but the word
"failure" can be understood in various ways.
Keith
