Re: Keywords for "SMTP Service Extension for Content Negotiation"

--On Saturday, 13 July, 2002 12:04 +0900 Dave Crocker
<[email protected]> wrote:

>> - consideration of relay
> 
> Facsimile is direct, point-to-point.  The sending device and
> the receiving device are connected to each other at the same
> time.  They talk with each other directly.
> 
> Internet mail is store-and-forward.  The sender and the
> receiver are not required to be connected to the Internet at
> the same time.  The email may go through intermediate email
> services, when moving from the sender to the receiver.  (For
> example, it may go from a department's SMTP mail system to the
> enterprise system; the enterprise system may send it to the
> receiving enterprise's system; the receiving system may then
> send it to the receiver's department email server.) This is
> like packet switching.  Each intermediate system is "relaying"
> the email.

It is like packet switching except, of course, in the packet
case, each packet is typically a fragment or component of a
message.  The message, or data stream, is sent one packet at a
time; it is not completely assembled at each intermediate host
and then forwarded after it is complete.  With email, each relay
host obtains, assembles, and stores the entire message, only then
initiating a new transaction to forward it.  That difference is
significant for a few purposes, insignificant for most, but we
should be careful to not push analogies to packet-switching too
far.

> The primary difference between relaying versus direct is that
> relaying might take much longer.  Therefore the sender does not
> know when it will receive a response.

I would disagree.  The primary difference I see between relaying
and direct is that, in a direct arrangement (characteristic of
e.g., HTTP) the originating sending system can ask the ultimate
receiving one a question by, well, asking.  In the relay case,
such questions can only be asked of an intermediate system, which
must respond based on indirect information (which it finds in a
database, see below) or by acting as proxy for a remote system,
using information it has not obtained yet.   Some illustrations:

Q: Can mail be delivered to this address?

	Direct answer: "yes" or "no"
	
	Relay answer: "I have no idea, but I will accept
	responsibility for the mail and promise to forward it to
	someone else who will accept responsibility.  For each of
	us, we understand that "accepting responsibility" means
	that we will either deliver the mail to the final
	recipient, deliver it to someone else who agrees to
	accept responsibility, or return an error message which
	will, of necessity, come out-of-band relative to the
	original connection".
	
	Note: contrast this with TCP, where the packet-switching
	model and the nature of the protocol permits getting the
	possibly-analogous "yes, the destination host will accept
	traffic on that port" answer back before any data packets
	are sent.

Q: Does the recipient support this data format?

	Direct answer: "Yes" or "How about one of the following?"
	
	Relay answer 1: "The database says you should try..."
	(see below)
	
	Relay answer 2: "I don't have a clue, but I will accept
	the message on the assumption that it does, and pass it
	on, either to that destination or to some other site
	willing to take responsibility.  If it turns out the
	recipient cannot accept the format, I (or one of the
	systems to which responsibility has been passed) will
	(preferentially) convert the format to something that can
	be accepted or (less preferred) bounce it with an
	out-of-band message."

Those seem fairly different to me, much more different than
"slower".  In fact, I think that difference is part of what this
discussion is about: if the only difference were "might take
longer", I don't think we would be having this (part of) the
discussion at all.

     john

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.