A footnote on the "find out from a database" issue. The more I
think about it, the more I conclude that the database lookup
(LDAP or otherwise) is the only rational way of implementing the
desired functionality here in a case that might involve relaying.
To the extent that speedy and confirmed delivery are often cited
as important values in fax, the "maybe it will get delivered as
requested, maybe it will be downgraded, maybe the format will be
influenced by the format requirements of other recipients, and
maybe the message will be bounced in a form that is hard or
impossible for the originating (or early relay) MTA to detect"
alternatives are unreasonable.
But, if database lookup is the only plausible implementation that
is consistent with the underlying design requirements, then we
should not be looking at capabilities negotiation in the SMTP
stream. Instead, we should be looking at a piece of protocol by
which the sending system (probably the MUA, rather than the MTA)
can figure out the capabilities of the recipient(s) and then
prepare the message, make address grouping decisions, etc.,
cleanly. It seems to me that would be more clear, would put the
responsibility back on the MUA or local system which has maximum
information about sender intent, would avoid layering violations
and other complications, and generally be a cleaner and more
efficient model.
I think this is a fine piece of theoretical analysis which unfortunately has no
applicability to the real world. In the real world directory/database systems
that let sites provide Internet-wide access to information about their users do
not deploy.
I'm not sure why this is the case, and indeed I'm fairly sure that there is no
good reason for it, but a vast tract of experience tells me it for-sure is the
case. (Now is not the time to get into whys in more detail.)
The IETF has tried to tackle this problem several times, and indeed continues
to do so now in the RESCAP WG. But I don't think anyone seriously believes that
even if RESCAP produces some specifications it is going to succeed at its
intended scale. Frankly, the silence is pretty deafening over there.
Lacking direct capabilities to find capabilties information necessarily leads
to various piggybacking options, that is, deploy this facility on top of or
inside other protocols. This has some of the same characteristics as the
everything-over-HTTP approach, but with several important differences: There is
a close relationship between the piggybacked data and the intended purpose of
the underlying protocols (a relationship that is often lacking with stuff
travelling over HTTP) and the operational case for doing this is far more
compelling (getting the OK to drill a hole in a firewall for a new protocol is
triviality itself compared to the difficulty in setting up even restricted
access to directory information).
I think the availabilty of capabilities information has the potential to be as
important a step as MIME was. As such, I don't begrudge healthy debate about
how and where it is done. But let's not forget that the development of MIME was
informed by the catastrophic failure of various other schemes for doing
multimedia messaging -- some of them more elegant than MIME -- leading to
compromises in the design intended to insure deployability. I think the
discussion of where and how to do content negotiation needs to be similarly
informed by the catastrophic failure of Internet-wide directory services to
deploy.
Ned