Network Working Group S. D. Nelson INTERNET DRAFT Lawrence Livermore National Laboratory Category: Standards Track Livermore, CA 94550, USA. Expires in six months C. Parks National Institute of Standards and Technology Gaithersburg, MD 20899, USA. Mitra Worlds Inc. San Francisco, CA 94107, USA. October 1995 The Model Primary Content Type for Multipurpose Internet Mail Extensions Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. The original version of this draft benefitted from discussions between the authors and their respective communities. The previous version of this draft was in the "ietf-types" list through four revisions and encompassed about 10 weeks of feedback. Draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use draft documents as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Introduction The purpose of this Internet Draft is to propose an update to Internet RFC 1521 to include a new primary content-type to be known as "model". RFC 1521[1] describes mechanisms for specifying and describing the format of Internet Message Bodies via content-type/subtype pairs. We believe that "model" defines a fundamental type of content with unique presentational, hardware, and processing aspects. Various subtypes of this primary type are immediately anticipated but will be covered under separate documents. Nelson, Parks, Mitra [Page 1] INTERNET-DRAFT Model Primary MIME Type October 1995 Table of Contents: 1. Intended Audience for this Document. 2. The Need for "model" and the Definition 3. Consultation Mechanisms. 4. Encoding and Transport 5. Security Considerations Section 6. References and Citations. 7. Authors' Addresses. 8. Suggested Registration Mechanism for New Model/Subtype Values 9. Appendix 10. Acknowledgements 1. Intended Audience for this Document. This is directed at anyone who is concerned with implementing Electronic Mail, Gopher, World-Wide Web and other information services supporting MIME (RFC 1521) in a local environment where model information needs to be processed. We do not expect the ``average'' user to concern themselves with the details of defining specific Media types, but we would expect them to have access to local knowledge, or to specific examples and implementations of the various Media types. This Internet Draft is a discussion document for an agreed definition, intended eventually to form a standard accepted extension to RFC 1521. We are also targeting developers of input/output filters, viewer software and hardware, those involved in MIME transport, and decoders. 2. The Need for a Model Primary Content Type. The following quote by MIT Lab Director Nicholas Negroponte appeared in the Scientific American Special Issue 1995 p.102; "In the long run, model-based image transmission and encoding are better than transmission of pictures alone. Mathematical models of a scene can describe the spatial relations of the objects in it and maneuver them through space. The idea of capturing a picture with a camera is obsolete if one can instead capture a realistic model from which the receiver can generate any picture. For instance, from a real-time model of a baseball game, a fan watching at home could get the view from anywhere in the ballpark -- including the perspective of the baseball." Each subtype in the model structure has unique features, just as does each subtype in the other primary types. The important fact is that these various subtypes can be converted between each other with less loss of information then to that of other primary types. This fact groups these subtypes together into the model primary type. All of the proposed subtypes have several features in common and that are unique to this primary type: Nelson, Parks, Mitra [Page 2] INTERNET-DRAFT Model Primary MIME Type October 1995 1. have 3 or more dimensions which are bases of the system and form an orthogonal coordinate system (any orthogonal system is sufficient). 2. contains a structural relationship between model elements. 3. have calibration factors to physical units (force, momentum, time, velocity, acceleration, size, etc.). Thus, an IGES file will specify a building of non-arbitrary size, computational meshes and VRML models will have real spatial/ temporal units. This allows for differing elements to be combined non-arbitrarily. With these assumptions: a. the default dimensionality will be spatial and temporal (but any are allowed). b. it is presumed that models will contain underlying structure which may or may not be immediately available to the user. (fluid dynamics vector fields, electromagnetic propagation, related IGES dimensional specifiers, VRML materials and operators, etc.) c. it is assumed that basis set conversion between model domains is lossless. The interpretation of the data may change but the specification will not. i.e. convert the model of the U.S.A. Gross Domestic Product into a VRML model and navigate it to explore the variances and interrelationships. The model has many dimensions but also ``passages'' and ``corridors'' linking different parts of it. A similar situation is true for meshes and CAD files. The key is identifying the basis set conversion which makes sense. d. models are grouped to assure LESS loss of information between the model subtypes than to subtypes of other primary types. (i.e. converting a chemical model into an image is more lossy than concerting it into a VRML model). To promote the implementation, use and development of such subtypes, we propose that a new primary media type of ``model'' be introduced. 2.1 Model Data Types are Well Defined and Widely Used Already. 2.1.1 VRML Data Types The 3D modeling and CAD communities use a number of file formats to represent 3D models, these formats are widely used to exchange information, and full, or lossy, converters between the formats exist both independently and integrated into widely used applications. The VRML format is rapidly becoming a standard for the display of 3D information on the WWW. Nelson, Parks, Mitra [Page 3] INTERNET-DRAFT Model Primary MIME Type October 1995 2.1.2 Mesh Data Types For many decades, finite element and finite difference time domain codes have generated mesh structures which attempt to use the physical geometry of the structures in connection with various physics packages to generate real world simulations of events including electromagnetic wave propagation, fluid dynamics, motor design, etc. The resulting output data is then post processed to examine the results in a variety of forms. This proposed mesh subtype will include both geometry and scalar/vector/tensor results data. An important point to note is that many modern meshes are generated from solids constructed using CAD packages. Motivation for mesh grew out of discussions with other communities about their design requirements. Many CAD or scene descriptions are composed of a small number of complex objects while computational meshes are composed of large numbers of simple objects. A 1,000,000 element 3D mesh is small. A 100,000,000 element 3D structured mesh is large. Each object can also have an arbitrary amount of associated data and the mesh connectivity information is important in optimizing usage of the mesh. Also, the mesh itself is usually uninteresting but postprocessing packages may act on the underlying data or a computational engine may process the data as input. Meshes differ principally from other kinds of scenes in that meshes are composed of a large number of simple objects which may contain arbitrary non-spatial parameters, not all of whom need be visible, and who have an implicit connectivity and neighbor list. This latter point is the key feature of a mesh. It should be noted that most meshes are generated from CAD files however. The mesh type has association functions because the underlying physics was used to calculate the interaction (if you crash a car into a telephone pole, you get a crumpled car and a bent pole). Most interesting computational meshes are 4D with additional multidimensional results components. 2.1.3 IGES CAD Data Types (The following text is from "U.S. Product Data Association and IGES/PDES Organization Reference Manual," June 1995; by permission.) IGES, the Initial Graphics Exchange Specification, defines a neutral data format that allows for the digital exchange of information among computer-aided design (CAD) systems. CAD systems are in use today in increasing numbers for applications in all phases of the design, analysis, and manufacture and testing of products. Since the designer may use one supplier's system while the contractor and subcontractor may use other systems, there is a need to be able to exchange data digitally among all CAD systems. Nelson, Parks, Mitra [Page 4] INTERNET-DRAFT Model Primary MIME Type October 1995 The databases of CAD systems from different vendors often represent the same CAD constructs differently. A circular arc on one system may be defined by a center point, its starting point and end point, while on another it is defined by its center, its diameter starting and ending angle. IGES enables the exchange of such data by providing, in the public domain, a neutral definition and format for the exchange of such data. Using IGES, the user can exchange product data models in the form of wireframe, surface, or solid representations as well as surface representations. Translators convert a vendor's proprietary internal database format into the neutral IGES format and from the IGES format into another vendor's internal database. The translators, called pre- and post-processors, are usually available from vendors as part of their product lines. Applications supported by IGES include traditional engineering drawings as well as models for analysis and/or various manufacturing functions. In addition to the general specification, IGES also includes application protocols in which the standard is interpreted to meet discipline specific requirements. IGES technology assumes that a person is available on the receiving end to interpret the meaning of the product model data. For instance, a person is needed to determine how many holes are in the part because the hole itself is not defined. It is represented in IGES by its component geometry and therefore, is indistinguishable from the circular edges of a rod. The IGES format has been registered with the Internet Assigned Numbers Authority (IANA) as a Multipurpose Internet Mail Extension (MIME) type "application/iges". The use of the message type/subtype in Internet messages facilitates the uniform recognition of an IGES file for routing to a viewer or translator. Version 1.0 of the specification was adopted as an American National Standards (ANS Y14.26M-1981) in November of 1981. Versions 3.0 and 4.0 of the specification have subsequently been approved by ANSI. The current version of IGES 5.2 was approved by ANSI under the new guidelines of the U.S. Product Data Association. Under these guidelines, the IGES/PDES Organization (IPO) became the accredited standards body for product data exchange standards. This latest standard is USPRO/IPO-100-1993. Nelson, Parks, Mitra [Page 5] INTERNET-DRAFT Model Primary MIME Type October 1995 2.2 The Role of Primary and Secondary MIME Content Types. Central to all these developments is the MIME concept as defined in Internet RFC 1521 [1]. This defines standards for the inclusion of message bodies in e-mail messages and other information systems such as the World-Wide Web. A two level mechanism exists comprising top level and sub-types. The MIME top-level types exist to allow mail gateways and other agents such as World-Wide Web clients to do filtering and/or conversion properly, and to allow user agents to have a default behavior for certain classes of objects. Neither the currently accepted primary content types nor the existing sub types contain any explicit proposals for actions on message bodies containing model information. It is our intention in this Internet draft to suggest a mechanism for the handling of such information in a consistent and extensible manner with the existing MIME guidelines. Central to our argument is that the media content of model is quite different from "text", "image", "audio", or "video" media types, and the manner in which the information is likely to be processed and presented is also fundamentally different. Existing top-level types were chosen very carefully to reflect the capabilities required for the media and presentation, and not the specific subject matter. In this context, we argue that a "model" type has new generic media and presentation requirements that are not fulfilled by the image, audio, or video content types currently defined. For example, the default presentation behavior for the model content is expected to result in the rendering of a scene or interpretation in several dimensions, with some degree of navigation through modeled objects being possible, and with control over how individual objects (grids, cells, or buildings for example) are displayed. Also, models in general have an underlying structure which may not be just visual but may reflect mathematical relationships, physical phenomena, and interactivity between objects apart from the user. A degree of semantic interpretation in the process is essential. Model information is intrinsically three dimensional in space (and possibly one extra dimension for time) but in general can contain heigher dimensions due to the modeling of real objects which comprise a collection of well defined structures. We envision all model media types carrying very substantial semantic content, e.g. structural information relating to the individual objects and their relationships. For example, the presentation of a computational mesh of a building might include information about the stress/strain characteristics for the materials used. Further elaborations include model rotation, geometry calculations, extraction of numerical information, and calculation of associated properties. Nelson, Parks, Mitra [Page 6] INTERNET-DRAFT Model Primary MIME Type October 1995 For these reasons, we considered the existing "image" type to be too restrictive for the presentational needs specifically of the physical sciences community, and would actually inhibit further development. To an equal extent, the mesh type is needed because it includes fundamental results data which may be further post-processed to extract the desired information such as power flow, turbulence, loss, and diffraction. An image is intrinsically taken to be a two-dimensional representation - normally a 2D bitmap rather than an object collection. In this context, we note that there is no uniquely definable way of specifying how any 3D model could be presented as a two dimensional image. In three dimensional terms, several excellent "helper" programs for achieving a default process with various model contents are readily available to the community and have become widely used in the last few years. It can be said therefore that default actions on 3D model information have achieved a certain level of de facto status, which would be consolidated by this proposal. More elaborate and truly innovative forms of processing of the content are also envisioned, including association with scientific instruments, presentation to automated synthesis robots and harvesting via indexing agents searching for structural features or themes in the content. We note the situation with 3D stereo lithography machines which (for example) take IGES files and convert them into physical solids and similar techniques with "laminating" systems. Presentation of the media content in this context is quite different in nature from a display on a computer screen, and serves to emphasize the fundamentally different nature of these media types from other primary content types. We believe that such actions are not best implemented using the ``application'' type but should be allocated to a separate type to convey the generic and semantic nature of the content, rather than necessarily the subject content. The anticipated subtypes (see below) share a common structural thread which ``application'' does not convey. 3. Consultation Mechanisms. Before proposing a subtype for the model/* primary type, it is suggested that the subtype author examine the definition (above) of what a model/* is and the listing (below) of what a model/* is not. Additional consultations with the authors of the existing model/* subtypes is also suggested. Nelson, Parks, Mitra [Page 7] INTERNET-DRAFT Model Primary MIME Type October 1995 Copies of Internet drafts and RFCs are available on: ftp://ftp.isi.edu/in-notes/ Similarly, the VRML discussion list has been archived as: http://vrml.wired.com/arch/ and discussions on the comp.mail.mime group may be of interest. Discussion digests for the existing model/* subtypes may be referenced in the respective documents. The mesh community presently has numerous different mesh geometries as part of different packages. Freely available libraries need to be advertised more than they have been in the past to spur the development of interoperable packages. It is hoped that by following the example of the VRML community and creating a freely available comprehensive library of input/output functions for meshes[11] that this problem will be alleviated for the mesh community. A freely available mesh viewer conforming to these standards is available now for various platforms. The IGES community has a suite of tests and conformance utilities to gauge the conformance to specifications and software authors are encouraged to seek those out from NIST[14]. 4. Encoding and Transport a. model/* is used for 3D geometric data which may be examined from multiple viewpoints. It may require specialized 3D acceleration hardware for effective use on some platforms. Typical rendering of subtypes of model is a 2D projection of the 3D scene from some particular initial viewpoint, perhaps with hidden line and hidden surface removal, perhaps with perspective. User agents typically provide the ability to progressively alter the viewpoint and generate new 2D pictures, giving the illusion of moving through the scene. Particular subtypes of model may provide more than one scene and these may be related in some sort of temporal sequence. Within each scene, multiple viewpoints are possible This type differs from image (for example, a raytraced view of a particular scene) in that multiple viewpoints are possible; a rendered view of a scene to produce a 2D picture implies a fixed viewpoint, and should be labeled as an image primary type Nelson, Parks, Mitra [Page 8] INTERNET-DRAFT Model Primary MIME Type October 1995 This type differs from video (for example, a video flythrough of a 3D scene) in that there is enough information to allow user selectable viewpoints, where as there is insufficient information in a video of a flythrough to alter the viewpoint. This type differs from general 3 dimensional data, for example recordings of temperature, pressure, and rainfall, in that pressure and rainfall are not independent basis functions of the space. b. A parameter which makes sense for all subtypes of model is the initial viewing condition, consisting of the view position (a 3D point), the view vector, and the up vector. This parameter is optional. Some subtypes will contain one or more viewing conditions as part of there internal data. If present, this parameter over-rides any internal viewing condition. Note that these parameters are not specific to visualizations on computer screens but also the default fabrication orientation on milling machines. c. Unrecognized subtypes of model should at a minimum be treated as "application/octet-stream". Implementations may optionally elect to pass subtypes of model that they do not specifically recognize to a robust general-purpose model viewing application, if such an application is available. d. Different subtypes of model may be encoded as textual representations or as binary data. Unless noted in the subtype registration, subtypes of model should be assumed to contain binary data, implying a content encoding of base64 for email and binary transfer for ftp and http. 6. Security Considerations Section The security implications of model MIME types do not differ from those relevant to RFC 1521. We reproduce the section in RFC 1521 for reference here; ``Security issues are discussed in Section 7.4.2 and in Appendix F. Implementors should pay special attention to the security implications of any mail content-types that can cause the remote execution of any actions in the recipient's environment. In such cases, the discussion of the application/postscript content-type in Section 7.4.2 may serve as a model for considering other content-types with remote execution capabilities.'' Nelson, Parks, Mitra [Page 9] INTERNET-DRAFT Model Primary MIME Type October 1995 Note that the data files are ``read-only'' and do not contain file system modifiers or batch/macro commands. The transported data is not self-modifying but may contain interrelationships. The data files may however contain a ``default view'' which is added by the author at file creation time. This ``default view'' may manipulate viewer variables, default look angle, lighting, visualization options, etc. This visualization may also involve the computation of variables or values for display based on the given raw data. For motorized equipment, this may change the position from the hardware's rest state to the object's starting orientation. The internal structure of the data files may direct agents to access additional data from the network (i.e. inclusions); the security limits of whom are not pre-supposed. Actions based on these inclusions are left to the security definitions of the inclusions. 5. References and Citations. [1] N. Borenstein, and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993. [2] Fitzgerald P., "Molecules-R-Us Interface to the Brookhaven Data Base", Computational Molecular Biology Section, National Institutes of Health, USA; see http://www.nih.gov/htbin/pdb for further details; Peitsch M.C, Wells T.N.C., Stampf D.R., Sussman S. J., "The Swiss-3D Image Collection And PDP-Browser On The Worldwide Web", Trends In Biochemical Sciences, 1995, 20, 82. [3] "Proceedings of the First Electronic Computational Chemistry Conference", Eds. Bachrach, S. M., Boyd D. B., Gray S. K, Hase W., Rzepa H.S, ARInternet: Landover, Nov. 7- Dec. 2, 1994, in press; Bachrach S. M, J. Chem. Inf. Comp. Sci., 1995, in press. [4] Richardson D.C., and Richardson J.S., Protein Science, 1992, 1, 3; D. C. Richardson D. C., and Richardson J.S., Trends in Biochem. Sci.,1994, 19, 135. [5] Rzepa H. S., Whitaker B. J., and Winter M. J., "Chemical Applications of the World-Wide-Web", J. Chem. Soc., Chem. Commun., 1994, 1907; Casher O., Chandramohan G., Hargreaves M., Murray-Rust P., Sayle R., Rzepa H.S., and Whitaker B. J., "Hyperactive Molecules and the World-Wide-Web Information System", J. Chem. Soc., Perkin Trans 2, 1995, 7; Baggott J., "Biochemistry On The Web", Chemical & Engineering News, 1995, 73, 36; Schwartz A.T, Bunce D.M, Silberman R.G, Stanitski C.L, Stratton W.J, Zipp A.P, "Chemistry In Context - Weaving The Web", Journal Of Chemical Education, 1994, 71, 1041. Nelson, Parks, Mitra [Page 10] INTERNET-DRAFT Model Primary MIME Type October 1995 [6] Rzepa H.S., "WWW94 Chemistry Workshop", Computer Networks and ISDN Systems, 1994, 27, 317 and 328. [7] S.D. Nelson, "Email MIME test page", Lawrence Livermore National Laboratory, 1994. See http://www-dsed.llnl.gov/documents/WWWtest.html and http://www-dsed.llnl.gov/documents/tests/email.html [8] C. Parks, "Registration of new Media Type application/iges", ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ application/iges, 1995. [9] G. Bell, A. Parisi, M. Pesce, "The Virtual Reality Modeling Language", http://sdsc.edu/SDSC/Partners/vrml/Archives/vrml10-3.html, 1995. [10] S.D. Nelson, "Registration of new Media Type model/mesh", (will be) ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/model/ mesh, 1995. [11] "SILO User's Guide", Lawrence Livermore National Laboratory, University of California, UCRL-MA-118751, March 7, 1995, [12] E. Brugger, "Mesh-TV: a graphical analysis tool", Lawrence Livermore National Laboratory, University of California, UCRL-TB-115079-8, http://www.llnl.gov/liv_comp/meshtv/mesh.html [13] S. Brown, "Portable Application Code Toolkit (PACT)", the printed documentation is accessible from the PACT Home Page http://www.llnl.gov/def_sci/pact/pact_homepage.html [14] L. Rosenthal, ``Initial Graphics Exchange Specification (IGES) Test Service'', http://speckle.ncsl.nist.gov/~jacki/igests.htm 7. Authors' Addresses. S. D. Nelson, Lawrence Livermore National Laboratory, 7000 East Ave., L-153, Livermore CA 94550, USA. E-Mail: nelson18@llnl.gov C. Parks, National Institute of Standards & Technology Bldg 220, Room B-344, Gaithersburg, MD 20899, USA. E-Mail: parks@eeel.nist.gov Mitra, Worlds Inc., 605 Market St, San Francisco CA 94107, (415)281-1308 E-Mail: mitra@worlds.net Nelson, Parks, Mitra [Page 11] INTERNET-DRAFT Model Primary MIME Type October 1995 8. Suggested Registration Mechanism for New Model/Subtype Values This is explained in RFC 1590, "Media Type Registration Procedure", from which the following is quoted. This document should be consulted for further detail. ``Send a proposed Media Type (content-type/subtype) to the "ietf-types-request@uninett.no" mailing list. This mailing list has been established for the sole purpose of reviewing proposed Media Types. Proposed content-types are not formally registered and must use the "x-" notation for the subtype name. The intent of the public posting is to solicit comments and feedback on the choice of content-type/subtype name, the unambiguity of the references with respect to versions and external profiling information, the choice of which OIDs to use, and a review of the security considerations section. It should be noted that the proposed Media Type does not need to make sense for every possible application. If the Media Type is intended for a limited or specific use, this should be noted in the submission. After two weeks, submit the proposed Media Type to the IANA for registration. The request and supporting documentation should be sent to "iana@isi.edu". Provided a reasonable review period has elapsed, the IANA will register the Media Type, assign an OID under the IANA branch, and make the Media Type registration available to the community.'' 9. Appendices 9.1 Appendix I -- ``what is not a model'' 1. an "image" is not a model because it is only 2D (and all existing images are uncalibrated, although they need not be). "calibrated" means: this pixel=523nm at 0.03W/m^2 + 553nm at... 2. a video is not a model because it is only 2D spatially and it is spatially uncalibrated. video is (almost) temporarily calibrated. The implication in model is that it be greater than 2D spatially. 3. text is not a model because it is only 1D 4. audio is not a model because it is uncalibrated. audio can be physically/psychoacoustically 3D by using multiple source points. But at that point audio is not a model, it is the real thing (once it is calibrated). 5. a model/* is not an application because... Nelson, Parks, Mitra [Page 12] INTERNET-DRAFT Model Primary MIME Type October 1995 6. mathematical relationships fit into the definition of model/* but may lack structure. Existing definitions were added to the model/* definition list so that more emphasis is placed on structure to avoid confusion. 7. numerous data types used in the physical sciences are composed of many different forms of data: tables, charts, graphs, images, sounds, etc. The appropriate type for these is probably multipart/* (a guess). application/* may also be appropriate, but a generalized physical sciences type is obviously missing from the existing list since the data relationship is important. 9.2 Appendix II -- hardware stereo glasses, 3D lithography machines, automated manufacturing systems, data gloves (with feedback), milling machines, aromascopes, treadmills. 9.3 Appendix III -- anticipated model subtypes Upon acceptance of the model/* primary type, it is anticipated that a collection of subtypes will be registered by the respective authors covering several fields. Table 1 shows a partial list of what will be proposed in the future: The VRML type is gaining wide acceptance and has numerous parallel development efforts for different platforms. These efforts are fueled by the release of the QvLib library for reading VRML files; without which the VRML effort would be less further along. This has allowed for a consistent data type and has by defacto established a set of standards. Further VRML efforts include interfaces to other kinds of hardware (beyond just visual displays) and it is proposed by those involved in the VRML effort to encompass more of the five senses. Unlike other kinds of "reality modeling" schemes, VRML is not proprietary to any one vendor and should experience similar growth as do other open standards. The mesh type is an offshoot of existing computational meshing efforts and, like VRML, builds on a freely available library set. Also like VRML, there are other proprietary meshing systems but there are converters which will convert from those closed systems to the mesh type. Meshes in general have an association feature which is similar to the chemical bond system contained in the chemical types but also have the spatial organization similar to VRML. Most modern meshes are derived from CAD solids types of files. Nelson, Parks, Mitra [Page 13] INTERNET-DRAFT Model Primary MIME Type October 1995 Table 1 lists the proposed model sub-type names, together with one suggested filename qualified. Suggested 3 letter extensions are also provided for DOS compatibility but their need is hopefully diminished by the use of more robust operating systems on PC platforms. The ``silo'' extension is provided for backwards compatibility. Mesh has an extensive list of hints since the present variability is so great. In the future, the need for these hints will diminish. Table 1. Primary/sub-type Suggested qualifier(s) Reference model/iges igs,iges [8] model/vrml wrl [9] model/mesh+regular+static mshrs,mrs [10] model/mesh+unstructured+static mshus,mus [10] model/mesh+unstructured+dynamic mshud,mud,silo [10] model/mesh+conformal+static mshcs,mcs [10] model/mesh+conformal+dynamic mshcd,mcd [10] model/mesh+isoparametric+static mshis,mis [10] model/mesh+isoparametric+dynamic mshid,mid [10] The above sub-types are some of the anticipated types that are already in use. Notice that the IGES type is already registered as "application/iges" and that RFC states that a more appropriate type is desired. Note that the author of "application/iges" is one of the authors of this "model" proposal. The three immediately anticipated sub-types presently differ in the following ways: 1. IGES files contain elemental relationships 2. mesh files contain underlying physics and associations 3. VRML files contain a high degree of interactivity and exhibit containment (ownership). 9.4 Appendix IV -- Examples This section contains a collection of various pointers to examples of what the model type encompasses. A snapshot of a shipping cage crashing into the ground: http://www.llnl.gov/liv_comp/meiko/apps/dyna3d/cagefig2.gif A 100,000,000 zone mesh: http://www.llnl.gov/liv_comp/meiko/apps/hardin/PMESH.gif Seismic wave propagation through a computational mesh: http://www.llnl.gov/liv_comp/meiko/apps/larsen/movie.mpg Nelson, Parks, Mitra [Page 14] INTERNET-DRAFT Model Primary MIME Type October 1995 Additional example Mesh objects: ftp://fhp.llnl.gov/dist/silo/data/ Various IGES compliant test objects: http://www.eeel.nist.gov/iges/specfigures/index.html VRML Test Suite: http://www.chaco.com/vrml/test/ 10. Acknowledgements Thanks go to Henry Rzepa (h.rzepa@ic.ac.uk), Peter Murray-Rust (pmr1716@ggr.co.uk), Benjamin Whitaker (B.J.Whitaker@chemistry.leeds.ac.uk), Bill Ross (ross@cgl.ucsf.EDU), and others in the chemical community on which the initial draft of this document is based. That document updated IETF Internet Draft, draft-rzepa-chemical-mime-type-01.txt in which the initial chemical proposal was made, incorporated suggestions received during the subsequent discussion period, and indicated scientific support for and uptake of a higher level proposal incorporating physical sciences[2-7]. This Model RFC proposal benefited greatly from the previous groundwork laid, and the continued interest by, those communities. The authors would additionally like to thank Keith Moore (moore@cs.utk.edu), lilley (lilley@afs.mcc.ac.uk), Wilson Ross (ross@cgl.ucsf.EDU), hansen (hansen@pegasus.att.com), Alfred Gilman (asg@severn.wash.inmet.com), and Jan Hardenbergh (jch@nell.oki.com) without which this document would not have been possible. Nelson, Parks, Mitra [Page 15]