On 18 Mar 93 01:49:05 EST, Al Costanzo wrote:
There is absolutely nothing wrong with using line count. It works.
show me a mailer that will have a problem with line count and I will
consider a change...
This question was gone over in huge nauseating detail two years ago. Please
see the series of messages with subject ``What is a line?'' in the WG
archives.
Line counts do not work.
There are two fundamental problems with line counts:
1) there are gateways which reformat messages and thus add or remove line
breaks
2) what constitutes a ``line'' is an operating system dependent matter.
All the world is not UNIX. Some people are going to get a harsh shock when NT
comes out. A piece of data which ``obviously'' has n lines may ``obviously''
have n +/- m lines on some other operating system. Although Internet clearly
defines what a ``line'' is, it is regrettably --> **NOT** <-- the case that
there is a reversible transform between Internet format and local OS format
for several operating systems, including UNIX.
It is not possible on several operating systems, *INCLUDING* UNIX, to
determine what the ``10th line'' of a message is with any certainty.
I generated textual data which demonstrates this problem in RFC-1154.
This is a show-stopper.
I contacted Messrs Robinson and Ullman about this problem a long time ago,
when I first implemented RFC-1154. At the time, I entertained a false hope
that RFC-1154 could be fixed and made useful. I got back a rather arrogant
reply that said in effect that I didn't know what I was talking about. 15+
years of e-mail software development should give me some notion of what I am
talking about.
The upshot of all of this is that I came to realize that RFC-1154 was a dead
end. I abandoned it, and joined the MIME effort. All vestiges of RFC-1154
support were erased from my API long ago, which is the basis of several
commercial and public e-mail packages. RFC-1154 support is not coming back.
Similarly, RFC-1154 support was withdrawn from the IMAP2bis protocol in favor
of MIME, and is not coming back.
- only supports the "full range of the ASCII character set"
What is the problem here?
Please tell me how I am to send e-mail in Japanese. Are you telling me I am
no longer allowed to communicate with my colleagues in To^kyo^?
Let's make it easier, since I doubt you have investigated the technical issues
in sending Japanese e-mail.
Please tell me how I am to send mail in any European language that uses
characters outside of ASCII, keeping in mind the fact that there are at least
10 different overlapping character sets for European languages, and choosing
any one of these would have the effect of locking out the others.
- has no way to support lines of more than "reasonable length" (i.e. 1000
octets)
Please elaborate on the problem.
The problem is as stated. How do I send text which contains lines of more
than 1000 characters/line in an undamaged fashion, considering that SMTP says
that 1000 characters/line is the maximum?
I'm not asking whether or not you think I should do it. I'm asking you how I
should send perfectly reasonable text that just happens to have long lines in
it.
- has no body part structuring other than `message' body parts
Please show me a need and I will consider it.
How do I represent a collection of objects in the message that logically
belong together, and where I have multiple collections?
For example, suppose I have a set of files that I am sending, with separate
versions in English, Japanese, and German? I want a separate set for each
language, with members inside the set.
The only way to do this in RFC-1154 is to make these be separate messages
which has even more ``extra ugly headers'' that you protest against so much in
MIME.
FS encoding was born on a Prime 50 Series.
I *knew* it. Sooner or later we would see the connection to (late unlamented)
Prime Computer. It's like cockroaches, you think you've killed them all but
they pop out of the woodwork as soon as your back is turned.