Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!ox.com!lokkur!scs
From: scs@lokkur.dexter.mi.us (Steve Simmons)
Newsgroups: comp.mail.elm
Subject: Re: Confirm on open in elm ?
Summary: A compromise is possible
Message-ID: <1990Nov20.020554.2146@lokkur.dexter.mi.us>
Date: 20 Nov 90 02:05:54 GMT
References: <1990Nov19.162037.7631@amd.com> <1990Nov19.182044.14572@DSI.COM>
Organization: Inland Sea
Lines: 94

syd@DSI.COM (Syd Weinstein) writes:

I was going to requote Syd in detail here, but that's too tedious.
Reread his post if my responses make no sense, it was less than 24
hours before this response.

Syds comments are correct within a limited sense.  He compares email to
the USPS, wherein your receipt, reading, and action on a letter are
completely up to you.  The worst that can happen is a certified letter
which you can either refuse or accept and either way the recipient
finds out.

If the proposed return receipts, etc, were mandated upon the recipient,
I would agree fully with Syd.  But there is a way to deal this issue
without imposing privacy loss upon uninvolved 3rd parties.

In a corporate environment, one often wants to assign tasks to a
specific person.  One would like to define the task, assign it, get
acknowledgement back, and then get confirmation upon completion of
task.  If one has assigned or been assigned tasks, it would be very
nice to have a computer tell you what you're currently under the gun
for.

Yes, this is ranging far afield of simple email and into a corporate
management tool.  That's what people want with return receipts, acks,
etc.  The fact that this is surfacing in a discussion of email is
somewhat misleading -- email is only a piece of that management tool.

Email between private parties is quite a different thing from email in
a corporate environment, where there are lines of authority
acknowledged by both sender and recipient.  In a corporate environment
one may quite validly wish to have automatic acks, forced replies, etc,
etc.  [[If you don't like your employer doing such things with elm,
recall they could require you to use PROFS.  Definately a fate worse
than death.  Those who wish to discuss fascism, trust, etc, may feel
free to do so.  Please put it in your header line so I can kill it.]]

We have been having serious discussions about just such a tool at work,
and one of the mechanisms under discussion is to extend elm by use of
Xheaders.  One issue I continually harp on is making sure email to
folks outside of our corporate umbrella maintains exactly those privacy
considerations Syd mentions.  We don't have anything like a finished
design, but it's clear it will require some sort of X-authoritydomain
header.  This would be the 'authorization' field, saying what level of
authority the sender is working in.  So if I send you a message with

	Xauthoritydomain: Industrial Technology Institute (foo@iti.org)
	Xaction-required: confirm read to sender, htruman
	Xaction-required: reply by 11/25/90 to sender, dbcooper, htruman

in the headers, one of several things would happen:

 (a) If you are under the ITI authority domain, you have no choice --
     the ack goes out saying you read the message as soon as you look
     at it.  The ack goes to the sender and to `htruman'.  You should
     be informed this is happening.  You should also be informed of
     upcoming requirements, such as the 'reply by' action.

 (b) If you are not under the domain, you will be asked if you want
     to ack, if you want to postpone the ack, or if you want to
     permanently ignore the ack.  The ack goes out as described in (a).
     I suppose there ought to be an auto-ignore setting for this, but
     I'd kind of like to know who's trying to track me.

Note one hitch -- you *must* be using elm (or some other MUA which
handles the Xa* headers) or nothing happens in the way of response.
Elm would be site-configured to respect authority domains, probably
with a flat file that wouldn't require rebuilding elm to change
authority domains.  We've talked about modifying the MTAs to do this,
and I've pretty much convinced them that's a bad idea.

The address on Xauthoritydomain is where acks are sent to.  This is an
alias for a program which maintains the actions/requirements/acks
database.  It's the only way to handle it across multiple hosts/sites.
The db keeps everything central, making sure only one ack is done,
etc.  Some sort of cron-based reporter would handle simple passing on
of acks, etc, while the truly curious could interrogate it
interactively.  If the recipient doesn't complete the reply by the
given date, a nag message is sent to the original person plus the others
on the 'reply by' list.

There's lots more stuff required to make this work right (which means I
disagree with Syd about the difficulty), but you get the general idea
of how it might be implemented seamlessly and reliably.

What's the odds on this being implemented at ITI?  Pretty slim, IMHO.
ITI is very good about talking about such things, very poor at putting
any resources into them.  I just wanted to get these ideas out and show
that there is a compromise which gives those desired and useful
features but respects Syds legitimate concerns.
-- 
"When your neighbour loses his job, it's a slowdown; when you lose your own
 job, it's a recession; when an economist loses his job it's a depression."
	-- "Six Ways To Define A Recession", The Economist, Nov. 3 1990.