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

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
<[email protected]> 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:[email protected]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.850.1850
> 
> 
>