[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Character code sets and all that
On Thu, 31 Jan 91 16:54:29 -0600 you said:
> It is a fact of life, no matter how much you dislike it, that there are
>lots of IBM systems out there generating lots of mail, with a definition
>of line which prohibits completely empty lines. They insist on at least
>one blank, and sometimes of card image format with 80 blanks. You may
>not like it, and I may not like it, but no mail transfer standard is ever
>going to be widely accepted if it cannot handle BITNET mail from IBM hosts.
I happen to be paid to care for one of these IBM beasts that has trouble
with null lines. I'm *quite* aware of the problem. My *point* was that
the RFC should have been written in such a way that you had a
*unambiguous* definition of 'apparently blank line'.
In specific, my objection to the RFC as written is in section 3.2, where
it defines <count>. Unfortunately, they do NOT do a very good job of
defining exactly what the terms 'text line' or 'blank line' mean. Back
in RFC822, they were *quite* explicit in defining 'null line' in section
3.1, and 'LWSP-char' and 'linear-white-space' in section 3.3.
Now, if RFC1154 gave a similarly clear definition of 'blank', there
would not be a problem.
Consider that my IBM 3090 thinks that an 80-byte record consisting of 40
pairs of the octets CR and LF is one line. Given the wording of RFC1154
as written, another site is quite proper to consider this as 40 blank
So much for the count being anywhere NEAR right.
Imagine if RFC822 had define 'null line' as leniently. Wonder how long
it would have taken before all mailers were able to recognize the "null
line" seperating the headers from the body?
Computer Systems Engineer
Virginia Polytechnic Institute
P.S. As usual, I'm just presenting *my* viewpoint. If you have an urge
to associate my opinion with our official policy, please lay down till the