Bob,
Well actually, historically, I have proposed a hybrid model which
does not have this restriction.
Hybrid seems the way to go. Encode an end-to-end request/reply in
RFC 822 headers, and upgrade SMTP to do per-hop checking of support
for the facility. (Given the possibility of intermediate non-support,
while still having recipient system support, we might want to
distinguish how to handle non-support by intermediate
systems: don't send onto next hop, notify originator but send to
next hop, send and don't notify.)
So basically I agree with everything in your message as far as it goes.
(Well, it's always fun to wait for the other shoe to drop...)
The key problem is how do you do _guaranteed_ delivery Acks.
This is, unfortunately, a very simple question to answer: You don't.
We have 20 years of history in the operation of Internet email, where
one of its prime charcteristics is only minimal conformance.
I think that we can, should, and must do better, but the concept of
"guaranteed" levels of service, in a system with highly distributed
and independent administration, much of which is "casual" rather than
professional, suggests that we will not attain your goal anytime soon.
As Internet EMail moves towards more commercial styles of operation, much
as the underlying IP Internet has, then your goal may be attainable. My
own guess is that that is at least 5 years away, perhaps more. (And I'd
be delighted to be wrong.)
... What
does this mean? It means that if you ask your UA for a Delivery Ack
then you will definitely [barring catastrophic disaster in the
mail system like a disk crash] get one of: (a) a Delivery Ack; or
When, the small "barring" clause hold the keys to the kingdom. The
lesson of network transport is that such problems DO occur. Low-level
reliability mechanisms are still very much Good Things, since they usually
detect and fix localized transmission problems quickly. But there still
is a basic requirement for an end-to-end mechanism, separate from the
underlying one.
For those who think that the end-to-end reliability mechanism of TCP is
not that big a deal, I'll mention that I witnessed a very serious
commercial impact, involving corruption of file data, near loss of a
major account, and consumption of several weeks of time among senior
technical staff at one company, specifically because of such an error.
The products did not use a protocol that had end-to-end reliability,
so the mis-behaving hardware interface couldn't be detected in any
trivial way, nor could the corrupted data.
Once again: Model email as a packet net and many technical decisions get
extremely easy.
And it fact it is so
different to Delivery Acks in other systems, like X.400, that you
could not use such an optional Delivery Ack to gateway a mail
message with a Delivery ack request from X.400 to the Internet.
Hmmm. Hadn't thought to specify the semantics as making the ack
request optional, merely to tolerate current operational realities,
in order to provide SOME utility. (Hidden agenda: If people start
supporting the function, then they are likely to provide, ahem..., errr...,
"feedback" to those who do not.)
In any event, I agree that we should copy any/all of X.400 services
that the Internet community feels is appropriate.
And what I am saying is that we need to formalize the way one intermediate
transport agent asks the next one for support of the Delivery Ack
request. If the next hop won't support it the user needs to know that
that is as far as the message could get with the guarantee attached
to the Delivery Ack.
We are in violent agreement about the basic need. It appears that we
have some difference in how to handle the non-support condition.
...this
is not a real problem in the Internet. The reasons why a message takes
multiple hops in the Internet are few in real life [yes you can
source route but that is deprecated]. Sometimes hosts are configured
to send mail to a mail hub instead of following the MX. In this case
if the sending host supports Delivery Acks you can be sure that the
mail hub it uses will also.
Bob, this is flawed in two, fundamental ways: First, multi-hop
configuration (e.g., mail hubs) are *far* more prevalent and essential
that your statement implies. Also, I strongly suggest that we start
thinking of Internet email as something that reaches much farther than
SMTP/TCP/IP, since there are several other, major services that use
Internet email objects (rfc 822) but not Internet transport protocols.
This means at least one extra hop, to relay between the environments.
Second, the "it will support the service, too" argument goes back to
relying upon an independent series of link-level mechanisms, with no
upper-level, end-to-end "glue".
/Dave