Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ucbvax!THUMPER.BELLCORE.COM!nsb From: nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) Newsgroups: comp.mail.multi-media Subject: Re: Multi-media mail standards; Forw: Use of ODA in the Internet Message-ID: Date: 14 Aug 90 12:26:50 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 73 Excerpts from internet.mmm-people: 14-Aug-90 Re: Multi-media mail standa.. Larry Masinter@cs.ucla.e (1070) > I caught the tail end of an argument (well, flame exchange) about > whether it is important that the mail be viewable on 'dumb' terminals. > Are there other issues? Oh, lots. Otherwise it wouldn't be any fun. (Personally, I think the idea of making a multimedia standard look good on a dumb terminal is pretty hopeless. I find it hard to imagine coming any closer than Andrew does on this score, and that isn't very close, especially for things like bitmaps...) Two of the issues that I find most intriguing (possibly because I come down on a different side than my friend, colleage, and collaborator Jonathan Rosenberg) are the issues of processability and programmability. Here's a brief summary of the issues: Processability: A processable document representation is one that can not only be displayed to the end-user, but also edited in terms of high-level structures. For example, think of a multi-font document. You could transmit this as a bitmap, and it would be readable, but scarcely editable at all. You could transmit it as text along with indicators of the font (e.g. "@timesroman14bold(Hello)") and that would be largely editable/processable. Best of all, you could transmit it with structural indicators that might not be translated into fonts until the last minute, when the output capabilities are really known, e.g. "@majorheading(Hello)". You can think of these three cases as being on a scale of increasing processability. Programmability: A programmable document is simply one that includes code, either instead of or in addition to data. If I can send you code through the mail and have it run automatically when you read it, I can build all sorts of mail-based services. (This sounds like a mind-bending security hole, but it doesn't need to be. My current research has produced a powerful language for safely sending programs through the mail.) What's really interesting is that the two goals of processability and programmability are in some measure incompatible. (Can programs be processed? Think about the halting problem.) My current belief is that the ultimate mail standard should include both processable and programmable components, but I'm not terribly happy with that. Another open issue is extensibility of the multimedia standard to new media types. Andrew really broke new ground on this one -- it is amazingly easy to add new media types (animation, video, annotated hypertext, whatever) to an installed Andrew base. Yet multimedia messaging only works if EVERY site makes such installation, because the new media types are defined at the level of C code rather than at the level of Andrew representation. (Alternately, Andrew permits you to make many such extensions, nearly to the level of new media types, using the embedded Ness programming language. However, this can open up real security problems if generalized and used.) Contrast all this to ODA, which is fine for a few media types (rich text, rasters) but which requires a multi-year stnadardization process in order to add new media types. The "right" answer is far from obvious. Those are just three issues that particularly interest me. If you want a more exhaustive list of issues in multimedia mail, you could do a lot worse than ask some of the thousands of Andrew users what they dislike about the system... :-) ---------------------------------------------------------------------- [An Andrew ToolKit view (a raster image) was included here, but could not be displayed.] [An Andrew ToolKit view (a raster image) was included here, but could not be displayed.] Nathaniel S. Borenstein Member of Technical Staff, Bell Communications Research Office: Bellcore Room MRE 2A-274, 445 South Street, Morristown, NJ 07962-1910 Work phone: (201) 829-4270 Work FAX: (201) 829-7019 Home: 25 Washington Ave., Morristown, NJ 07960, (201) 993-8586