home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / internat / 862 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  3.2 KB

  1. Xref: sparky comp.std.internat:862 news.admin.misc:770
  2. Newsgroups: comp.std.internat,news.admin.misc
  3. Path: sparky!uunet!usc!sol.ctr.columbia.edu!eff!ckd
  4. From: ckd@eff.org (Christopher Davis)
  5. Subject: Re: 8-bit news
  6. In-Reply-To: avg@rodan.UU.NET's message of 15 Dec 1992 18:20:45 -0500
  7. Message-ID: <CKD.92Dec15185902@loiosh.eff.org>
  8. Sender: usenet@eff.org (NNTP News Poster)
  9. Nntp-Posting-Host: loiosh.eff.org
  10. Organization: Electronic Frontier Foundation Tech Central
  11. References: <Bz9Bw3.2I6@ra.nrl.navy.mil> <89RsVB3w165w@blues.kk.sub.org>
  12.     <CKD.92Dec15161747@loiosh.eff.org> <1glp8dINN4sc@rodan.UU.NET>
  13. Date: Tue, 15 Dec 1992 23:59:05 GMT
  14. Lines: 53
  15.  
  16. VA> == Vadim Antonov <avg@rodan.UU.NET>
  17.  
  18.  VA> "Just send 8 bits" is the proper superset of "just send 7 bits"
  19.  VA> -- exactly the same as adding new header fields. It breaks nothing
  20.  VA> as long as you do not use extensions.
  21.  
  22. Not if the standard specifies 7-bit NETASCII.  Most header standards
  23. (certainly '822 and '1036) allow for user-defined and future headers.  (If
  24. I put X- in front of all my 8-bit data, does that work? :)
  25.  
  26.  ckd> I'm certainly not insensitive to the needs of languages that don't
  27.  ckd> fit in USASCII.  However, I'm also not insensitive to the needs of
  28.  ckd> sites that could care less about 8-bit characters, have
  29.  ckd> vendor-supplied software that blows up on 8-bit data, and aren't
  30.  ckd> prepared to upgrade immediately.
  31.  
  32.  VA> If the vendor-software crashes on, say, a file with 1025-byte line
  33.  VA> it's a bug, isn't it? If a program craches on ANYTHING it's a bug.  A
  34.  VA> bug is a bug is a bug. Call their tech support and have them to fix
  35.  VA> it.
  36.  
  37. And if the standard says "<protocol> data is 7-bit NETASCII." and something
  38. claiming to be doing that protocol sends 8-bit ISO-8859-1 data, that's a
  39. bug too.  Sure, the software *should* gracefully deal with it in an
  40. implementation-defined manner (since the standards currently don't cover
  41. the situation).  To stretch a point, dumping core could be considered an
  42. implementation-dependent behavior :)
  43.  
  44.  ckd> As soon as there's a compatible SMTP extension for 8 bits, I'll at
  45.  ckd> least try to hack it into my mailer (assuming the UIUC IDA sendmail
  46.  ckd> folks don't beat me to it).
  47.  
  48.  VA> "Just send 8 bits" *is* backward compatible. Check your logic.
  49.  
  50. It's not backward compatible, because the standard says 7 bits, and some
  51. software will enforce that (either by clipping the 8th bit, or dumping
  52. core).  If I get "550 EMAL: command unrecognized" and then convert the body
  53. to quoted-printable, that's backward compatible.  If I get "Connection
  54. closed" and try it again every half hour (generating a core dump each
  55. time), that's not.
  56.  
  57.  ckd> But I won't install anything that tries to pull a Nike and
  58.  ckd> "Just Do It" to some unsuspecting mailer somewhere.
  59.  
  60.  VA> Then why on the Earth did you upgrade your software the last time?
  61.  
  62. Because it gave me better configuration flexibility than the old version,
  63. and was more robust, and followed the SMTP standard.
  64. --
  65. Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
  66. <ckd@eff.org>   EFF #14   |   for the TV generation, Klingon) high command.
  67. System Administrator, EFF |   Whoever takes action and can be heard wins.''
  68. +1 617 864 0665  [CKD1]   |   --Peter da Silva <peter@ferranti.com>
  69.