[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Public intro private: more history
Risto asked me to forward our side exchange into the list.
Pls note that the last two messages should be read in reversed order.
Dave
------- Forwarded Messages
Return-Path: @odin.nma.com:stef@nma.com
Received: by nsl.pa.dec.com; id AA09100; Tue, 19 Feb 91 12:51:30 -0800
Received: by decpa.pa.dec.com; id AA04357; Tue, 19 Feb 91 12:50:34 -0800
Received: from nma.com by nrtc.nrtc.northrop.com id ab13311; 18 Feb 91 22:16 PST
Received: from odin.nma.com by nma.com id aa00590; 18 Feb 91 21:15 PST
Received: from nrtc.northrop.com by nma.com id ad00334; 18 Feb 91 16:35 PST
Received: from ics.uci.edu by nrtc.nrtc.northrop.com id aa12104;
18 Feb 91 16:31 PST
Received: from keos.helsinki.fi by ICS.UCI.EDU id aa10106; 18 Feb 91 16:13 PST
Received: by keos.Helsinki.FI (4.1/SMI-4.1/34-keos)
id AA00689; Tue, 19 Feb 91 02:13:01 +0200
Date: Tue, 19 Feb 91 02:13:01 +0200
From: Risto Kankkunen <kankkune@cs.helsinki.fi>
Message-Id: <9102190013.AA00689@keos.Helsinki.FI>
In-Reply-To: Einar Stefferud's message as of Feb 17, 18:19
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: Stef@ics.uci.edu
Subject: Re: A multiple bodypart multiple content type message
Prev-Resent-Date: Mon, 18 Feb 91 16:14:03 PST
Prev-Resent-From: stef@ics.uci.edu
Prev-Resent-To: stef%nma.com@nrtc.northrop.com
Resent-To: Dave Crocker <dcrocker>
Resent-Date: Mon, 18 Feb 91 21:14:55 PST
Resent-Message-Id: <15201.666940495@nma.com>
Resent-From: Einar Stefferud <stef@nma.com>
[Didn't want to clutter up the list with this.]
> > I think the MTA, when it notices it has 8-bit data to send to a 7-bit
> > MTA, could just encode and encapsulate the original message and add a
> > suitable Content-Type (or Encoding or whatever) header to the message.
> > The reveiver wouldn't know whether it was the MTA or the author of the
> > message that did the encoding.
>
> I don't think you guys really appreciate the magnitude of confusion
> and mess that is going to follow from random MTA RELAYS doing 8>7 and
> 7>8 conversions between 8-8 sender-receiver pairs.
Nice rhetorics, but can you point out some real problems? Makes a little
bit hard to agree or disagree with such general views.
If we use 7-bit transfer, we have to specify some encodings and headers
so that the receiver's mail readers can decode the message the sender
coded. I assume you don't see any problems with these conversions.
Now, if we allow some sites to speak 8-bit with each other, we don't
need to encode the messages. But if the receiver doesn't say it wants
8-bits, the sender-MTA makes the same encoding as mentioned above. How
the conversion done at this point can cause so many problems, if done by
the user it isn't a problem at all?
> Every 8-bitter is going to have to handle 7-8 decoding in any case for
> soime cases, so what it the big advantage?
The advantage is that in most cases they probably wouldn't need to
encode, saving bandwidth, CPU and disk space. I think many sites would
like to do this at least within their organizations. Gradually it would
get to wider use. Why should we deny this? What's lost, if it turns out
that nobody wanted this feature?
> ...when in addition, we reap such a cost in terms of confusion and
> trouble.
You have told this over and over. Can you justify your claims in any
way? I'd like to see some constructive discussion of the matter.
Risto
- --
Risto Kankkunen kankkune@cs.Helsinki.FI (Internet)
Department of Computer Science kankkunen@finuh (Bitnet)
University of Helsinki, Finland ..!mcsun!uhecs!kankkune (UUCP)
------- Message 2
To: Risto Kankkunen <kankkune@cs.helsinki.fi>
cc: Einar Stefferud <stef@nrtc.northrop.com>
Subject: Re: A multiple bodypart multiple content type message
In-reply-to: Your message of Tue, 19 Feb 91 02:13:01 +0200.
<9102190013.AA00689@keos.Helsinki.FI>
Date: Tue, 19 Feb 91 14:31:45 PST
From: Dave Crocker <dcrocker>
Risto,
The facile response to some of your questions would be a quiet sigh, with
a shrug of the shoulders, and the comment that all of this is as difficult
as we are saying, ... well, because that has been our experience.
But I somehow suspect that you want a little more detail than that...
The key issue, in developing an enhancement to 821/822 is the installed
base. The inertia that is represented by the existence of an installed
base usually is vastly underestimated. But the current users cannot be
ignored, and dealing with them usually cannot be done trivially.
Hence, we must take, as a firm given, the fact that there will continue to
be many users and systems which use the current 821/822 system, which means
7-bit, flat body.
To enhance this, we can define a brand new system and try to gateway between
them, or we can add the new features in an upward compatible fashion.
The first means, in effect, planning to replace the email infrastructure with
the new stuff. To believe that that really will happen, we need to believe
that the new stuff is VERY SUBSTANTIALLY superior to the old stuff. And I
don't believe that the work being discussed will be sufficient for that. Note,
for example, how slowly the world is switching over to X.400, and it certainly
attempts to be very substantially better than 821/822. The main point, here,
is that it is difficult to guarantee that people will switch.
On the other hand, if we define the upgrade as upwardly compatible, then we
keep all of the current infrastructure, and people can upgrade whenever it is
convenient. Until then, they get messages that can be processed by current
software. They get all of the old benefit, and none of the new. BUT NOTHING
BREAKS!
As to the issue of better efficiency, by using the 8th bit, I will tell you
that you will get vastly better data compression by using registered serial
numbers for field names -- i.e., going to numeric encoding of structured
information -- in the headers of messages. I did an analysis of this, about
15 years ago, and was shocked at the percentage of most messages that is
taken just by header names.
In other words, if we are going to improve storage/transmission/etc. efficiency,
we need to be careful. Simply turning 821 into an 8-bit protocol won't
be sufficient. It won't even be overly helpful. The philosophy behind
821/822 has always been simple-over-clever. If we had wanted to develop
a truly sexy email spec, it would have looked vastly different.
Enhancing 822 to allow standardized encoding of new data types and adding
structuring to the body, on the other hand, reflects the kinds of private
enhancements that already have been done. Hence, there is good reason to
believe that the user community will WANT and DEMAND conversion over to
these features, especially if the conversion can be done gradually.
As to the 2x2 matrix, simply try plotting out how to maintain the information
that says who gets what format.
Anyhow, hopes this helps.
Dave
------- Message 3
To: kankkune@cs.Helsinki.FI (Risto Kankkunen)
Subject: Re: A multiple bodypart multiple content type message
In-reply-to: Your message of Wed, 20 Feb 91 13:51:39 +0200.
<9102201151.AA11542@keos.Helsinki.FI>
Date: Wed, 20 Feb 91 14:05:08 PST
From: Dave Crocker <dcrocker>
My point is that the kind of scheme that you are
proposing will not have the benefit you expect,
since the sender STILL must be able to communicate
with a recipient that doesn't have the new capability.
"...If the sender-MTA notices that the receiver can't take the message as it
is, it encodes it with some standard method..."
Well, that 'some standard method' is a second mechanism
for sending the same information. Hence, we now have
to have two standards. We have to choose one in real
time and have to make the conversion in real time.
Further, I am trying to avoid the round-trip interaction
overhead of the query about the binary option. This
issue is far more important than people seem to be
realizing. Extra transaction overhead, in a large-scale
system, is very expensive to aggregate throughput.
I believe that it is entirely reasonable to pursue
pure-binary transport and encoding, but only as a
separate and longer-term activity. And I think that
such an activity will need to indicate why it isn't
just as well to switch over to X.400.
As with Stef, I suggest that further discussion be
within the group.
Dave
------- Message 4
Return-Path: kankkune@cs.Helsinki.FI
Received: by nsl.pa.dec.com; id AA13372; Wed, 20 Feb 91 13:41:32 -0800
Received: by uucp-gw-1.pa.dec.com; id AA07612; Wed, 20 Feb 91 13:30:00 -0800
Received: by keos.Helsinki.FI (4.1/SMI-4.1/34-keos)
id AA11542; Wed, 20 Feb 91 13:51:39 +0200
Date: Wed, 20 Feb 91 13:51:39 +0200
From: kankkune@cs.Helsinki.FI (Risto Kankkunen)
Message-Id: <9102201151.AA11542@keos.Helsinki.FI>
In-Reply-To: Dave Crocker's message as of Feb 19, 14:31
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: Dave Crocker <dcrocker>
Subject: Re: A multiple bodypart multiple content type message
Thanks for your constructive letter.
> On the other hand, if we define the upgrade as upwardly compatible, then we
> keep all of the current infrastructure, and people can upgrade whenever it is
> convenient. Until then, they get messages that can be processed by current
> software. They get all of the old benefit, and none of the new. BUT NOTHING
> BREAKS!
>From this I gather you think that the binary system wouldn't be upwardly
compatible. I think it would be. Can you tell otherwise?
In case it isn't clear what I'd like to be done: A new mailer that can
send binary asks the the receiving MTA, if it can also. This can be done
in a number of ways (after hello send "ICAN binary" and then wait for
the answer, or try to send the data using command "D8TA" instead of
"DATA" and see, if the receiver accepts). If the receiver is an old kind
of mailer, the sender encodes the message, adds a suitable Content-type
- -header and sends the stuff. I think this wouldn't break anything.
> As to the issue of better efficiency, by using the 8th bit, I will tell you
> that you will get vastly better data compression by using registered serial
> numbers for field names -- i.e., going to numeric encoding of structured
> information -- in the headers of messages. I did an analysis of this, about
> 15 years ago, and was shocked at the percentage of most messages that is
> taken just by header names.
This probably is the case, as most of the mail messages tend to be
short. I think that with multimedia (pictures, finished documents with
illustrations etc.) the message size is going to increase. It is in
these cases the encoding becomes painful as it increases the message
size considerably. It also means that the document may need to be split
to multiple parts by the user to get it through, etc.
This seems silly, as most of the sites would be capable of handling
unencoded messages, and many probably would, if there were a standard
way of doing it. I think someone would pretty quickly hack a binary-
capable mailer for unix. This would make it possible for a large number
of sites to upgrade quite easily, if they want.
> As to the 2x2 matrix, simply try plotting out how to maintain the information
> that says who gets what format.
I think the binary capability wouldn't make this any harder (there
wouldn't be 2x2 matrix).
If the sender-MTA notices that the receiver can't take the message as it
is, it encodes it with some standard method and adds a header telling
this method. If the sender was 7-bit, the user would have done the same.
So, the receiver doesn't notice any difference whether the message came
from an old or new one.
Risto
- --
Risto Kankkunen kankkune@cs.Helsinki.FI (Internet)
Department of Computer Science kankkunen@finuh (Bitnet)
University of Helsinki, Finland ..!mcsun!uhecs!kankkune (UUCP)
------- End of Forwarded Messages