[inforoots] Re: that +AFs-inforoots+AF0- stuff

[Rafael Skodlar]

Hi Mike,

Michael Albaugh wrote:
> =======================================
>
> Posts to inforoots at computerhistory.org is information known to or the opinions of the poster.  All posts to inforoots at computerhistory.org are archived.  By posting to this list you grant a license for use of this material to the Computer History Museum located in Mountain View, California, USA. 
>
> =======================================
> Just FY-all-I, the first version came out "mostly correct" when viewed
> via gmail.
>   

Using open source computing environment for ALL my private computing 
needs and 99% at work I have no problems with information standards in 
general nor did I have problems with the original email. Most if not all 
widely used file formats were reverse engineered in cases where a 
(greedy, dictatorial, and non-inventive) company did not publish them 
and that's the way it should be.

> It did have the funny +A...- stuff, which I believe (and this is why
> I'm posting)
> is an artifact of MSFT choosing "reserved, non-printing" characters for their
> "smart quotes".
>
> When ASCII was expanded and ISO'd for national character sets,
> some of those reserved characters were used as sort of "escapes"
> to introduce non-USASCII characters. (sort of the same goal as UTF-8,
> but different in detail).
>
> Anyway, when mail passes through various gateways, each tries to
> "do the right thing" with non-ISO characters and various alternate
> encodings, and, well, this is what you get.
>
>   

That's not exactly correct I believe. No MTA (Mail Transfer Agent) is 
allowed to convert anything in the message body. Email headers are 
defined in appropriate RFCs and the envelope is updated as it passes 
through MTAs on it's way to final destination. The rest, i.e. message 
body has to be (re)sent intact otherwise it [wc]ould be completely 
unusable to the addressee. That way, messages in different languages can 
make it through MTAs without problems. Scanning messages for virus or 
spam is another subject but it should not affect the contents either; 
otherwise lawyers would be all over MTA server owners.

> Appropriate for Inforoots because this is a taste of what we, and our
> successors,
> will face with archived material. Not all (that is, very little) of it is marked
>   

That's only true for products from one particular company that caused 
more damage to "computing psyche" than good. It's unfortunate and a 
shame that they go against their own customers in such a way. Digital 
karma will eventually catch with them and they'll end up in dark corner 
of computer museum as a warning to future generations :-)

> unambiguously for character set (Hand's up everyone whose web pages
> _all_ have the proper character set attribute in the content-type. Didn't
> think so :-), software that tries to "do the right thing" can make a bigger
>   
"Right thing" is a matter of standards. There are well defined WWW 
standards but some companies tried to mess with them more or less 
successfully.

> mess, etc. The last computer I own that can properly read old Word
> and PageMaker 3.0 files is on its last legs, and it was brand-spanking new
> 10 years ago. Something to mull.
>
>   

Well, if you install and use appropriate OS with open source 
applications you'll be able to read and use old documents without 
problems in most cases. Well, not sure about Pagemaker. There are plenty 
of "live CD" versions of operating systems that make it easy to "test 
the waters". You don't need to install the OS in order to see if the 
files can be dealt with in some form or another.

> Now, in my spare time I will be attempting to recover CDC3400 "Display-code"
> (_not_ the same as IBM BCD, no matter what "the web" seems to believe)
> text from a COSY archive, stored in a SIMH-style virtual tape, that I found
> inside a .zip in one of my .tgz files in a Macintosh disk-image on my current
>   
"inside .zip in .tgz"? Isn't that an overkill? Compression of a 
compressed file not only makes it bigger in most cases, it makes it 
harder to decode in case of errors.

> main computer. Not that I suggest anybody hold their breath :-)
>
>   Mike
>   

SIMH needs a lot of work also. It's a great tool to quickly run old programs but it's architecture is not user friendly :-)


--
Rafael