Path: utzoo!utgpu!watserv1!watmath!att!bu.edu!rpi!julius.cs.uiuc.edu!wuarchive!uunet!looking!brad From: brad@looking.on.ca (Brad Templeton) Newsgroups: news.software.b Subject: Re: New USENET header: Language Message-ID: <1991Jan03.061359.8706@looking.on.ca> Date: 3 Jan 91 06:13:59 GMT References: <1990Dec29.093002.10739@lth.se> <91B+H%A@b-tech.uucp> <1990Dec30.095938.23011@lth.se> <4ef9aa39.1bc5b@pisa.ifs.umich.edu> Organization: Looking Glass Software Ltd. Lines: 38 In article <4ef9aa39.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >I'll have to plead guilty of getting us off the track. Brad just wanted >some way to skip articles written in French because he doesn't read French. >I now understand that this is orthogonal to the issue of character sets. Well, I can read French ... mostly, and certainly not as well as I could when I left school, however it does take a lot more work so I might still want to skip such articles. I can't read Italian, however, and the group trial.soc.culture.italian is full of postings in that language. However, I would be upset if my suggestion of a human-language header caused the creation of an encoding header that supported large numbers of character set encodings. If we allow multiple encodings we only complicate all the software, or create a set of postings that can't be read very widely by the computers, not just the humans. One or two official encodings beyond ASCII, at best, are all we should dare. In fact, I would try to kill many birds with one stone and say that the extra encoding should be a rich text format that supports, aside from unusual characters, formatting codes etc. Perhaps even the microsoft RTF with international charset extensions as we wish. If somebody writes a nice decoding pager for this format, then all newsreaders can use that at the very least for such files, even if it's slow to call a remote program. We don't want to generate a large set of postings that lots of people can't even decode because their software doesn't support 10 otherwise isomorphic encoding methods. In summary, multiple encoding methods should be defined only when they provide new features. There is no point in supporting two ways of doing the same thing. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473