fredc@umrisca.isc.umr.edu (Fred Clauss) (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
available, platforms supported, and price ranges).
Please reply by mail, and I'll summarize in a future post.
--
Fred Clauss INTERNET: fredc@isc.umr.edu (preferred)
Intelligent Systems Center or flc@umree.ee.umr.edu
University of Missouri UUNET: {occrsh|sunarch}!umree!flc
Rolla, MO 65401 BITNET: S081192@UMRVMAjxr@THUMPER.BELLCORE.COM (Jonathan Rosenberg) (08/17/90)
From: Einar Stefferud <Stef@nrtc.northrop.com> Date: Thu, 16 Aug 90 11:45:57 -0700 Message-Id: <21001.650832357@nma.com> Sender: stef@nma.com > What are the standards bodies (ccitt/iso/iec) doing in the MMM arena? There are a number of standards activities involving multi-media documents (that's the nice thing about standards: there's so many to choose from :-) We could probably (certainly) argue about whether a mmm standard is the same as a mm doc standard. It's undoubtedly not the case that a mm doc standard can just be taken as it is & used as a mmm standard. But, a mm doc standard (in particular, one with a defined interchange format) has got to be a good place to start. Anyway, here's the (dejure or de jure) standards activities relating to mm doc's that I know of: 1) Office Document Architecture (ODA). You are probably somewhat familiar with this standard, which is ISO 8613. ODA defines a document architecture for multi-media documents that allows the specification of logical structure (the logical organization of the document) and/or its layout structure (how thw document is to be imaged). The ODA architecture makes it easy to plug in new media types. It currently supports multi-font structured text, geometric graphics & raster graphics. There is lots of work going to introduce new media (e.g., audio, video, spreadsheets). ODA is a large, complex standard. 2) Compound Document Architecture (CDA) Digital Document Interchange Format (DDIF). CDA is DEC's mm doc standard. It appears to me that it actually encompasses a rather large suite of sub-standards, tools & applications. DDIF is, I believe, one of the possible representatiuons for a CDA document. DDIF is based on a early version of ODA, which was then extended/modified to take care of some perceived problems. Unfortunately, I don't know enough about CDA/DDIF, but my impression is that they have done a nice job & have that it is fact, a great improvement over ODA, while retaining many of its good points. 3) HyTime. HyTime is an ANSI "Draft Standard" (I think I have the terminology correct), which is actually a subset of a larger standard known as the Standard Music Description Language (SMDL). SMDL is an SGML application designed for musical presentations. HyTime is the subset of SMDL that deals with Hypermedia & time-dependent notions. Unfortunately, I don't know enough about HyTime to comment much more on it. Except that it is my impression that HyTime basically presents a shell in which any particular must fill in lots of details to obtain a useful document model. HyTime is onloy a high-level document architecture & leaves the choice of media representations up to applications. 4) Multimedia Hypermedia Expert Group (MHEG). This group is ISO/IEC JTC1/SC2/WG12 & is a sister group to MPEG (Moving Picture Expert Group) & JBIG (Joint Bilevel Image Group), which you might be aware of. MHEG is a fairly new effort & I believe that the group's future is rather uncertain: for various political reasons, they may disappear or be absorbed into the ODA work. Leaving politics aside, the purpose of MHEG is to define an architecture that allows the composition of media objects into "documents" allowing the representation of hypermedia-like concepts & simple time-dependent actions. Like HyTime, MHEG does not define the representations of its content but will refer to other existing standards (particularly those in its sister working groups). MHEG is fairly new & whether it has staying power remains to be seen. 5) Miscellaneous. There are a number of miscellaneous efforts that I know of & can mention briefly. Document Syntax & Semantics Specification Language ? (DSSSL): I always get confused about what the acronym means.) This is a non-standards-body activity (as far as I know) attempting to define an SGML application that has rich logical & layout semantics. I have only seen preliminary documents on it & my impression is that anything real is several years away. Rich Text Format (RTF): is a Microsoft mm doc format used by the latest versions of Microsoft Word (I believe). I have looked at RTF in some depth & my own belief is that it is simply not well enough though out or defined to be a serious contender. > Is there a reason to engage in some more formal MMM pre-standards > activities, such as preceded X.400, X.500 and NetworkManagement. Because there are not enough reasonable examples around, believe it is too early to actually standardize on a mm doc architecture. However, I do believe that the pre-standards activities you are referring to are worthwhile. I would very much like to participate, although I won't be at Zurich. I'll send a discussion paper with Nathaniel. JR
jxr@THUMPER.BELLCORE.COM (Jonathan Rosenberg) (08/23/90)
Date: 22 Aug 90 05:17:24 GMT From: news-server.csri.toronto.edu!utgpu!craig@rutgers.edu (Craig Hubley) Organization: Craig Hubley & Associates Subject: Re: Multi-media mail standards; Forw: Use of ODA in the Internet To: mmm-people@venera.isi.edu >>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. 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 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 execution. So, for example, if the application supports only a single fixed margin for text, then presumably the format will not include any information about margins, since that information is embedded in the application. And, that's exactly the problem with considering such applications as the generators of document standards: the interchange representation is peculiar to the application (and, sometimes, its implementation) and not designed as an interchange medium for use among heterogeneous systems & applications. > 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. Arggghhh ... now, I feel more certain that I was correct in my interpretation above. This sounds like a "standard" based on people using a common set of (versions of) application programs. 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. 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 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???? > . . . > 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? >>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. I don't see the relevance of this comment. > 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 suitable for use as a general-purpose mm mail standard. Does anyone want to claim otherwise? > Similarly, a lot of people with bandwidth to burn mail HyperCard stacks to each other... 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. >>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 sounds like it would result in a bunch of unrelated media representations (we already have that situation). How, in your 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? > 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. Well, that just ain't so. For example, 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. > 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). I disagree (as you might have guessed by now). I would rephrase your statement to say Something like NewWave could be a very acceptable standard for application programs to use to manipulate a mm document standard on single platforms, if ... > . . . Comments encouraged. JR
vcerf@NRI.RESTON.VA.US (08/23/90)
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