Nathaniel,
Yes, discussions of acks always seem to (de)generate lots of issues of
functionality levels, types of acknowledgements, and so on.
Don't forget all the religous issues that came out of this. :-)
A lot of
this was beaten to death in early rounds on ietf-ack, to no obvious
fruitful outcome.
I think a lot of this had to do with arguing about one of the following
sets of issues:
o Since many implimentors had a rather fascist approach to the
unconditional generation of return receipts, some felt that this was
reason for not allowing any mechanism for providing this type of
service.
o Some felt that the only type of ack that was of interest was what
could be provided by enhancements to SMTP where others felt it was
strictly an 822 matter.
With the breakdown that Dave suggests, I believe that at the very minimum,
these discussions can be isolated to one of three different categories,
without impacting other areas. With this in mind, we should be able to make
reasonable progress in each of the three areas.
I guess what I was hoping is that MIME provides a
framework (parameters on the content-type line) that allows us to
specify which level we're talking about, rather than to argue endlessly
over which level we SHOULD be talking about.
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.
Personally, for example, I believe that MTA-level acks are nearly
completely worthless. The only ack worth anything, to my mind, is an
ack from the end-user, indicating that he has really seen your mail.
This is certainly useful from many points of view, but definitely not the
only useful type. In my work a few years back at LLNL, we had a mail package
that we provided to many government agencies. Their initial reaction was the
same as yours, but when we really got down and talked to them to find out
what they were looking for, the majority of them simply wanted some way to
be able to determine that the message made it to the recipients mailbox and
did not get lost in transport. We implimented both, but found that what was
most often needed was the delivery notification, or MTA-UA level acks.
Are there any levels that couldn't be handled in the MIME
framework? I think not in theory, but in practice it will be a while
before there are very many MTA's that are prepared to responde to
"Content-type: application/ack-request" buried deep in a multipart MIME
message. This doesn't much worry ME because I don't want MTA-level
acks, but it may be a problem for other folks.. -- Nathaniel
This is the problem in making MIME a requirement for ack's. It is also
unclear to me how this would work across gateways. A nice side effect from
this effort would also be to update RFC-1148 to take into consideration any
enhancements decided upon here.
Best Regards,
Tim Kehres