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

At 03:11 AM 7/13/2002 -0400, John C Klensin wrote:
> --On Saturday, 13 July, 2002 12:04 +0900 Dave Crocker
> > Internet mail is store-and-forward.  ... 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.
"Typically", perhaps, but it is not true for all packet switching systems 
and it is not part of the formal definition of packet-switching.
Packet switching is about independent addressing (and usually independent 
routing) and handling of discrete chunks of data.  It is not about the 
relationships among that data.  To that extent, Internet mail is quite 
similar to lower-level packet switching.
(I say it is exactly the same, but therein lies a debate that some of us 
have enjoyed for a few years -- errr, decades -- and it is not pertinent to 
the specification under review.)

>   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.
On the contrary, Arpanet IMP packet switching did fragmentation and 
reassembly in the net, not in the hosts.  (Any further debate on this issue 
might be interesting, but it, too, is not relevant to the current topic.)

> > 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.
The UA-based CONNEG mechanism does query/response between two UAs that are 
connected only by the store-and-forward email service.  There is nothing 
that dictates that application-level query/response exchanges be conducted 
over connection-oriented, direct or real-time associations.
Just to underscore how fuzzy all this gets:  HTTP relies on the underlying 
store and forward of IP.  Email UAs rely on the underlying store and 
forward of SMTP.  And, of course, SMTP also relies on the store and forward 
of IP.
More importantly, these concerns are essential matters for successful 
implementation, deployment and use.  But they have nothing to do with core 
architectural principals.
With respect to direct vs. relay, the architectural difference between a 
UA-UA exchange and an HTTP exchange is remarkably small, especially given 
that HTTP usage pretends it has no context.  These differences get even 
smaller with the introduction of caching servers, and the like, because 
they introduce a very high degree of indirection between consumer and provider.

> 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.
Yes, it is an appealing model, except that LDAP has yet to achieve 
Internet-scale deployment and use.  Consequently it is not wise to make a 
new service dependent on it.
It is also worth noting that such a model requires real-time 
connectivity.  An email-based mechanism can operate with asynchronous access.
It makes far more sense to postulate a range of choices -- including 
directly asking the own of the information via a UA mechanism, as well as 
direct intermediaries via ESMTP/CONNEG -- and incorporate LDAP when it 
starts being a serious global service.

> To the extent that speedy and confirmed delivery are often cited
> as important values in fax, the "maybe it will get delivered as
> requested, ... is hard or
> impossible for the originating (or early relay) MTA to detect"
> alternatives are unreasonable.
To the extent that a higher degrees of certainty is required, then the 
operational components should be configured to provide it.  Using LDAP does 
not provide any guarantees of proper or speedy performance, any more than 
using UA- or SMTP-based content negotiations guarantees the lack.
d/

----------
Dave Crocker  <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850