home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / internat / 863 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  4.0 KB
  1. Xref: sparky comp.std.internat:863 news.admin.misc:772
  2. Path: sparky!uunet!not-for-mail
  3. From: avg@rodan.UU.NET (Vadim Antonov)
  4. Newsgroups: comp.std.internat,news.admin.misc
  5. Subject: Re: 8-bit news
  6. Date: 15 Dec 1992 19:42:36 -0500
  7. Organization: UUNET Technologies Inc, Falls Church, VA
  8. Lines: 77
  9. Message-ID: <1glu1sINNoth@rodan.UU.NET>
  10. References: <CKD.92Dec15161747@loiosh.eff.org> <1glp8dINN4sc@rodan.UU.NET> <CKD.92Dec15185902@loiosh.eff.org>
  11. NNTP-Posting-Host: rodan.uu.net
  12.  
  13. In article <CKD.92Dec15185902@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
  14. >Not if the standard specifies 7-bit NETASCII.  Most header standards
  15. >(certainly '822 and '1036) allow for user-defined and future headers.  (If
  16. >I put X- in front of all my 8-bit data, does that work? :)
  17.  
  18. What's the difference between putting X- to the header line and
  19. adding 0200 to the character code?
  20.  
  21. >To stretch a point, dumping core could be considered an
  22. >implementation-dependent behavior :)
  23.  
  24. Yep, exactly. I know one mailer which craches on RFC-822 groups.
  25. And what? Garbadge remains garbadge. Somehow nobody's proposing
  26. to add a new header field for every bug in every mail agent.
  27.  
  28. > VA> "Just send 8 bits" *is* backward compatible. Check your logic.
  29. >
  30. >It's not backward compatible, because the standard says 7 bits, and some
  31. >software will enforce that (either by clipping the 8th bit, or dumping
  32. >core).  If I get "550 EMAL: command unrecognized" and then convert the body
  33. >to quoted-printable, that's backward compatible.  If I get "Connection
  34. >closed" and try it again every half hour (generating a core dump each
  35. >time), that's not.
  36.  
  37. C'mon. If you got a character with 8th bit set and the standard
  38. says you shouldn't you can respond with "555 America uber alles"
  39. and everything will be ok. The fact that RFC822 does not require
  40. this behavious is nothing more than a hole in the standard.
  41. Not the first, not the last.
  42.  
  43. So far, all wide-spread software simply zeroes the meta-bit which
  44. surely is not a reason to propose a new extention to the already
  45. bloated stuff.
  46.  
  47. > VA> Then why on the Earth did you upgrade your software the last time?
  48. >
  49. >Because it gave me better configuration flexibility than the old version,
  50. >and was more robust, and followed the SMTP standard.
  51.  
  52. Really? If a standard does not reflect the real life it is not the
  53. life which should be changed. As i already said a lot of people
  54. in Europe already closed that discussion using the simpliest
  55. solution. As every simple solution it's easy to implement (no need
  56. to write new code -- just *remove* some old), it works (for
  57. couple dozens of countries) and it provides easy way for future
  58. extensions (aka UTF -- it you have 8-bit transparency now it'll
  59. be really easy to switch to UTF tomorrow).
  60.  
  61. Now, imagine what will happen if some eggheads will come up with the
  62. standard demanding adding yet another encoding for those characters --
  63. vendors will have to add new code, some software authors will find
  64. that it requires changing the entiore structure of their algorithms;
  65. there will be various "interpretations" (want examples? look at
  66. "uuencode" postings on USENET) and at the year 2100 survivors will
  67. finally see the death of the last 7-bit mailer.
  68.  
  69. And THAT is what do propose in exchange for doubtful convinience of
  70. owners of 7-bit links (who has one anyway? UUCP - 8 bit, TCP/IP - 8 bit,
  71. X.25 - 8 bit) who will need to fix their software anyway. I'd prefer
  72. *them* to solve the problem of transparency instead of having
  73. *everybody* to add code for another sloppy encoding.
  74.  
  75. Why don't you argue FOR adding another header field for allowing
  76. the poor souls with EBCDIC to get out without transliterating?
  77. What about 80-byte records? X-Lines-Splitted, yeah? You have to agree
  78. that there are obsolete technologies which are cheaper to discard
  79. than to continue support. 7-bit characters is SURELY one of them.
  80.  
  81. JUST SAY NO TO 7-BIT ENCODINGS
  82.  
  83. --vadim
  84.  
  85. "Cause of death: a system utterly drained of vitality by the
  86.  constant struggle of fighting the diseases.
  87.  
  88.  One can only speculate on the mental health of the patient."
  89.                 -- Rob Pike on Unix
  90.