home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.std.internat:862 news.admin.misc:770
- Newsgroups: comp.std.internat,news.admin.misc
- Path: sparky!uunet!usc!sol.ctr.columbia.edu!eff!ckd
- From: ckd@eff.org (Christopher Davis)
- Subject: Re: 8-bit news
- In-Reply-To: avg@rodan.UU.NET's message of 15 Dec 1992 18:20:45 -0500
- Message-ID: <CKD.92Dec15185902@loiosh.eff.org>
- Sender: usenet@eff.org (NNTP News Poster)
- Nntp-Posting-Host: loiosh.eff.org
- Organization: Electronic Frontier Foundation Tech Central
- References: <Bz9Bw3.2I6@ra.nrl.navy.mil> <89RsVB3w165w@blues.kk.sub.org>
- <CKD.92Dec15161747@loiosh.eff.org> <1glp8dINN4sc@rodan.UU.NET>
- Date: Tue, 15 Dec 1992 23:59:05 GMT
- Lines: 53
-
- VA> == Vadim Antonov <avg@rodan.UU.NET>
-
- VA> "Just send 8 bits" is the proper superset of "just send 7 bits"
- VA> -- exactly the same as adding new header fields. It breaks nothing
- VA> as long as you do not use extensions.
-
- 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? :)
-
- ckd> I'm certainly not insensitive to the needs of languages that don't
- ckd> fit in USASCII. However, I'm also not insensitive to the needs of
- ckd> sites that could care less about 8-bit characters, have
- ckd> vendor-supplied software that blows up on 8-bit data, and aren't
- ckd> prepared to upgrade immediately.
-
- VA> If the vendor-software crashes on, say, a file with 1025-byte line
- VA> it's a bug, isn't it? If a program craches on ANYTHING it's a bug. A
- VA> bug is a bug is a bug. Call their tech support and have them to fix
- VA> it.
-
- And if the standard says "<protocol> data is 7-bit NETASCII." and something
- claiming to be doing that protocol sends 8-bit ISO-8859-1 data, that's a
- bug too. Sure, the software *should* gracefully deal with it in an
- implementation-defined manner (since the standards currently don't cover
- the situation). To stretch a point, dumping core could be considered an
- implementation-dependent behavior :)
-
- ckd> As soon as there's a compatible SMTP extension for 8 bits, I'll at
- ckd> least try to hack it into my mailer (assuming the UIUC IDA sendmail
- ckd> folks don't beat me to it).
-
- 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.
-
- ckd> But I won't install anything that tries to pull a Nike and
- ckd> "Just Do It" to some unsuspecting mailer somewhere.
-
- 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.
- --
- Christopher K. Davis | ``Usenet seems to run much like the Kif (or,
- <ckd@eff.org> EFF #14 | for the TV generation, Klingon) high command.
- System Administrator, EFF | Whoever takes action and can be heard wins.''
- +1 617 864 0665 [CKD1] | --Peter da Silva <peter@ferranti.com>
-