Dave,
You are, I think, equating packet fragmentation and reassembly to
email messages. IMO, that is bogus (and, as you point out, this
argument is decades old and I believe it has been bogus for at
least that long), unless you constrain those packets to reliable
delivery and permit them to be very large. I.e., the only
reasonable comparison is to a collection of packets in a a
connection-mode (or other serialized and reliable) context. It
was in that context that I used the term "message" -- typically a
multipacket entity in the TCP and IP layers just as an email
message consists of a series of SMTP turnarounds over TCP. In
that context, I stand by my assertion. And the reassembly of
packets (as distinct from data streams/ messages) in the ARPANet
is, I'm sure, fascinating to the few people on this distribution
who didn't know about it and care.
john
--On Saturday, 13 July, 2002 17:43 +0900 Dave Crocker
<dcrocker(_at_)brandenburg(_dot_)com> wrote:
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