ietf-822
[Top] [All Lists]

Re: MIME types for ack[-request]?

1992-03-30 08:09:13
Hi all,

I don't claim to be up to speed technically, but from a user
perspective I have a strong interest in MIME.  Also, here at
Georgia Tech there has been a voiced need for some sort of
ack system (quoting various users here "after all, PROFS does
it").

I hope you don't mind some of my impressions of the discussion....

From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
Subject: Re: MIME types for ack[-request]? 

=> > From: Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
=> > To: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
=> > Subject: Re: MIME types for ack[-request]?
=> 
=> > As for the question of acks in SMTP versus acks in MIME bodies -- I
=> > think this comes down to a question of what you want acks to mean, as I
=> > alluded to before.  
=> 
=> Or what you want the ack to be used for.  If I want an acknowledgement
=> that a message was *read*, obviously that's a UA function and the request
=> goes in the header.  If I want an ack that the message was *delivered*,
=> that's an MTA function.  Personally, I think we need both kinds of
=> acks.

Partly true.  Most of the time I don't want/need a Delivery ack, but
if I don't get a read ack then some sort of delivery ack after the
fact would be cool.  (That way I know that the message was *delivered*
but apparently not read.)

=> > Think about return-receipts in the physical mail. 
=> > You don't want a piece of paper in which the post office says "we
=> > dropped the mail in what we're pretty sure was the right mailbox."  What
=> > you want is a piece of paper signed by the recipient.
=> 
=> Well, in my experience, that's not what you get, at least with the US Postal
=> Service.  What you get is a piece of paper signed by someone at that
=> address.  It tells you that the Postal Service did its job, but doesn't
=> really certify that the named recipient got the message.

But from a legal perspective you know that a representative of
the recipient got the message.  What you don't know is whether or
not they opened it and read it.

The same is true for email.  I may get a read ack from someone but
that doesn't really tell me that they actually *read* the message
but it does tell me that they don't have an excuse for not knowing
what I sent them.


From: Bob Smart <smart(_at_)mel(_dot_)dit(_dot_)csiro(_dot_)au>
Subject: Re: MIME types for ack[-request]? 

=> :
=> Of course Acknowledgements don't have to be in a well-defined
=> software-interpretable format. However existing messages in random
=> format are going to have to continue to be interpreted by the 
=> human recipient. We must define and move to a format which will
=> allow the user's mail user interface to automatically associate
=> Acknowledgements with the copy of the original so the user can
=> easily see the status of messages that he has sent.

This is (IMO) the single most important comment made in the 
discussion.  Acks don't do me a bit of good unless I have
some convenient way of keeping track of them.


From: kehres(_at_)ima(_dot_)com (Tim Kehres)
Subject: Re: MIME types for ack[-request]?

=> > The ietf-ack group has been discussing mechanisms for return-receipt
=> > mail on the Internet.  I think that this can all be done very nicely
=> > within the MIME framework, and I was wondering how other people felt
=> > about it.  Basically, I would propose two new MIME types,
=> > "application/ack-request" and "application/ack".
=> 
=> 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?


From: kehres(_at_)ima(_dot_)com (Tim Kehres)
Subject: Re: MIME types for ack[-request]?

=> > Acking delivery is a UA-MTA (final MTA) request and may possibly be
=> > viewed as involuntary (a point for discussion) by the recipient.
=> 
=> Agreed.
=> 
=> > Acking reading is very much by the receiving UA and is almost certainly
=> > entirely at the discretion of the receiver.
=> 
=> 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.


From: kehres(_at_)ima(_dot_)com (Tim Kehres)
Subject: Re: MIME types for ack[-request]?

=> My only concern regarding integrating this with MIME is that ack's of any
=> type will now *require* MIME in order to function.  For the types of service
=> we are discussing, I don't believe this needs to be a requirement.

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.


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 (whether this is on the "main screen"
mixed with other incoming mail or on a separate menu that I have
to explicitly access is left up to the UA designer).

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).

How do we handle the "delayed" Delivery ack?  I don't know...I
am open to suggestions...(it would be "clever" if it was 
handled on the recipient's end because then the Delivery ack
would never be generated and sent if not needed.  If handled
by the sender's end then every piece of mail will generate
a Delivery ack that may just sit at the sender's end to be
ignored if the read ack comes in before the deadline.)

Now the recipient's perspective:

I get a piece of mail.  I read it.  Now I am normally going
to save it, delete it, or just leave it sit.  Additionally,
I may reply to it before doing one of the above "final" actions.
At the point between reading and any of the above actions (when
I hit the delete, save, reply, next message, or quit keys),
the UA prompts for the ack to take place.  I should have the 
choice of a) not ack'ing b) ack'ing or c) replying.  Ack'ing
or replying should rewrite the Status header to include a code
to that extent.  That way semi-fascist mailers can keep requesting
and ack everytime you look at that message.  (Really fascist
UA's will just generate the ack.  I don't think that is as good
because if you intend to reply, the UA generated two pieces of
mail, ack and reply, rather than just one piece with two
parts.)

Now I know that none of what I said tells you how to write
the headers or how much traffic is generated or anything else
useful from a technical perspective.  I hope that what this
does do is to stimulate some thought about what functionality
needs to be in ack[-request] so that it will be adequately
designed.

Thanks for listening,
Robert
-- 
| Robert L. Howard             |    Georgia Tech Research Institute     |
| rhoward(_at_)matd(_dot_)gatech(_dot_)edu      |    MATD Laboratory            
         |
| (404) 528-7165               |    Atlanta, Georgia  30332             |
-------------------------------------------------------------------------
| "See, when the GOVERNMENT spends money, it creates jobs; whereas when |
| the money is left in the hands of TAXPAYERS, God only knows what they |
| do with it.  Bake it into pies, probably.  Anything to avoid creating |
| jobs." -- Dave Barry                                                  |