Date: Thu, 13 Feb 1997 23:15:26 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Jake Hamby <jehamby@lightside.com> Cc: chat@FreeBSD.ORG Subject: Re: MIME applications for FreeBSD Message-ID: <Pine.BSF.3.95q.970213214219.10804G-100000@fallout.campusview.indiana.edu> In-Reply-To: <199702130450.UAA01601@lightside.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[moved to chat] On Wed, 12 Feb 1997, Jake Hamby wrote: > Terry Lambert writes: > > > As to what binary data is permitted to be encoded: > > > > 1) Any binary data the sender and the recipient can agree upon > > > > > > Though I'd be perfectly happy to see this limited to binary data for > > which public source reference implementations exist (ie: no more Word > > documents unless Microsoft publically documents Word file format, no > > PDF documents unless Adobe documents their "encryption" preventing > > the use of non-Adobe readers, but not preventing any Adobe reader from > > decoding the document, etc., etc.). > > Absolutely! Although figuring out the lowest common denomintor for, e.g. > rich text, often leads to all sorts of oddities. Ah, yes. What us poor users who just want to get some work done need is to raise the common denominator via DATA standards. Vendors, of course have a vested interest in focusing standardization at the APPLICATION. People's investment in their data typically far exceeds their investment in hardware or software. Unfortunately, with standardization focused at the application level, (MS|Corel|Lotus)Office, the fine print on the investment contract says "If the customer should wish to change applications, all data investments are null and void." Actually, it isn't completely null and void, but you do take a substantial loss. The pickings for universally grokable application and vendor independent data formats are pretty thin. 7 bit US-ASCII won't cause very many people very much trouble but it does cramp many people's style. As soon as you add that 8th bit, things degenerate into a code set quagmire with the only light on the horizon being unicode/ISO 10646, but with its implementation and political difficulties, it may be quite a while before it is widespread. Higher level encoding boils down to markup. SGML is a good start. Essentially any markup construct found in proprietary word processor formats can be expressed using SGML. Unfortunately, SGML is widely misunderstood and has been plagued by lack of tools useful to ordinary mortals. The recent XML initiative may help out on both fronts. XML is a proper subset of SGML. Many of the more esoteric and confusing SGML features of dubious utility have been cut, which makes XML much easier to understand (humans) and parse (tools). XML embraces unicode right from the start as well. Of course, vendors can still create hideously obtuse markup languages using SGML, but they would be orders of magnitude easier to reverse engineer than the bag of encrypted bits they currently use. -john
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970213214219.10804G-100000>