🚀 go-pugleaf

In article <CKD.92Dec15185902@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>Not if the standard specifies 7-bit NETASCII.  Most header standards
>(certainly '822 and '1036) allow for user-defined and future headers.  (If
>I put X- in front of all my 8-bit data, does that work? :)

What's the difference between putting X- to the header line and
adding 0200 to the character code?

>To stretch a point, dumping core could be considered an
>implementation-dependent behavior :)

Yep, exactly. I know one mailer which craches on RFC-822 groups.
And what? Garbadge remains garbadge. Somehow nobody's proposing
to add a new header field for every bug in every mail agent.

> VA> "Just send 8 bits" *is* backward compatible. Check your logic.
>
>It's not backward compatible, because the standard says 7 bits, and some
>software will enforce that (either by clipping the 8th bit, or dumping
>core).  If I get "550 EMAL: command unrecognized" and then convert the body
>to quoted-printable, that's backward compatible.  If I get "Connection
>closed" and try it again every half hour (generating a core dump each
>time), that's not.

C'mon. If you got a character with 8th bit set and the standard
says you shouldn't you can respond with "555 America uber alles"
and everything will be ok. The fact that RFC822 does not require
this behavious is nothing more than a hole in the standard.
Not the first, not the last.

So far, all wide-spread software simply zeroes the meta-bit which
surely is not a reason to propose a new extention to the already
bloated stuff.

> VA> Then why on the Earth did you upgrade your software the last time?
>
>Because it gave me better configuration flexibility than the old version,
>and was more robust, and followed the SMTP standard.

Really? If a standard does not reflect the real life it is not the
life which should be changed. As i already said a lot of people
in Europe already closed that discussion using the simpliest
solution. As every simple solution it's easy to implement (no need
to write new code -- just *remove* some old), it works (for
couple dozens of countries) and it provides easy way for future
extensions (aka UTF -- it you have 8-bit transparency now it'll
be really easy to switch to UTF tomorrow).

Now, imagine what will happen if some eggheads will come up with the
standard demanding adding yet another encoding for those characters --
vendors will have to add new code, some software authors will find
that it requires changing the entiore structure of their algorithms;
there will be various "interpretations" (want examples? look at
"uuencode" postings on USENET) and at the year 2100 survivors will
finally see the death of the last 7-bit mailer.

And THAT is what do propose in exchange for doubtful convinience of
owners of 7-bit links (who has one anyway? UUCP - 8 bit, TCP/IP - 8 bit,
X.25 - 8 bit) who will need to fix their software anyway. I'd prefer
*them* to solve the problem of transparency instead of having
*everybody* to add code for another sloppy encoding.

Why don't you argue FOR adding another header field for allowing
the poor souls with EBCDIC to get out without transliterating?
What about 80-byte records? X-Lines-Splitted, yeah? You have to agree
that there are obsolete technologies which are cheaper to discard
than to continue support. 7-bit characters is SURELY one of them.

JUST SAY NO TO 7-BIT ENCODINGS

--vadim

"Cause of death: a system utterly drained of vitality by the
 constant struggle of fighting the diseases.

 One can only speculate on the mental health of the patient."
				-- Rob Pike on Unix