> I see a lot of merit in a scheme that would leave the message in > the recipient's reader in untranslated ASCII (no informaton lost!) > and leave the EBCDIC rendering to the viewer (PEEK) or extractor > (RECEIVE). If the recipient doesn't like what he sees, he can > PEEK again with different rendering options, or forward to a > UTF-8 savvy workstation.
Email originally was "local plaintext". The more commonly known systems (to a certain public; eg: Unix and VMS, others?) were ASCII, but were not consistent in such things as record boundaries (NL? CR+LF? out of band?). And there were plenty of EBCDIC boxes (both VM and MVS ... maybe VSE, certainly things like MUSIC). If you wanted to play, you learned to play nice. As email got fancier, some far sighted people cooked up MIME. The encodings are more than sufficient to leave the message in the recipient's reader, albeit encoded. (I like Base64, but QP should do too.) The trouble is, if it's a MESSAGE and not an ATTACHMENT then it would be nice if it were readable (which B64 clearly is not and even QP is really not) with existing tools. I fear that the next phase for email will be not only UTF-8 but also XML. Both good things. Both easily misused. (Something about guns and feet, but other people's feet, not just their own. Ouch!) You also said ... > I hate EBCDIC! I think what you really hate is the unfortunate consequence of 60s thinking w/r/t nationalization. The blind spot was that whoever at IBM cooked up the original national character set scheme never thought that some of us might use more code points than our local language demands. Or worse ... actually CONNECT computers from different countries. These days, it's INTERnationalization and INTERnet. I wish our forefathers had thought ahead. -- R; <>< On Sat, Mar 6, 2010 at 20:05, Paul Gilmartin <[email protected]> wrote: > On Mar 6, 2010, at 15:34, Bob Cronin wrote: > >> Oh and I believe that your specific example would require VM SMTP to be >> configured with the DBCS statement with SJISKANJI as the value. If you did >> that, it would have converted the incoming ASCII to EBCDIC 939 (but would >> likely have left the headers alone). >> > the character set translated-to really ought to be documented in > a "Content-type: text/???; charset=IBM???" header so that if your > guess doesn't match the recipient's expectation, he has a chance > to recover by refiltering. > > But what to use for a last resort EBCDIC encoding without information > loss? The dreaded and widely shunned UTF-EBCDIC? > > I see a lot of merit in a scheme that would leave the message in > the recipient's reader in untranslated ASCII (no informaton lost!) > and leave the EBCDIC rendering to the viewer (PEEK) or extractor > (RECEIVE). If the recipient doesn't like what he sees, he can > PEEK again with different rendering options, or forward to a > UTF-8 savvy workstation. > > Back on charter: Wnat pipelines stages manipulate Unicode? > > -- gil >
