Re: e-mail, character sets, encodings (was Re: George Keremedjiev)
On 2018-11-25 7:45 PM, Bill Gunshannon via cctalk wrote: > It's not a mailing list problem. It's not even a mail problem. It's a > > Mail User Agent problem. It is a display problem. It is up to the > > users mail program to display the email as it was sent. Unless the > Did you really double space this email like a high school essay? Don't see that every day. --T
Re: e-mail, character sets, encodings (was Re: George Keremedjiev)
It's not a mailing list problem. It's not even a mail problem. It's a Mail User Agent problem. It is a display problem. It is up to the users mail program to display the email as it was sent. Unless the user doesn't want to see anything in character sets other than their favorite. Nothing along the way should change anything in an email message. The endpoint should receive whatever the beginning point sent out and either handle it or not. But it is the endpoints responsibility to try to display it accurately. I often send emails (and post on USENET) characters that are not a part of ASCII or the English alphabet. I certainly don't want someone in between to modify what I send. bill On 11/25/18 7:00 PM, ED SHARPE via cctalk wrote: > Hi Frank and others- > Yea it is only here we have the problem. or at leased this is the > only list serve that does not like it. > > I wondered if something could be handled at the listserv end or not > but I have littleknowledge of list serves alas... > > Sad when people spent more time on characters rather than George the > museum archivist that passed away. > > > George worked his ass off to achieve what he did. > > Google him and read about his early days. You will be surprised and > you might find yourself thankful for how easy you had it. > > I did not know him all that well but I did provide his PDP-8 classic > with the plexis when He was first starting up It was a beauty and in the > 200 serial number range as I remember. We kept #18 classic Plexi for > SMECC > > I had not planned on selling it as always handy to have a #2 for an > offsite display and you do not have to disturb the in-house display but > George seems so focused and intense on making a museum too so who > could say no to that? I wish I had. traveled to see his effort up > close. > > Project this week is to find someone one with a UNIVAC 422 or the > predecessor UNIVAC Digital trainer. I can NOT BELIEVE I am fortunate enough > to be the only one with a UNIVAC 422' > > That is all for now... I think I hear a half of turkey and leftover > dressing in the refrig wailing to be consumed. > > Ed# www.smecc.org > > > > In a message dated 11/25/2018 4:32:34 PM US Mountain Standard Time, > cctalk@classiccmp.org writes: > > > Most mail servers sending inbound messages to the list include the encoding > > scheme in the header. The mailer program should process and translate the > email message body accordingly...in theory anyway. The set up and testing > of a sampling of encoding variations would reveal which interpreters were > missing in our particular list's relay process. Someone could create tests > with the most common 20 or so encoding schemes and a character set dump and > document the results etc. Anyone have the time for that? I dont really > think asking persons to fix their email program is the solution, it's a > mailing list fix/enhancement. I bet there is documentation on such a > procedure I can't imagine we are the first to encounter this problem. It's > fixable > B > > On Sun, Nov 25, 2018, 3:24 PM Frank McConnell via cctalk < > cctalk@classiccmp.org wrote: > >> Very old mail programs indeed have no understanding whatsoever of >> character sets or encoding. They simply display data from the e-mail file >> on stdout or equivalent. If you are lucky, the character set and encoding >> in the e-mail match the character set and encoding used by your terminal. >> >> The early-to-mid-1990s MIME work was in some part about allowing e-mail to >> indicate its character set and encoding, because at that point in time >> there were many character sets and multiple encodings. Before that, you >> had to figure them out from your correspondent's e-mail address and the >> mess on your screen or printout. >> >> And really it's not just about the mail program, it's about the host >> operating system and the hardware on which it runs and which you are using >> to view e-mail. Heavy-metal characters are likely to look funny on a >> terminal built to display US-ASCII like an HP 2645. Your chances get >> better if the software has enough understanding of various Roman-language >> text encodings and you are using an HP 2622 with HP-ROMAN8 character >> support and the connection between your host and terminal is >> eight-bit-clean. But then you get something that uses Cyrillic and now >> you're looking at having another HP 2645 set up to do Russian. And hoping >> your host software knows how to deal with those character sets and >> encodings too! >> >> -Frank McConnell >> >> On Nov 25, 2018, at 9:55, ED SHARPE via cctalk wrote: >>> seems only the very old mail programs do not adapt to all character >> sets? >>> >>> In a message dated 11/25/2018 6:19:52 AM US Mountain Standard Time, >> cctalk@classiccmp.org writes: >>> >>>
Re: e-mail, character sets, encodings (was Re: George Keremedjiev)
Hi Frank and others- Yea it is only here we have the problem. or at leased this is the only list serve that does not like it. I wondered if something could be handled at the listserv end or not but I have littleknowledge of list serves alas... Sad when people spent more time on characters rather than George the museum archivist that passed away. George worked his ass off to achieve what he did. Google him and read about his early days. You will be surprised and you might find yourself thankful for how easy you had it. I did not know him all that well but I did provide his PDP-8 classic with the plexis when He was first starting up It was a beauty and in the 200 serial number range as I remember. We kept #18 classic Plexi for SMECC I had not planned on selling it as always handy to have a #2 for an offsite display and you do not have to disturb the in-house display but George seems so focused and intense on making a museum too so who could say no to that? I wish I had. traveled to see his effort up close. Project this week is to find someone one with a UNIVAC 422 or the predecessor UNIVAC Digital trainer. I can NOT BELIEVE I am fortunate enough to be the only one with a UNIVAC 422' That is all for now... I think I hear a half of turkey and leftover dressing in the refrig wailing to be consumed. Ed# www.smecc.org In a message dated 11/25/2018 4:32:34 PM US Mountain Standard Time, cctalk@classiccmp.org writes: Most mail servers sending inbound messages to the list include the encoding scheme in the header. The mailer program should process and translate the email message body accordingly...in theory anyway. The set up and testing of a sampling of encoding variations would reveal which interpreters were missing in our particular list's relay process. Someone could create tests with the most common 20 or so encoding schemes and a character set dump and document the results etc. Anyone have the time for that? I dont really think asking persons to fix their email program is the solution, it's a mailing list fix/enhancement. I bet there is documentation on such a procedure I can't imagine we are the first to encounter this problem. It's fixable B On Sun, Nov 25, 2018, 3:24 PM Frank McConnell via cctalk < cctalk@classiccmp.org wrote: > Very old mail programs indeed have no understanding whatsoever of > character sets or encoding. They simply display data from the e-mail file > on stdout or equivalent. If you are lucky, the character set and encoding > in the e-mail match the character set and encoding used by your terminal. > > The early-to-mid-1990s MIME work was in some part about allowing e-mail to > indicate its character set and encoding, because at that point in time > there were many character sets and multiple encodings. Before that, you > had to figure them out from your correspondent's e-mail address and the > mess on your screen or printout. > > And really it's not just about the mail program, it's about the host > operating system and the hardware on which it runs and which you are using > to view e-mail. Heavy-metal characters are likely to look funny on a > terminal built to display US-ASCII like an HP 2645. Your chances get > better if the software has enough understanding of various Roman-language > text encodings and you are using an HP 2622 with HP-ROMAN8 character > support and the connection between your host and terminal is > eight-bit-clean. But then you get something that uses Cyrillic and now > you're looking at having another HP 2645 set up to do Russian. And hoping > your host software knows how to deal with those character sets and > encodings too! > > -Frank McConnell > > On Nov 25, 2018, at 9:55, ED SHARPE via cctalk wrote: > > > > seems only the very old mail programs do not adapt to all character > sets? > > > > > > In a message dated 11/25/2018 6:19:52 AM US Mountain Standard Time, > cctalk@classiccmp.org writes: > > > > > > > > > >> On Nov 21, 2018, at 4:46 PM, Bill Gunshannon via cctalk < > cctalk@classiccmp.org> wrote: > >> > >> > >>> On 11/21/18 5:19 PM, Fred Cisin via cctalk wrote: > >>> Ed, > >>> It is YOUR mail program that is doing the extraneous insertions, and > >>> then not showing them to you when you view your own messages. > >>> > >>> ALL of us see either extraneous characters, or extraneous spaces in > >>> everything that you send! > >>> I use PINE in a shell account, and they show up as a whole bunch of > >>> inappropriate spaces. > >>> > >>> Seriously, YOUR mail program is inserting extraneous stuff. > >>> Everybody? but you sees it. > >>> > >> > >> I don't. I didn't see it until someone replied with a > >> > >> copy of the offending text included. > >> > >> > >> bill > >> > > same here. i didnt see them until some replies included the text. > > > > kelly > > > >
Re: e-mail, character sets, encodings (was Re: George Keremedjiev)
On 11/25/18 4:32 PM, Bill Degnan via cctalk wrote: Most mail servers sending inbound messages to the list include the encoding scheme in the header. The mailer program should process and translate the email message body accordingly...in theory anyway. Most email handling programs don't need to bother with what the data is, as they just move the data. This largely includes email list managers. This really only becomes a concern if something is modifying part of the message (data) as it moves through the system. The set up and testing of a sampling of encoding variations would reveal which interpreters were missing in our particular list's relay process. cctalk is using Mailman, and I'm fairly sure that Mailman does handle this properly. Or if there is a bug it has likely been found & resolved. In the event that a bug is found, I think that it would be best to report it upstream to Mailman so they can fix it, and then install the updates when they are released. Someone could create tests with the most common 20 or so encoding schemes and a character set dump and document the results etc. Anyone have the time for that? I doubt that this is necessary. Based on what I've seen, Mailman is handling the message (data) just fine. It's passing the Ed's messages with the UTF-8 =C2=A0 (quoted-printable) encoded parts just fine. I dont really think asking persons to fix their email program is the solution I agree that it's asking an end user to fix their email client is the most viable solution. it's a mailing list fix/enhancement. I disagree. I'm not convinced that this is a problem in email. I question how many people are seeing the symptoms -and- what email client they are using. If someone knowingly chooses to use an email client that doesn't support UTF-8, then ¯\_(ツ)_/¯ That's their choice. I just hope that they are informed in their choice. I bet there is documentation on such a procedure I can't imagine we are the first to encounter this problem. It's fixable If you really do think that this is a problem with the mailing list, I'd suggest bringing the problem up on the Mailman mailing list. Mark S. is very responsive and can help people fix problems / configurations in short order. -- Grant. . . . unix || die
Re: e-mail, character sets, encodings (was Re: George Keremedjiev)
Most mail servers sending inbound messages to the list include the encoding scheme in the header. The mailer program should process and translate the email message body accordingly...in theory anyway. The set up and testing of a sampling of encoding variations would reveal which interpreters were missing in our particular list's relay process. Someone could create tests with the most common 20 or so encoding schemes and a character set dump and document the results etc. Anyone have the time for that? I dont really think asking persons to fix their email program is the solution, it's a mailing list fix/enhancement. I bet there is documentation on such a procedure I can't imagine we are the first to encounter this problem. It's fixable B On Sun, Nov 25, 2018, 3:24 PM Frank McConnell via cctalk < cctalk@classiccmp.org wrote: > Very old mail programs indeed have no understanding whatsoever of > character sets or encoding. They simply display data from the e-mail file > on stdout or equivalent. If you are lucky, the character set and encoding > in the e-mail match the character set and encoding used by your terminal. > > The early-to-mid-1990s MIME work was in some part about allowing e-mail to > indicate its character set and encoding, because at that point in time > there were many character sets and multiple encodings. Before that, you > had to figure them out from your correspondent's e-mail address and the > mess on your screen or printout. > > And really it's not just about the mail program, it's about the host > operating system and the hardware on which it runs and which you are using > to view e-mail. Heavy-metal characters are likely to look funny on a > terminal built to display US-ASCII like an HP 2645. Your chances get > better if the software has enough understanding of various Roman-language > text encodings and you are using an HP 2622 with HP-ROMAN8 character > support and the connection between your host and terminal is > eight-bit-clean. But then you get something that uses Cyrillic and now > you're looking at having another HP 2645 set up to do Russian. And hoping > your host software knows how to deal with those character sets and > encodings too! > > -Frank McConnell > > On Nov 25, 2018, at 9:55, ED SHARPE via cctalk wrote: > > > > seems only the very old mail programs do not adapt to all character > sets? > > > > > > In a message dated 11/25/2018 6:19:52 AM US Mountain Standard Time, > cctalk@classiccmp.org writes: > > > > > > > > > >> On Nov 21, 2018, at 4:46 PM, Bill Gunshannon via cctalk < > cctalk@classiccmp.org> wrote: > >> > >> > >>> On 11/21/18 5:19 PM, Fred Cisin via cctalk wrote: > >>> Ed, > >>> It is YOUR mail program that is doing the extraneous insertions, and > >>> then not showing them to you when you view your own messages. > >>> > >>> ALL of us see either extraneous characters, or extraneous spaces in > >>> everything that you send! > >>> I use PINE in a shell account, and they show up as a whole bunch of > >>> inappropriate spaces. > >>> > >>> Seriously, YOUR mail program is inserting extraneous stuff. > >>> Everybody? but you sees it. > >>> > >> > >> I don't. I didn't see it until someone replied with a > >> > >> copy of the offending text included. > >> > >> > >> bill > >> > > same here. i didnt see them until some replies included the text. > > > > kelly > > > >
e-mail, character sets, encodings (was Re: George Keremedjiev)
Very old mail programs indeed have no understanding whatsoever of character sets or encoding. They simply display data from the e-mail file on stdout or equivalent. If you are lucky, the character set and encoding in the e-mail match the character set and encoding used by your terminal. The early-to-mid-1990s MIME work was in some part about allowing e-mail to indicate its character set and encoding, because at that point in time there were many character sets and multiple encodings. Before that, you had to figure them out from your correspondent's e-mail address and the mess on your screen or printout. And really it's not just about the mail program, it's about the host operating system and the hardware on which it runs and which you are using to view e-mail. Heavy-metal characters are likely to look funny on a terminal built to display US-ASCII like an HP 2645. Your chances get better if the software has enough understanding of various Roman-language text encodings and you are using an HP 2622 with HP-ROMAN8 character support and the connection between your host and terminal is eight-bit-clean. But then you get something that uses Cyrillic and now you're looking at having another HP 2645 set up to do Russian. And hoping your host software knows how to deal with those character sets and encodings too! -Frank McConnell On Nov 25, 2018, at 9:55, ED SHARPE via cctalk wrote: > > seems only the very old mail programs do not adapt to all character > sets? > > > In a message dated 11/25/2018 6:19:52 AM US Mountain Standard Time, > cctalk@classiccmp.org writes: > > > > >> On Nov 21, 2018, at 4:46 PM, Bill Gunshannon via cctalk >> wrote: >> >> >>> On 11/21/18 5:19 PM, Fred Cisin via cctalk wrote: >>> Ed, >>> It is YOUR mail program that is doing the extraneous insertions, and >>> then not showing them to you when you view your own messages. >>> >>> ALL of us see either extraneous characters, or extraneous spaces in >>> everything that you send! >>> I use PINE in a shell account, and they show up as a whole bunch of >>> inappropriate spaces. >>> >>> Seriously, YOUR mail program is inserting extraneous stuff. >>> Everybody? but you sees it. >>> >> >> I don't. I didn't see it until someone replied with a >> >> copy of the offending text included. >> >> >> bill >> > same here. i didnt see them until some replies included the text. > > kelly >
