Bob,
Methinks there is a flaw in your ointment.
Your line of logic is the sort that asserts there is no need for
end-to-end acknowledgements in TCP, since it should be perfectly
adequate to rely upon the lower level, link-layer sequence of
ack mechanisms.
Further, your model requires complete support, along an entire
path, when it may be just as likely that an intermediate node does
not support acks, but the final node does.
In other words, I think it is fine to push for more robust
email transport protocols, but the delivery ack mechanism is
fundamentally an End System function and *not* and Intermediate
System function.
Further, it is cheaper to add it to 822, and allow gradual adoption
than to require full *intra-* system adoption prior to being of
any use.
If one take the User Header vs. Transport Envolope vs. Transport
operation model, then one would assume that the Originating user
interacts with their UA to specify the delivery ack request. This
is then encoded down to the transport envelope, where it stays, until
the final delivery MTA is about to hand the message off to the
recipient UA. It is fine for intermediate transfer agents to notice
the request, on the envelope, and try to improve the reliability of
the response mechanism, by asking the next hop if it supports the
function, but a negative response does *not* necessarily mean that
the final MTA won't support it.
In other words, I'm suggesting that we make sure that the mail system
supports these features in its upper "layers" before insisting that
it support them in a lower layer.
Dave