home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / internat / 886 < prev    next >
Encoding:
Internet Message Format  |  1992-12-17  |  2.9 KB
  1. Xref: sparky comp.std.internat:886 news.admin.misc:811
  2. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!att!allegra!alice!andrew
  3. From: andrew@alice.att.com (Andrew Hume)
  4. Newsgroups: comp.std.internat,news.admin.misc
  5. Subject: Re: 8-bit representation, plus an X problem
  6. Summary: clarification
  7. Keywords: ISO8859-1 CP850 fidonet gateway
  8. Message-ID: <24426@alice.att.com>
  9. Date: 17 Dec 92 05:36:10 GMT
  10. Article-I.D.: alice.24426
  11. References: <171@complex.complex.is> <eaRsVB2w165w@blues.kk.sub.org> <1gnemoEINN3qo@uni-erlangen.de>
  12. Organization: AT&T Bell Laboratories, Murray Hill NJ
  13. Lines: 50
  14.  
  15. In article <1gnemoEINN3qo@uni-erlangen.de>, unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn) writes:
  16. > ...
  17. > in the above pipeline. I heard roumors, that the Plan 9 UTF version will
  18. > be added as UTF-2 to an ISO 10646 annex, can anyone confirm this? Perhaps
  19.  
  20.     firstly, 10646 is cast in concrete right now. there will
  21. be no changes for at least a year or two or three.
  22.  
  23.     secondly, the UTF encoding is now formally called UTF-1.
  24.  
  25.     thirdly, the Plan 9 encoding is the same as the FSS-UTF
  26. encoding being considered for adoption by X/Open as the
  27. recommended encoding for 10646 text streams. (i believe it
  28. has been approved by the technical committee and is wending
  29. its way through some process inside X/Open.)
  30.  
  31.     fourthly, if as we expect X/Open adopts FSS-UTF, it will
  32. be proposed as an addition to 10646 as an alternate UTF encoding
  33. (presumably called UTF-2 -- we have heard of no other encodings).
  34. This could be done relatively quickly and expeditiously if ISO
  35. so desired; otherwise, it will wait until the next time someone tweaks
  36. 10646.
  37.  
  38. > we really should wait as suggested by Randall Atkinson for the final
  39. > version of ISO 10646 before starting to include anything new (e.g.
  40. > a 16-bit encoding) in MIME.
  41.  
  42.     this won't help. the character assignments are known; translation
  43. tools exist (i have nearly got permission for public release of the
  44. Plan 9 translation stuff); and the ISO-blessed encoding (UTF-1) is known.
  45.  
  46. > Of course. But USENET users will have difficulties in understanding this,
  47. > as there isn't currently anything like a presentation layer (as defined in the
  48. > OSI reference model) that performs the conversion between the local
  49. > representation (e.g. I prefer Latin 1 files) and the encoding used on
  50. > the network (e.g. any 8-bit encoding on news and 7-bit encoding on
  51. > email). ...
  52.  
  53.     maybe some usenet users will have difficulties. i suspect most
  54. won't. but in any case, they oughtn't have to know! mail has
  55. always struct me as one of the easiest programs to control in this way
  56. as typically all mail leaves and enters a system through a couple
  57. of programs. and conceptually, those programs could easily and
  58. transparently handle conversion to and from a transport format/encoding.
  59.  
  60.     right now, we have the transport model/encoding and conversion
  61. stuff; all we lack are the conventions to get 8-bits thru cleanly
  62. and to do the translations.
  63.  
  64.             andrew
  65.