=> This is an interesting approach. In my mind the two most important ack
=> requests are return receipt (knowing the recipient has seen the message),
=> and delivery notification (knowing the recipient's UA has received the
=> message). As such, I think it would be desirable to come up with a
solution
=> that did not require MIME, but only specified extensions to RFC 822.
But MIME is a good way of doing it...see some of my ideas below. And
either way you have an extension to RFC 822 that requires a UA to
understand what is going on. So what's the difference?
I don't disagree with this. All I am trying to say is that if it is possible
to extend 822 in a way that does not require MIME, then why not? I just
don't see MIME as a prerequisite for defining these enhancements. At this
point, I believe that they can, and should stand on their own.
There are a lot of systems (and vendors) that support different ad-hoc methods
for dealing with these issues. The software involved usually is quite simple,
and if presented with a "standard" solution, for some of them it might be
easier to get them to upgrade if they did not first have to embrace MIME.
=> Yes, it is done by the receiving UA (or its agent), but different existing
=> implimentations have different ideas of whether this is at the discretion
=> of the receiver or automatic. I completely agree with your statement, and
=> it also corresponds with what is referenced in X.400. Other mail systems
=> however, deviate from this and automatically generate return receipts with
=> no way for the recipient to stop the return message. Microsoft Mail and
=> some of the mainframe mail systems come to mind here.
=>
=> This was an area that generated a lot of debate (bordering on religous
=> discussions) last year.
I think it should be easy enough to make UA's allow for voluntary
acks. I guess it is up to the "customer" to decide whether or
not the MS Mail (fascist :-) approach is suitable for them.
This is really not my area, but a while back I seem to remember that there
might be some legal implications associated with the UA unconditionally
generating read acks. Something to do with invasion of privacy I believe.
Personally, I think that in regard to read acks (or return receipts), that
whatever solution is eventually agreed to should have wording either declaring
UA's that behave in this way as being broken or at least very strongly
discouraging implimentors from abusing this feature in this way.
No matter how you do it, you will require a new piece of software
to make it function. So what if it is a new UA or MTA? The way
I see it, this just gives me one more good reason to want MIME
in my next UA.
It is true that software will have to change. However, the scope of
the changes can be quite different. Many existing implimentations will
only require very minor changes to handle a non-MIME specific extension.
Supporting all of MIME in addition to this is a very different set of
issues to consider, especially if you are a vendor that has to support
this code.
BTW, I feel that MIME certainly has enough good reasons to prompt an
upgrade of software on it's own merits, regardless of the ack stuff. Unless
there is a significant benefit for requiring MIME in conjunction with the
ack enhancements, they should be kept separate from one another.
Here's what I would like to see (from the user's perspective).
As a sender of mail:
Upon sending a message I can request an ack. I can also set an
expiration on that ack (the default expiration being on the
order of 3 days, but configurable in the UA).
For messages that I request an ack on, a copy is created somewhere
such that whenever I am in my UA I see a list of unacknowledge
messages that I have sent ...
:
:
When an ack comes in, my UA automatically "tags" the acked message
and I can view that ack to see time and date. In the case of a
UA that moves the messages to a different screen, placing the
ack tag on the "main screen" might be a good idea. (A good UA would
have kept track of how many recipients there were to my mail and
let me know how many have come back out of the total.) If the
ack comes with a reply (see below for the recipient's perspective),
then I get to see the reply and from that point on my UA treats that
as any other piece of incoming mail.
Now the tough part. For mail that I don't get an ack on within
the epiration period, the remote site should *then* generate a
Delivery ack. The point here is that at least now I know that
the mail was delivered. The reason I don't want the Delivery ack
earlier is that if I get a read ack in a resonable time then
the Delivery ack is not needed (and really not wanted).
Hmm.... this is a very interesting situation. While most of the issues
raised are UA specific, and not directly pertitent to how acks are
represented, it brings up the following issues:
o When you request the ack, you should be able so specify either a
delivery ack and/or a read ack.
o The response must be such that a automated process can look at it
to determine what it is, and what it is reference to. This I believe
is the point that Bob Smart brought up earlier as well. This implies
more than just the standardization of the mechanism for specifying
the ack, but also defines what the response is to look like.
o Cancellation of a delivery ack if a read ack has already been sent:
This is interesting, but I believe not practical. If someone is
interested in both, let them request both. It is not that much extra
overhead.
Anyone care to take a crack at what a return receipt (read ack) or a
delivery notification (delivery ack) should look like?? At a very minimum
I would think it should contain a well marked reference to the original
message's message-id. There should also be some kind of marking to identify
it as a delivery notification or return receipt as opposed to a reply. Have
I missed much??
Best Regards,
Tim Kehres