stef@NRTC.NORTHROP.COM (Einar Stefferud) (07/27/90)
>Are there any public-domain IP-compatible mail standards for multi-media mail? >I am working on a messaging system which would combine telephone, videotext, >video, and SMTP e-mail on a single, portable platform, so what I am most >interested in are voice and still/moving video standards which can be moved around easily via TCP/IP. > >In your reply, please indicate the source of the standard, and >give some idea how widespread the current implementations are (software -------- Forwarded message To: ietf@venera.isi.edu Subject: Use of ODA in the Internet Date: Wed, 25 Jul 90 09:39:36 -0400 From Peter Kirstein..... - --------------------------------------------------------------------- FACITLITIES FOR PROPOSED PILOT ACTIVITY USING OFFICE DOCUMENT ARCHITECTURE FACILITIES FROM UNIVERSITY COLLEGE LONDON AND THE PODA PROJECT Text communication on an open system, broad-based scale was made possible by the emergence of a number of standards. The most important of these, ASCII, ensured that a test document could be composed on one system, could be transmitted to another (on-line or by some other medium), and reproduced elsewhere with no loss of meaning. ASCII was a National Standard; eventually it was extended to the International Alphabet No 5 and then the extended character set to allow for national characteristics. There have been many proprietary activities in extending the standard to include processable formatted text, and mixed-mode documents. Some, like nroff, have had a considerable following; that one is limited, however, to text applications and does not directly map to WYSIWYG editors. The more advanced Wordprocessing packages have taken another approach; they have allowed the import/export of documents from other systems with special packages. Some have even allowed the import of bit-map or geometric graphic documents from other sources to be incorporated. All these approaches have a common drawback; as the number of proprietary packages have grown, the number of import/export formats has had to grow. To aid in document interchange, a number of approaches have been tried. Many of the manufacturers have tried to get their proprietary formats accepted universally. The one with the most success has been Adobe Inc. with POSTSCRIPT; many systems can accept POSTSCRIPT [1] and print it out (with minor inconsistencies), but it is certainly not appropriate for the interchange of Processable text for collaborative working. There is one attempt at an International Standard which has worked better: the Standardised Generalised Mark-up Language (SGML) [2], [3]. This has been adopted widely for text documents. It has still a number of facilities which can be defined by private conventions, so that it does not follow that SGML documents are universally reprocessable; nevertheless, providing that conventions are agreed, it goes very far for high quality text. SGML does not do well, however, with other types of document content like tables, bitmap graphics, and geometric graphics. To aid with the interchange of mixed-mode documents, the International Standards Organisation has developed the Office Documents Architecture [4]. This Standard is still being developed further, but its present version already supports formattable text, bit-map graphics (and facsimile) and geometric graphics. Extensions under development include incorporation of Data and Spreadsheets, Colour, Security (Confidentiality, Authenticity and Integrity) and even Voice Annotation. To ensure interoperability, there are various profiles adopted internationally; one of these is Q112 [5]. Many manufacturers are developing editor products which can interchange documents to the ODA/ODIF standards of [4] and [5]. In particular, Apple, British Telecom, Bull, DEC, IBM, ICL, Nixdorf, Oce, Olivetti, Siemens, UCL, and UNISYS showed interworking systems at the CEBVIT '90 in Hanover in March 1990. Few of these are yet real products, but several of the above have announced product plans. While the editors represented often had higher internal functionality, there was still far greater functionality in processable mixed-mode documents passed between the above systems than in any other heterogeneous interchanges. In CEBIT '90, the document interchange was via X.400 (1984); by using UUENCODE or some other agreed format, it would also be possible to interchange the documents by SMTP or any other mechanism which was designed only for text interchange. In the Internet Community, there are no good standards yet for mixed-mode docuemts. In view of the current status of the ODA standard, and of the imminence of real ODA products, it would seem appropriate to investigate the suitablility of ODA for Internet purposes. Many of the organisations mentioned above have offered to make available there packages for such a trial. The details have still to be worked out on the terms of availability, but in principle the following should be available with ODA/ODIF interchange packages: Editors from Apple and DEC SLATE from BBN/UCL WORD from Bull WORDPERFECT from ICL Few details are available yet on most of the above. One purpose of this note is to determine who would be interested in any of the above being pursued more vigorously. The BBN SLATE package was developed (initially as DIAMOND), partially under DARPA and NSF auspices (the latter under the EXPRES project). The UCL ODA postprocessor [6] was developed under two European ESPRIT (INCA and PODA [7]). In the PODA demonstrations, SLATE/ODA was integrated with the PP X.400 system developed by UCL [8]. However, a version is now being packaged together, using SLATE v1.1 and the UCL tools, which will allow the use either of X.400/X.25, X.400/TCP/IP or SMTP/TCP/IP. The software runs on Sun workstations, and makes use of the ISODE Systemm (currently v6 [9]), which has been developed principally by M. Rose, but assisted by people in other organisations (including UCL). Reference 7 is being made available for annonymous FTP at nisc.nyser.net [192.33.4.10] from the directory pub/isode/directory. UCL is currently investigating the status of the other software packages mentioned above; at the momnent only the one based on SLATE is known to be complete and conformant. Most of those used in the PODA demonstrations are completely experimental, and many are embedded in Office Automation systems, and thus are not really suitable for use in a Pilot. People interested in participating in the use of ODA in a Pilot project should contact R. Hagens (Hagens@wisc.edu) or P. Kirstein (Kirstein@cs.ucl.ac.uk). It would be helpful if they indicated the equipment they would wish to use, and whether they wished to use the system based on SLATE or one of the others indicated above. REFERENCES 1. Adobe: PostScript Language Manual, Adobe Systems Inc, Palo Alto, 1984. 2. ISO: Information Processing - Standardised Generalised Markup Language, IS 8879, International Standards Organisation, Geneva, 1988. 3. ISO: Information Processing - SGML Document Interchange Format, IS 9069, International Standards Organisation, Geneva, 1988. 4. ISO: Information Processing, Text and Office Systems - Office Document Architecture (ODA) and Interchange Format (ODIF), IS 8613, ISO, Geneva, 1988. 5. EWOS: ODA Document Application Profile Q112 - Processable and formatted documents - Extended mixed mode, PrENV 41 510, Paris, 1988. 6. S. Golkar et al.: ODA Activities at University College London and their relation to the PODA Project, submitted to Commputer Networks and ISDN Systems, 1990. 7. J. Nelson et al.: ODA/ODIF - the Standard Solution to Document Interchange, ESPRIT'89; Proceedings of the 6th Annual ESPRIT, Brussels, Nov 27-Dec 1 1989. 8. S.E.Kille: PP - A Message Transfer Agent, Conference on Message Handling Systems and Distributed Applications, pp 115-118, October 1988. 9. M.T. Rose: The ISO Development Environment User's Manual, V6, available from U of Delaware and UCL, 1990 ------- End of Forwarded Messages
enag@ifi.uio.no (Erik Naggum) (07/28/90)
I would be pleased if the references to SGML and ISO were done properly. SGML is not "Standardised Generalised Mark-up Language", but "Standard Generalized Markup Language", at least according the copy I have. It also says ISO is the International Organization for Standardization not "International Standards Organisation". Personal opinion: I hope that we will never see application-level binary interchange formats on the Internet. Editability with a variety of tools, not just some random and closed-minded specific application tool is a must for soi disant "open systems". They are closed if they are not user extensible. They are closed if they depend on a particular version of a particular protocol specification. They are closed if users cannot understand them. We are again moving towards the "white robes" of super-technicians who have the questionable skill to decode a broken ODA bit stream. "Open" to me also means I can look inside. Well, I won't go rambling on about this. -- [Erik Naggum] Gaustadalleen 21 +47-256-7822 <erik@naggum.uu.no> N-0371 OSLO; NORWAY +47-260-4427 (fax)
richardb@cognos.UUCP (Richard Brosseau) (08/03/90)
In article <ENAG.90Jul28183852@slembe.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes:
+I would be pleased if the references to SGML and ISO were done
+properly.
+
+SGML is not "Standardised Generalised Mark-up Language", but "Standard
+Generalized Markup Language", at least according the copy I have.
+
+It also says ISO is the International Organization for Standardization
+not "International Standards Organisation".
+
+Personal opinion:
+I hope that we will never see application-level binary interchange
+formats on the Internet. Editability with a variety of tools, not
+just some random and closed-minded specific application tool is a must
+for soi disant "open systems". They are closed if they are not user
+extensible. They are closed if they depend on a particular version of
+a particular protocol specification. They are closed if users cannot
+understand them. We are again moving towards the "white robes" of
+super-technicians who have the questionable skill to decode a broken
+ODA bit stream. "Open" to me also means I can look inside.
+
+Well, I won't go rambling on about this.
SARCASTIC MODE ON
So we should all stick to ADM-5 terminals and use ASCII, eh?
SARCASTIC MODE OFF
+--
+[Erik Naggum] Gaustadalleen 21 +47-256-7822
+<erik@naggum.uu.no> N-0371 OSLO; NORWAY +47-260-4427 (fax)
--
Richard Brosseau Cognos Inc.
UUCP: uunet!mitel!sce!cognos!richardbenag@ifi.uio.no (Erik Naggum) (08/09/90)
Dear Richard, This is in reply to your sarcastic "So we should all stick to ADM-5 terminals and use ASCII, eh?" comment in reply to my hope that "open" should not mean "open, that is, between 1130 and 1135 Wednesdays with a total eclipse of the moon" in respect to the binary coded "open systems interconnection" horrors in the field of what was once text. Multi-media is a very interesting topic. I don't think you should trivialize issues of readability where all the multiple media are not simultaneously representable in a convenient form. Neither do I think you should ignore the fact that some actual, real people, such as pro- grammers, will have to sit down and write the software you will use on your undoubtedly fancy 16-bit color 2048x2048 pel bitmap display device with stereo speakers and a fountain with goldfish. I do appreciate the efforts that are made to formalize structures and concepts, as in ODA and SGML, but I also think that when you need to write a device driver for a window system just to read your mail in 12-point Times fonts because that was what the sender deemed to be useful to you, it has gotten somewhat out of hand. It gets even worse when you have to spend the better part of a year to understand the soi disant standards involved, then shell out thousands of bucks to get a compiler for ASN.1, and try to break that damn bitstream into something readable by a human, eventually. Add to this the frustration that comes packaged with the next version of the standard, incompatible with the one you use. Now you might intervene and say: "But _I'm_ not going to write those programs!", implying that somebody else somewhere is going to do it for of you, somehow. I know that the relevant Working Group under ISO has not given the idea of somebody actually implementing their stuff the slightest consideration, at least not if they would do it for less than the gross national product of Chile. This, however, is not an excuse to pick up their bad aim and faulty decisions. After all, who cares what the underlying representation is, anyhow? EXCEPT the system programmers, the application programmers, the debuggers, the network folks, the toolkit designers, etc, etc, etc. These folks are not slaves of your binary-coded whims, Richard. They will have to get paid, lots!, if they are to do a job which is good enough to reach that Nirvana of Interconnectivity people are starting to spin mythologies around. Remember, one tiny little error in a binary coded stream is going to wreak havoc, fast. Some "it'll probably work -- who cares" programmer somewhere is bound to make some lowly error that will bring down your very important system at demo time. It's going to take ages to find the bug, unless you have bug-free "scopes" to peek into the fluttering world of binary representation. I don't write my programs in 12 pt Times Roman with a 630 Hz sub-carrier and animated syntax rules, I write them in plain ASCII -- and for that purpose, an ADM-5 will do. I'd like the ADM-5 to be able to used for testing, as well, and so would the sponsor of my project, unless of course, he knows that some undefined set of taxpayers is going to pay. "Have you hugged your programmer today?" -- [Erik Naggum] Gaustadalleen 21 +47-256-7822 <erik@naggum.uu.no> N-0371 OSLO; NORWAY +47-260-4427 (fax)
masinter@parc.xerox.com (Larry Masinter) (08/14/90)
I've just started reading this newsgroup. What do current multi-media
systems do for posting mail across the Internet?
The following is just my impression from brief encounter with a couple
of multi-media mail systems:
It seems that NeXT machines want to transmit RTF + uuencoded data for
sounds; (or is it a tar file of the RTF plus the required accompanying
data.)
Andrew seems to want its own ascii representation (looks a little like
SGML with backslash and {} braces).
The Interlisp-D/Xerox Common Lisp mailer could mail image objects
using the Xerox mail system; Bob Bane did a hack where mail transport
across Unix mail sytems would uuencode the binary and uudecode it on
the way in.
What does BBN/Diamond do? Other multi-media mail systems?
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?
--
Larry Masinter (masinter@parc.xerox.com)
Xerox Palo Alto Research Center (PARC)
3333 Coyote Hill Road; Palo Alto, CA USA 94304
Fax: (415) 494-4333nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/14/90)
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 <nsb@thumper.bellcore.com> 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
jhm+@ANDREW.CMU.EDU (Jim Morris) (08/14/90)
You forgot to mention PostScript. Certain communities exchange a lot of things in PostScript. It offers the possiblity of system independence.
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/15/90)
Excerpts from internet.mmm-people: 14-Aug-90 Re: Multi-media mail standa.. Jim Morris@andrew.cmu.ed (144) > You forgot to mention PostScript. Certain communities exchange a lot of > things in PostScript. It offers the possiblity of system independence. PostScript is a good example of some of the problems I mentioned in my previous post. In particular, it is not really processable. It is computational very rich (programmable) but hardly designed with attention to the security problems involved in embedding it in mail, which means I'd have to examine the spec very closely before really trusting it to run automatically. It certainly suffers in the case of people trying to read it in a non-multimedia environment. It is, however, extremely extensible, which is probably its one strong point as far as I'm concerned. I think it would be a bad multimedia mail standard, though. -- Nathaniel
jhm+@ANDREW.CMU.EDU (Jim Morris) (08/15/90)
Whatever its technical merits and demerits PostScript is strategically well-positioned because everybody translates into it already. If you are willing to assume that a PostScript program's only purpose is to render a set of pages in finite time, then it can be distilled down into a simple canonical form that is much more amenable to processing. This, of course, is true of any language.
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/15/90)
Excerpts from mail: 14-Aug-90 Re: Multi-media mail standa.. Jim Morris@andrew.cmu.ed (393) > Whatever its technical merits and demerits PostScript is strategically > well-positioned because everybody translates into it already. Yes, the real question is: what are we talking about? If we're talking about "how to get multimedia mail working right away for people, no matter what the cost in technical correctness" then yes, PostScript is a good candidate. If we're talking about "what should CCITT committees be thinking about in formulating ultimate standards for multimedia documents" then I think they should be steered away from PostScript at all costs. The bottom line is that multimedia mail and printers are very different beasts, and a printer-oriented standard would be a real straitjacket for multimedia mail. -- Nathaniel
jhm+@ANDREW.CMU.EDU (Jim Morris) (08/15/90)
Nathaniel Borenstein writes: >Yes, the real question is: what are we talking about? If we're talking >about "how to get multimedia mail working right away for people, no >matter what the cost in technical correctness" then yes, PostScript is a >good candidate. If we're talking about "what should CCITT committees be >thinking about in formulating ultimate standards for multimedia >documents" then I think they should be steered away from PostScript at >all costs. I agree completely! :-?
maguire@NADA.KTH.SE (Gerald Maguire) (08/15/90)
There was a mail system built on LISP at HP Labs which allowed you to send S-exprs and have them executed by the receiver. As a security feature you could set a flag that you did NOT want the s-exprs to be automatically executed but could eval them manually. It is quite straight forward to make this conditional on the sender. However, if you want programmability there is no free lunch. You could evaluate the experessions inside an environment where you redefined functions which could change the state of the system as "safe" operators - which could trap to a handler, rather than perform the operation (for example "rm" and write operations). This is one major advantage to execution within an environment which does name lookups using the top most directory (which means you could do the same for PostScript). Chip
dcrocker@nsl.dec.com (Dave Crocker) (08/15/90)
Hi, Jim. With respect to Postscript, pardon my using a small item from a recent IETF meeting, at which there was similar discussion about using it as an exchange standard, but I have a small question: What is postscript? People keep talking about it and they even keep exchanging files that are supposedly of that type, but I am impressed with the frequency with which such files do not print. (Yes, I am also impressed with the number of times they DO print, but the failures seem infinitely more interesting to me.) I.e., there ain't no such thing as standard postscript. You can point to any document you want, but it appears not to reflect reality. Dave
jhm+@ANDREW.CMU.EDU (Jim Morris) (08/15/90)
Dave Crocker writes >I.e., there ain't no such thing as standard postscript. You >can point to any document you want, but it appears >not to reflect reality. This is true. There are intrinsic problems--like missing fonts-- and avoidable problems -- like the infamous, multi-versioned LaserPrep. This was also true of FORTRAN, another de facto, semi-proprietary standard. Adobe will tend to behave the same way IBM did with FORTRAN; they want it to be a de facto standard but they don't want to get carried away with clarifying the standard so as to make the cloners job easier. There is a PostScript users group, led by Terry Satterthwaite somewhere in S.F. They might be the logical group to clarify and enforce standards.
new@ee.udel.edu (Darren New) (08/15/90)
In article <9008142236.AA18311@nada.kth.se> maguire@NADA.KTH.SE (Gerald Maguire) writes: >which could change the state of the system as "safe" operators - which >could trap to a handler, rather than perform the operation (for >example "rm" and write operations). I may be slow, but why would a mail message need to "rm" a file at all? If you are talking about things like what we use "shar"s for now, I would think it would be possible to make a format that would need to be interpreted by a user-trusted program (like unshar) to unpack such things. If you mean things to give arbitrary output (like Postscript does), I fail to see any need for `security' there either: the Postscript interpreter in my laser printer is totally incapable of deleteing any of my files. A simple solution to the problem would be to design the multi-mail format to contain no embedded filenames. Hence, any operation to be done to any file must prompt the user for a filename (at least). Or am I totally off-base? -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
jhm+@ANDREW.CMU.EDU (Jim Morris) (08/16/90)
I generally agree with you that the activities of active mail messages could be sufficiently circumscribed to prevent it from doing damage to a local environment. However, one of the most useful things an active message might do is send mail messages to other places, and the possiblity for mischief is high.
emv@math.lsa.umich.edu (Edward Vielmetti) (08/16/90)
In article <MASINTER.90Aug14005817@recycle.parc.xerox.com> masinter@parc.xerox.com (Larry Masinter) writes:
Andrew seems to want its own ascii representation (looks a little like
SGML with backslash and {} braces).
For completeness I should add that discussion about SGML is currently
going on in comp.text, and there's a proposal afoot to create a new
newsgroup for it (comp.text.sgml).
SGML has been put forward (reasonably) as a markup scheme for
hypertext documents. I haven't seen much work as yet to talk
about it for multi-media efforts; there is work being done at
Brown regarding a SMML (std. music markup language) which would
probably be better suited to shipping around music scores rather
than Bart Simpson sound bites.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
comp.text.sgml ISO 8879 SGML, structured documents, markup languages
yes votes to sgml-yes@math.lsa.umich.edu
no votes to sgml-no@math.lsa.umich.eduStef@NRTC.NORTHROP.COM (Einar Stefferud) (08/17/90)
What are the standards bodies (ccitt/iso/iec) doing in the MMM arena? Is there a reason to engage in some more formal MMM pre-standards activities, such as preceded X.400, X.500 and NetworkManagement. I ask because IFIP WG 6.5 stands ready and will to commission an active workgroup in this area, with the objective of feeding the results to CCITT/ISO/IEC at some future date, as happened with X.400 and X.500 and NM. Although timing is not critical in establishment of such an IFIP WG 6.5 subgroup on MMM, there will be an IFIP TC6 (WG 6.5) sponsored Symposium on MHS and Application Layer Communication Protocols in Zurich on Oct 3-5, 1990. Some workshops will be held as part of the symposium, and if a group emerges there to begin active work, we will be prepared to support it with WG 6.5 recognition, which means that the output can be given official standing before the CCITT/ISO/IEC, when the work is done. The WG 6.5 business meeting will be held on the last afternoon (Oct 5). I am saying all this as the IFIP WG 6.5 North American Vice Chair...\Stef
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/17/90)
I think that it is evident that eventually some kind of format standard
for multimedia mail will have to be adopted. I also think that *none*
of the current conceivable contenders are appropriate, and that some
basic research on document representation technology still needs to be
done. In my opinion, a standard would be premature.
Having said that, however, I think it is NOT premature for standards
bodies to be looking at the problem. If, for example, an IFIP-sponsored
group were to meet, discuss the issues, and issue a statement that
listed some of the key issues that needed to be solved for multimedia
standards to become a reality, this would very likely hasten the
solution of the problems.
I'd be very interested in meeting with other interested parties (at the
Zurich conference or elsewhere) to see about starting such a group. As
far as I'm concerned, anything that will hasten the advent of a GOOD
standard representation format for multimedia mail is worth a
substantial amount of time and effort. Is there already a plan for a
workshop in Zurich on multimedia document format representation? If
not, I'd be willing to organize one.
(The Usual Disclaimer: The views expressed above are my own, and not
those of Bellcore.)
----------------------------------------------------------------------
[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 <nsb@thumper.bellcore.com>
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-8586Stef@NRTC.NORTHROP.COM (Einar Stefferud) (08/17/90)
Hello Nathaniel -- There is no published plan (as yet) for an MMM Workshop in the list of planned workshops to be held on Thursday Afternoon (October 4) but we can easily add one after the fact, and include it in our plan. We will be pleased if you will assume the Chair of an MMM Workshop on October 4. What we would like you to do in preparation is to develop or obtain (from wherever) one or more discussion paper(s) to provide grist for the mill, to be handed out in advance of the workshop, but not included in the proceedings preprint. A report of the workshop, if it jells and produces reportable results, will be added to the finally published (by North-Holland) proceedings. The results that we seek are to form a working subgroup with a set of work items and a plan to produce some useful pre-standards documents wihich can form the basis of further work in the standards bodies. When the work shows that there is indeed a reasonable basis for regular standards body work, it should be packaged as a contribution and contributed in some way so as to facilitate the standards process. You might want to use the MMM mailinglist discussion here as a forum for developing a disucsion paper that delineates the issues. What IFIP would be adding to the current effort (open discussion in this forum) would be a means for focusing the results into a serious pre-standards contribution to the standards bodies. I should note that the X.400 mail paradigm was first conceived in the internet (SMTP. MMDF, HERMES, MM, XMAILR, and passed through IFIP on its way to CCITT, starting in 1977. It was this head start provided by the INTERNET, via pre-standards work in IFIP WG 6.5, that allowed X.400 to be first delivered in 1984. It is very important sometimes to first iron out teh basic conceptual modelling issues in a neutral arena like an IFIP working group, than to try to do it in politically charged standards group meetings. IFIP operates in a non-political framework, open to all interested parties, with no authority to impose anything on anyone, but with standing before the standards bodies so results can be contributed to stand on its own merits. Wehn such work is contributed to the standards boides, with a good concensus behind it, it is pretty good bet that it will progess well. Best...\Stef
P.Kirstein@CS.UCL.AC.UK (08/17/90)
It is the current plan of many of the relevant bodies to improve the gaps in ODA (data [and spreadsheets], SGML interworking, voice content, security, more font support, colour, hypertext support in particular) and move that to a further standard. I thought that the end of the year was the date proposed for this to be completed as a Draft Proposal. While this does not deal with many of Nathaniel's concerns - in particular annimation and execution from a document - it is by no means clear that most of the bodies concerned would like to see that in a standard at all at present. Why is ODA not adequate for a mmm standard - at least it would let us get started with services quickly. If we start a long experimental stage, we will not get services going within the next five years. My own preference would be to take the ODA standard as it now is, and try to get agreed in (for example) the IFIP 6.5 arena a version of the draft standard extensions to meet the most pressing needs. My own vote would be for spreadsheets, colour, fonts and voice conte) to be put in some form. This should clearly be regarded only as an "interception strategy", and we should be aware that most of the manufacturers will not put in any work on the extensions which have not been formally ratified. We could then get some multi-implementations testbedsquickly. I need the basic services, on the lines of being able to use the types of facilities which exist already in my favourite editors in a more open environment. I am quite happy for a lengthy experimentation period for the more advanced facilities - where the whole model of how they will be used is still in the research phase.
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/17/90)
I think that the amount of work that is necessary for each ODA extension (e.g. for spreadsheets) is indicative of its deepest problem as a standard -- its lack of programmability/extensibility. However, I agree, as I may not have made clear before, that ODA is the best starting point for such a standard, and I think it makes a certain amount of sense to frame the discussion, at least, in terms of "What makes ODA inadequate for a standard?" With luck, we might be able to outline ODA extensions that would make it suitable -- I certainly wouldn't rule this out. At the very least, it's an excellent starting point for such discussion. Perhaps the most important questions is, will it be possible for the "advanced" standard you mention to evolve from today's ODA? If not, it might be a bad idea to get too dependent on ODA now. I invite all parties interested in these issues to attend the Thursday workshop on multimedia data representation at the Zurich conference. -- Nathaniel
Stef@NRTC.NORTHROP.COM (Einar Stefferud) (08/17/90)
Hello Nathaniel and Peter -- The MMM work in IFIP WG 6.5 that I want to promote is work that is beyond the reach of the current standards process. I have no interest (and I hope no one else does either) in doing anything to slow down or hinder the current standards process that is producing what you want. What I don't want to do with regard to further work, is hold it back within the current standards process. What I am advocating is that some people with interests beyond the current standards process and action move beyond that process and do some pre-standards research work on what might be worth doing next, after the current standards process delivers on its current work items. I do not see any conflict. By analogy, it is like when IFIP WG 6.5 worked on DIRECTORY while CCITT worked on MHS. IFIP stopped work on DIRECTORY as soon as CCITT/ISO took up the question. So, IFIP WG 6.5 holds open the door to do pre-standards work in the international arena, with the first goal of not interfering in the current ongoing standards process, and with the second goal of contributing positive IFIP WG 6.5 results at some future time if useful results can be developed. The only guidance that IFIP WG 6.5 wants to apply will be to assure that the work that is started is clearly well beyond the current standards process goals, and that the work should not discourage ongoing standards progress or generate expectations of conflicting technology development. A major point to be made here is that this new pre-standards work should be done in an atmosphere that is free from the short term constraints on active standards work items. It should not have any deadlines for delivery and should not seek to lobby the current standards activity. On the other hand, it must operate in a totally open atmosphere with free distribution of its documents to whomever may be interested. I expect much of the work to be done via netmail, with infrequent face-to-face meetings scheduled when members of the MMM SubGroup find themseleves conveniently close together. Our only time line will be tied to our plans for another IFIP WG 6.5 Working Conference in Vancouver in 1992, when we would hope to see some papers and presentations on MMM SubGroup results. We also look forward to another WG Working Conference in 1994 somewhere in Europe. And somewhere in 1996. Best...\Stef
craig@gpu.utcs.utoronto.ca (Craig Hubley) (08/20/90)
That list of standards efforts in multimedia was excellent, but there is a
body of work that it didn't cover. I mean the current efforts to standardize
"Object Management", including tangible media objects, that are happening in
the microcomputer world. It seems very likely that this work will have a major
effect on the form of any real working standard, as microcomputers are by far
the most likely terminals for any MM document or mail system. I think that a
standard that required a computer costing over $1000 (today's money) is likely
to lose ground, since there are tens of millions of PCs, Macs, etc., out there.
(about 20 million PCs, 4 million Macs, and 1.5 million Amigas, to name the
capable/popular MM platforms - plus all the workstations of course).
OMG
The OMG has about 70 corporate members. The goal is to standardize object-
oriented databases, operating systems, and most importantly from the multi-
media standpoint, *applications*. Their approach has some drawbacks, but
it makes new media types incidental side-effects of new applications, and
solves some very real problems in remote/programmed application control:
OBJECT = APPLICATION+DOCUMENT
The full command structure is considered to be available EITHER from WIMP means
or through a script language. The application code itself, *plus* an individual
document, constitutes an object. So, a spreadsheet object consists of Lotus
plus your spreadsheet. Lotus provides the behavior, you have provided the
data. Views of this 'object' can be included in other documents, and will
be updated when the spreadsheet is updated (the so'called 'hot link'). It
may be dependent on other documents itself. Snapshots can be taken at any
point in time. This would be useful to, say, send a report to someone else,
without sending the entire spreadsheet.
BIG OBJECTS
Now, granted these are pretty big objects, but as the approach catches on they
would get smaller, in fact each would tend to conform to one media type, just
as Unix tools have tended to become 'filters'. Most of the follow-on
functionality (printing, importing and exporting data, scripting languages)
would be provided for by the operating/window system.
ANY DOCUMENT
So, ANY DOCUMENT is potentially a piece of multimedia or even hypermedia,
just by including views of other documents. Each application defines a new
media type. The script language and standard WIMP controls are the same for
each.
AMIGA AREXX/IFF
This approach has already been test-bedded on the Amiga by the AREXX/IFF
combination. IFF is the Amiga answer to ODA, and defines many media types
up to and including animations, to match the Amiga's multimedia capabilities.
Amiga applications include AREXX ports to let AREXX scripts control them from
the 'inside'. AmigaDOS has lightweight multitasking, so tools have always
tended to be small and interoperable with others. AREXX is now part of the
operating system. It is interesting to note that neither IFF nor AREXX were
Commodore ideas, but their support in the user community grew so great that it
was impossible not to support them. Applications without AREXX ports are
considered substandard by the Amiga community. So, the hardware vendors need
not buy in to such a scheme to make it work, but it sure helps...
OTHER EFFORTS
HP's NewWave provides very similar capabilities for DOS and (I think, by now)
Unix. Apple is providing a parallel capability for System 7.0. These are
not the same, of course. According to some industry analysts at the time of
the suit, Apple sued HP over NewWave in part because it was afraid of this
greatly extended set of capabilities and wanted to scare off the market and
give itself time to catch up. This appears to have worked to some degree.
I have seen very few 'real' NewWave applications.
FOR MORE
For more information on the OMG, contact soley@omg.org (the Technical VP) and
ask to receive their standard literature pack. They are seeking feedback on
their current standards framework. For more on AREXX and IFF, read the group
comp.sys.amiga.tech - contact HP about NewWave, and Apple about System 7.0.
DEBATE ?
I would like to start a debate going on the advantages/disadvantages of this
approach to multimedia documents. I tend to think that today's monolithic
Mac and PC applications would make poor media types, but that Amiga and Unix
applications tend to be far better, probably due to multitasking which makes
it possible to run many simple programs, each dealing with one media type.
As Macs and PCs acquire this ability, their applications would be more
suitable for this approach. But in any case, this approach to MM documents
is very attractive because of the minimal incremental effort required on the
part of developers, to support it. It seems likely to have a very substantial
influence on standards efforts in this direction, although the standards groups
themselves seem blissfully unaware of it.
Craig Hubley kid after Live Aid: "Is that it?"
Craig Hubley & Associates ---------------------------------
craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET
craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
--
Craig Hubley kid after Live Aid: "Is that it?"
Craig Hubley & Associates ---------------------------------
craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET
craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craigStef@NRTC.NORTHROP.COM (Einar Stefferud) (08/20/90)
I will plan to leave the specifics of any woprkitem list and terms of reference to be developed by any IFIP WG .65 MMM Subgroup that might be formed. Your list looks like as good a place to strat the discussion as any. It is not required that the discussion of terms of reference and work items occur in this list. I can imagine that some recipients might be unhappy to be bothered weith it here, but for the moment we do not have anotehr forum, so lets start here. WE can always move if we overburden the mmm-people list. Cheers...\Stef
jxr@THUMPER.BELLCORE.COM (Jonathan Rosenberg) (08/20/90)
Subject: Re: Multi-media mail standards; Forw: Use of ODA in the Internet Sender: mmm-people-request@venera.isi.edu To: mmm-people@venera.isi.edu > That list of standards efforts in multimedia was excellent, but there is a > body of work that it didn't cover. I mean the current efforts to standardize > "Object Management", including tangible media objects, that are happening in > the microcomputer world. It seems very likely that this work will have a major > effect on the form of any real working standard, as microcomputers are by far > the most likely terminals for any MM document or mail system. > I think that a standard that required a computer costing over $1000 (today's money) > is likely to lose ground, since there are tens of millions of PCs, Macs, etc., out there. > . . . > DEBATE ? >I would like to start a debate going on the advantages/disadvantages of this > approach to multimedia documents. Well, you asked for it ... I must admit to being quite confused about the relationship of the kinds of standards/architectures you discussed in your message & a mm mail document standard. It is clear that in order to be usable as a mail standard, a document architecture must have a specified interchange format (also known as a datastream). I.e., the arch must specify the actual bits that are to be placed into the message to represent the document. Now, if I understand the standards you have described (and, I may not understand them correctly), they are descriptions of application program interfaces that allow executing processes to manipulate mm objects. This is obviously an important kind of standard, but I fail to see how one of these standards can be said to be a "mmm document standard". To be useful, one would have to define an interchange format for each standard. Now, this might be possible for any one of these standards, but given the original impetus for them (application program tool kits/standards), I'm not sure they lend themselves to mail standards. To stretch the analogy a little, I could claim that X is a graphics mail standard, since X allows applications to manipulate graphical objects. But, I hope no one would make this claim. Am I way off base here? Or, are you suggesting that we start with (one of) these standards & come up with an appropriate interchange format for them. JR
craig@gpu.utcs.utoronto.ca (Craig Hubley) (08/22/90)
>THUMPER.BELLCORE.COM!jxr (Jonathan Rosenberg) says: >Craig Hubley says: >> body of work that it didn't cover. I mean the current efforts to standardize >> "Object Management", including tangible media objects, that are happening in >> the microcomputer world. It seems very likely that this work will have a >> major effect on the form of any real working standard, as microcomputers >> are by far the most likely terminals for any MM document or mail system. >>I would like to start a debate going on the advantages/disadvantages of this >> approach to multimedia documents. > >Well, you asked for it ... > >I must admit to being quite confused about the relationship of the kinds >of standards/architectures you discussed in your message & a mm mail >document standard. It is two more or less separate ideas that are converging very strongly in practice, and have converged completely in some precedent-setting systems. TIEING UP TYPES Most of the debate over MM mail/documents seems to be around the definition of media types, and creation of a flexible architecture to support arbitrary types, including provisions for time-synchronized media (video, music) alongside browsable media (text, still pictures...). >It is clear that in order to be usable as a mail standard, a document >architecture must have a specified interchange format (also known as a >datastream). I.e., the arch must specify the actual bits that are to be >placed into the message to represent the document. The efforts I describe define this as the user's work file format (e.g a Lotus 1-2-3 spreadsheet in binary format) or a 'hot link' to such a file. The list of operations is the complete user interface of the application program (e.g. Lotus 1-2-3) itself. As such, it is defined not in PostScript or SGML but in a standard programming language, compiled for a given platform. The application itself may support an architecture-neutral interchange format for workfiles across platforms, but this is not necessary. So not all types of 'objects' are necessarily portable across all platforms. There is also the question of availability of the application on each receiver's platform. An organizational standard might specify "everyone will have Lotus, Word Perfect, and Oracle available", thereby enabling 'multimedia' documents (that consist of, say, Word Perfect documents that include Oracle tables and Lotus spreadsheet views) to be freely passed around. MEDIA TYPES On a multitasking, multimedia machine like the Amiga, this sort of an architecture already more or less exists, although it is not integrated with an embedded-editor protocol or full hypermedia system. Programmability is provided through AREXX, which Amiga applications support to enable remote control. Basic media forms like music and graphics are defined by IFF, the Interchange File Format. IFF started as a set of workfile formats for graphic programs, defining types like 640x480 pictures or sound bites, but now more complex forms like animations or 3D models are typically defined more by application programs, and adopted by the community of users, and often by new programs that support the IFF formats defined by the trailblazers. This is similar to the way every PC spreadsheet converts to/from Lotus files. MORE COMPLEX MEDIA As PCs and Macs acquire multimedia and multitasking abilities, it seems logical that minimal formats for exchange of spreadsheets, relational tables, etc., will develop, paralleling those for exchange of basic media objects. The Mac already has a prototype of such a system, with its "resource fork". The application program decides where and when each resource is used in the presentation, but the resource itself is interchangeable with others of its type - the application is simply a framework for the presentation of resources. >Now, if I understand the standards you have described (and, I may not >understand them correctly), they are descriptions of application program >interfaces that allow executing processes to manipulate mm objects. Not quite. Executing processes can manipulate ANY OTHER DOCUMENT THROUGH ITS ASSOCIATED APPLICATION, just as if they were the human user, and often with additional capabilities. The set of MM object types is not fixed, in effect a new type is defined every time a new application is built, and a new object of that type is created every time someone builds a document using it. So if I use an animation program and create the animation "Bedtime for Bonzo", any other program can run it/change it/etc. But this is only the first part. Some of these systems also define an embedded-viewing protocol so that all of these parts can be presented as part of a single hypermedia document. That document's "architecture" need not be standardized, as ANY APPLICATION can support the inclusion of such multimedia bits and pieces. In other words, I can include paragraphs formatted in WordPerfect in my Lotus spreadsheet, just as easily as vice versa. And changes are propagated properly. There is now only an organizational need for standards. The technical barriers are gone. >This is obviously an important kind of standard, but I fail to see how >one of these standards can be said to be a "mmm document standard". To Each application is its own, and it is true that none is really standard. But it would hardly matter, as the capabilities of each application would meld into a single whole with one set of functions available from anywhere. There is a set of types that continues to grow, and it is true that at any given point in time there will be more available types than standard types. >be useful, one would have to define an interchange format for each >standard. Now, this might be possible for any one of these standards, >but given the original impetus for them (application program tool >kits/standards), I'm not sure they lend themselves to mail standards. Consider the Unix mail community. People have few qualms about mailing files incomprehensible without rot13, UUencode, TAR, SH, csh, troff, etc.. In effect the "standard" has emerged from constant use, and the usefulness of the system is not drastically reduced by the proliferation of types. The ones that have tended to survive are those really represent a single kind of problem. >To stretch the analogy a little, I could claim that X is a graphics mail >standard, since X allows applications to manipulate graphical objects. >But, I hope no one would make this claim. X does not allow applications to arbitrarily invoke the functions of other applications. However, media objects as defined by the X protocols, plus C or other programs written to present these to the user, could be said to constitute a proto-standard. Similarly, a lot of people with bandwidth to burn mail HyperCard stacks to each other... >Am I way off base here? Or, are you suggesting that we start with (one >of) these standards & come up with an appropriate interchange format for >them. Perhaps. I would like to make a list of desirable minimal interchange formats (types we would like to see standardized) and perhaps identify likely existing candidates for each. Industry groups are already working on sound bites, musical notation, animations, video frames, relational tables, spreadsheets, etc., etc., and it would seem that all we need to do is have a list of such widely-recognized minimal standard interchange formats. We could write and exchange very minimal readers/writers/interpreters for them, work on new and more widely-compatible interchange formats, or define prototype architectures to simply store and transmit them, and invoke their functions. This is a very bottom-up approach to the problem, but in fact it is happening today, and people are sending "multimedia mail" in HyperCard and other formats, but no concerted effort seems to be made at building a set of interchange formats that arises from practice. Something like NewWave could be a very acceptable mm document standard on single platforms, if the applications used in 'hot-linking' were common or minimal enough (like the IFF editors/viewers on the Amiga). It remains to define a rational set of foundation types, and interchange standards across platforms. NewWave itself might accomplish much of this by bridging DOS and Unix, and the OMG is definitely set to do so across the platforms of the seventy-odd companies that have joined. Now, they might use ODA as their basic set of types, providing minimal 'applications' to deal with these, but their means of building new types would be very different. For this community, the questions should be: "which types should be defined by standards body fiat, which by de facto standards, which by negotiation of an interchange format ?", "how should we be defining new types ?", and "will people accept a closed system where capabilities cannot be seamlessly extended by user-group agreement ?" Craig Hubley kid after Live Aid: "Is that it?" Craig Hubley & Associates --------------------------------- craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig -- Craig Hubley kid after Live Aid: "Is that it?" Craig Hubley & Associates --------------------------------- craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
lord@sgi.com (Tom Lord) (08/24/90)
In article <UamjK4S0M2YtM5IlAl@thumper.bellcore.com> nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) writes: >I think that it is evident that eventually some kind of format standard >for multimedia mail will have to be adopted. I also think that *none* >of the current conceivable contenders are appropriate, and that some >basic research on document representation technology still needs to be >done. In my opinion, a standard would be premature. > I agree with the conclusion that a standard would be premature, and I'll go one better: I think [with apologies to my friends] that the exchange format is the wrong place invest effort. My biggest reason for saying this is that I don't believe there exists any real agreement about what `multimedia mail' really is. Consequently there can be no agreement about what infomration has to be included in a mm mail message. Exchange formats seem to me to be only a very small piece of a much larger multimedia question. The question is posed as new technologies come on line: new interaction techniques, audio and visual processing, new database technologies etc. As I see it, the unanswered question is how all these new parts interact and can be put together. Talk about multimedia documents, and consequently multimedia mail, falls right into the middle of these issues. Because the functionality of multimedia mail is unknown, an exchange format standard at this point faces two choices: 1. Choose a probably anemic notion of mm functionality and hold back the state of the practice for the life of the standard. 2. Write the standard as a language in which the functional characteristics of the mail can be described. Hope that your language matches the capabilities of emerging mm software. The second is the better approach, but better still would be to bag the exchange format altogether and concetrate directly on mm question itself. -t --
craig@gpu.utcs.utoronto.ca (Craig Hubley) (08/24/90)
Jonathan Rosenberg says: >If I understand you correctly, you're suggesting that the interchange >format for such applications is just whatever file format the >application happens to use. If so, then this seems like a bad place to >start looking for mm document standards (for mail or otherwise). In I didn't say it was a good place, just that it provided some immediate functionality and was already providing de facto "mm document standards" on several platforms. As applications are optimized to take advantage of a generalized object manager, the data formats tend toward sanity... at least in my opinion. >particular, this file format is particular to its generating application >(since that's what it's used for) and the format will, in general, only >include such information as is necessary for the application's Yes. The historical solution is to have one popular application's file format be copied by other applications, which can import its workfiles. They know about such limitations and when they import a file, deal with them. If you have Lotus, its limitations don't matter. If you don't, the application you *do* have knows how to deal with the limitations of Lotus's representation, expanding that rep. to its own, richer, format before using it. A problem arises in that you would have to know someone else had Lotus so that your Excel spreadsheet could be sent in Lotus form. The historical solution to *this*, as we've seen with modems, is to build systems that support multiple fallback representations if the first-choice isn't there. So you might include an Excel spreadsheet as 'first choice', and a Lotus version as 'last resort', or a passive chart pulled out of the spreadsheet format by a utility if the user has no spreadsheet at all... >applications as the generators of document standards: the interchange >representation is ... not designed as an interchange medium for use among >heterogeneous systems & applications. True. However, as I point out, alternate interpreters of the same data (other applications) tend to compensate for this, by bending over backwards to read files built by the de facto standard. And if you have the de facto standard application, the file is tailor-made for you anyway. This does not solve cross-platform issues, but some interchange formats like Rich Text Format begin to try. My thesis is these attempts begin to bridge the gap and make a short-term, if not long-term, practical solution. >interpretation above. This sounds like a "standard" based on people >using a common set of (versions of) application programs. Exactly. The "corporate" definition of "standard"... like it or not, there are plenty of places where Lotus is THE spreadsheet, and Word is THE word processor... their influence will be felt somehow... >I humbly submit that your examples are at the wrong level: you're >describing applications that may be suitable for manipulating a document >in some standard representation. My question is, and always was, how does that standard representation arise? ** MY POINT ** I submit that the needs of application developers to support their programs across multiple platforms, to remain compatible with files created by their old versions, and import and export files to the market leading products, solve many of the same problems as a standards committee. To not be aware of this is a mistake. Furthermore, applications program *interoperability* is on the rise, and the frameworks for this are perfectly suitable to *BE* multimedia mail or document systems. If I have a standard representation (good, bad, market leader, ISO, ANSI, corporate, whatever) for each data type, and an application of my (my organization's, or my country's) choice that can interpret that type, and a framework for interlinking the applications such that any one of them can host a heterogenous "multimedia document", then I do not need any other architecture to send "multimedia mail". If you want to be more specific and say "heterogenous network multimedia mail, world-standardized and guaranteed viewable on arbitrary nodes", by all means do so, and more power to you. But the world is not waiting on this... good or bad, it is plowing ahead. ** END POINT *** >I admit that it may be worthwhile to >standardize on aspects of some of these applications (e.g., look & feel, >application program interface). But, these standardizations are not the I don't believe in standardizing "look & feel" at all, although I believe strongly in standardizing APIs. There are plenty of toolkits out there that let you write one source for Open Look/Motif, or PM/Windows, or the Mac/Windows, and the IEEE has already decided to standardize API and leave look & feel to personal preferences, where it belongs, and to lawyers, who get a piece of everything... >same as standardizing on a document architecture suitable for >interchange. >> Each application is its own, and it is true that none is really standard. >> But it would hardly matter, as the capabilities of each application would >> meld into a single whole with one set of functions available from anywhere. >> There is a set of types that continues to grow, and it is true that at any >> given point in time there will be more available types than standard types. > >Huh???? If any 'document' supports inclusion of any other 'document' of any type, and the subparts are editable without visibly changing modes, then your entire system is, from the user's point of view, only one "application". The set of document types supported will naturally come to be standardized through specialization. If I am freed from having to build a pseudo-word- processor into my spreadsheet or database, then I will come up with a better and more succinct representation of spreadsheets instead. A multimedia mail "standard system" is likely to fail against such competition for the same reason that "integrated applications" fail against their more specialized competitors... people want each tool to do *one thing*, *well*. A consequence of doing so, is that data representation tends to evolve to a complete list of essential elements... and nothing more. I don't WANT tabs in my spreadsheet. If I need them, I will create a word-processing document, include the spreadsheet, and add the tabs in the WP view. Then I can include *that* in another WP document, and I have my tabs. >> Consider the Unix mail community. People have few qualms about mailing >> files incomprehensible without rot13, UUencode, TAR, SH, csh, troff, etc.. >> In effect the "standard" has emerged from constant use, and the usefulness >> of the system is not drastically reduced by the proliferation of types. >> The ones that have tended to survive are those really represent a single >> kind of problem. > >Gee, I would argue that usefulness IS affected by the use of these >encoding techniques. What do you think happens when a piece of mail >that requires csh ends up on a PC or an IBM mainframe? Usefulness to the *community* that passes the stuff around is not affected. If you are not part of that community, well, then you have other problems too. But in fact it will be a *very long time* before a standards body gets around to really coming up with acceptable standard script languages and operating environments. To the degree is it happening, POSIX and maybe X/Open are doing it. But you can get csh for a PC, anyway. >>>To stretch the analogy a little, I could claim that X is a graphics mail >>>standard, since X allows applications to manipulate graphical objects. > >> X does not allow applications to arbitrarily invoke the functions of other >> applications. > >I don't see the relevance of this comment. Because you didn't get the implication of the arbitrarily-nested 'type'. What the object management systems are trying to build is an architecture that makes every piece of work done on a computer into an object, which encapsulates its own functionality. Sending data with code that operates on it, as is often done in NeWS, is a start down this road. >> However, media objects as defined by the X protocols, plus >> C or other programs written to present these to the user, could be said to >> constitute a proto-standard. > >It may be a "proto-standard" (whatever that is), but it's in no way A strong prototype useful as a jumping-off point for standards discussion. Typically a de facto standard, but X itself didn't start out as one. >>suitable for use as a general-purpose mm mail standard. Does anyone >>want to claim otherwise? ANSI-standard C code, written to require only POSIX system facilities and the upcoming IEEE-standard GUI API, and straightforward file representations of the X bytestreams, should move all right: Any system with a POSIX-compliant OS, an Xwindows-compliant GUI, and a C compiler could display it. Not much in the way of real formatting or interactivity, though... >Sure -- and if we all agree to only use HyperCard to edit/present mm >documents, this would work just fine. But, given the heterogeneous >world that exists I fail to see the relevance of this point. Only that there are plenty of people willing to make this sort of compromise, and it would be better to learn from what they were doing than invent a totally different mechanism. I have not yet heard an adequate justification for this division of effort, which will no doubt cause problems later. What I see, is the standards people working on data representation, and the object management people working on function, and precious little thought about how they are going to come together, with some exceptions you point out. >> candidates for each. Industry groups are already working on sound bites, >> musical notation, animations, video frames, relational tables, spreadsheets, >> etc., etc., and it would seem that all we need to do is have a list of such >> widely-recognized minimal standard interchange formats. We could write and >> exchange very minimal readers/writers/interpreters for them, work on new and >> more widely-compatible interchange formats, or define prototype architectures >> to simply store and transmit them, and invoke their functions. > >This sounds like it would result in a bunch of unrelated media >representations (we already have that situation). How, in your This did not happen with IFF. In fact, the media types converged strongly. Problem is, Microsoft, Apple, Sun, IBM, and DEC aren't real interested in building IFF equivalents for their own systems, although Apple got halfway there (with resources) and stopped. >approach, would we ever end up with a means for integrating multiple >media into a single "document"? Do we all need to agree on a finite set >of specific applications to perform this integration? No, but each circle of people who need to exchange MM mail among themselves does. Not to the specific application or version like today, but to a compatible family of same which is created by application portability, backward compatibility, and importing/exporting files from the market leader. >ODA does, in fact, make use of >several such formats. The geometric graphics format (CGM) and the >raster graphics formats (Group 3 & 4) are based on (very) widely-used >formats. These formats did arise in practice. This is heartening. Me: >> Something like NewWave could be a very acceptable mm document standard on >> single platforms, Jon: >Something like NewWave could be a very acceptable standard for >application programs to use to manipulate a mm document standard on single >platforms, if ... Both: >if the applications used in 'hot-linking' were common > or minimal enough (like the IFF editors/viewers on the Amiga). I think there is some conflict in our use of the word "document" - it has two meanings: first, as a workfile associated with an application program, which might be interpreted as a (however inadequate) media type, and second, as an active collection of such things that are integrated into a presentation. Since things like spreadsheets consist of formulas and data cells (simpler types), and text documents consist of paragraphs and words (again, simpler types), in principle the two ideas are the same. However, on today's operating systems, they are not treated that way. When they are, there will be a whole new ball game to play. NRI.RESTON.VA.US!vcerf says: *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. I agree too. But that information can be added incrementally through encapsulation and nesting. *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. But it *does* get explicitly mentioned by the compatible applications which import the files. If no such capabilities were added, these applications could hardly compete. Thus this is a more incremental approach to defining the 'correct' contextual information. *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" As I said, the number of available (and usable!) types exceeds the number of standard types... *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... Yes, problems, problems, but as the standards solidify we will want more and richer types, and we will generate more such problems. The problems will never go away. My question is, how do we make the decision and adjustment process a social rather than bureacratic one ? *I think we will need to accommodate transfer of things like *TIF, CGM, and other common application formats around, while Right on. *searching for much more general, architecturally sound *frameworks for exchange of complex objects. As I mentioned earlier, this is exactly what the Object Management Group is trying to do. And they are not just thinking about 'multimedia mail', but about much more difficult problems... we don't need two parallel frameworks. You don't need NeWS and NewWave alongside each other... something like NewWave can do the whole job. zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!lord says: $Exchange formats seem to me to be only a very small piece of a much $larger multimedia question. The question is posed as new technologies $come on line: new interaction techniques, audio and visual processing, $new database technologies etc. As I see it, the unanswered question $is how all these new parts interact and can be put together. Talk $about multimedia documents, and consequently multimedia mail, falls $right into the middle of these issues. Couldn't agree more. The real question is the interaction of *objects*, and the fact that some objects happen to be displayable to humans and have specific human-perceptible manipulations is really irrelevant so far as the architecture is concerned. At this point it is an API issue. $Because the functionality of multimedia mail is unknown, an exchange $format standard at this point faces two choices: $ $ 1. Choose a probably anemic notion of mm functionality and $ hold back the state of the practice for the life of the $ standard. Many standards-oriented folks seem to accept this as inevitable. $ 2. Write the standard as a language in which the functional $ characteristics of the mail can be described. Hope that $ your language matches the capabilities of emerging mm $ software. I don't see why that language has to be anything special. Instead of inventing a new 4GL mess like SQL, use something object-oriented and widely accepted like C++. Soon it will be an ANSI standard anyway. Or use CLOS, which already is. Sure it's a mess, but it will work, and it provides a *mechanism for the definition of new types*. Add classes for each media type as they are invented, distribute binaries for each particular machine and window system. $The second is the better approach, but better still would be to bag $the exchange format altogether and concetrate directly on mm question $itself. I don't care what types we will eventually build. I only care how to build types, and I will use whatever tools are available to do so, until I figure out what the common needs and parameters are... the better and more general the tool for building types, the faster we will learn, and the better my eventual MM system will be. I guess, in sum, I am arguing for a rapid prototyping approach - make it easier to build types, and use general- purpose architectures that will deal with arbitrary types that you have built. Analogizing it to the user-interface design situation, I would claim that you learn more, and can do more, with a UI toolkit provided in an object-oriented language, than you can from using a UIMS of fixed capabilities. In multimedia, we will learn more from having a testbed for new types, than from deliberations of a standards committee. Craig Hubley kid after Live Aid: "Is that it?" Craig Hubley & Associates --------------------------------- craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig -- Craig Hubley kid after Live Aid: "Is that it?" Craig Hubley & Associates --------------------------------- craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig