Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!NRI.RESTON.VA.US!vcerf From: vcerf@NRI.RESTON.VA.US Newsgroups: comp.mail.multi-media Subject: Re: Multi-media mail standards Message-ID: <9008230525.aa01465@NRI.NRI.Reston.VA.US> Date: 23 Aug 90 09:25:50 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 32 Jonathan, I have to agree with your general sense that exchange standards for mm objects will have to convey more contextual information than one typically finds in a particular application file format. There is something interesting, though, about what we can see happening out there in application land. People who write similar applications (e.g. drawing packages) seem to be going to the trouble to support import (and sometimes export) in a variety of "formats." I don't think what has been done thus far will generalize in any particularly nice way because, as you point out, these formats were designed for particular applications which bring a lot of context to the file which doesn't have to be explicitly mentioned in the file itself. I expect, though, that there will be a strong inclination to be able to move objects with application-specific content around in the mm mail. The best example of the "lack of context" problem is sending ASCII files around with embedded tab characters but no indication anywhere as to the correct tab settings. ASCII is a wonderfully low level "medium" but even ASCII can foul you up, as above. And we all know some of the problems with shipping PostScript around... I think we will need to accommodate transfer of things like TIF, CGM, and other common application formats around, while searching for much more general, architecturally sound frameworks for exchange of complex objects. Vint [A