Nathaniel,
I'm cross-posting this to two mailing lists, the relatively-dormant
ietf-ack list, and the ietf-822 list for MIME discussions, because the
main point of this message is that I think the time has come to consider
merging the directions of these two efforts.
I agree that the time has come as well. It should be pointed out however
that this issue came up a few months ago, when Stef volunteered me to provide
a summary of the ietf-ack activity. Based upon the silence that message
generated as well as several private conversations at the time, we decided
not to bring up this can of worms at that time. This was done since we did
not want to detract from getting MIME out the door (the signal to noise ratio
was not very good then). There still is however, a significant interest in
this from many of the members of the ietf-ack list - we are just now coming
out of hibernation. :-)
One additional point - the timing of the reintroduction is interesting -
although I know this is most likely not intentional, at least two of the
people active on the ietf-ack list just left the country today for Japan
and will be out of contact for a week or so.
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.
Obviously some work would be required to flesh out the various
parameters, but I think this could all be done within the MIME framework
very nicely. Is anyone else interested in this approach? -- Nathaniel
I am certainly not against defining mechanisms where applications can
use these capabilities, but I believe that this represents a different
problem set than what the ietf-ack list was attempting to address.
Best Regards,
Tim Kehres