[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 rfc2077                                        
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.
                                                          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).


        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

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

   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

   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

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

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

   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

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:


   Similarly, the VRML discussion list has been archived as:


   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

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

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

   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

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

   [8] C. Parks, "Registration of new Media Type application/iges",
   application/iges, 1995.

   [9] G. Bell, A. Parisi, M. Pesce, "The Virtual Reality Modeling
   http://sdsc.edu/SDSC/Partners/vrml/Archives/vrml10-3.html, 1995.

   [10] S.D. Nelson, "Registration of new Media Type model/mesh",
   (will be)
   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

   [14] L. Rosenthal, ``Initial Graphics Exchange Specification
   (IGES) Test Service'',

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,
   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

   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

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:

   A 100,000,000 zone mesh:

   Seismic wave propagation through a computational mesh:

Nelson, Parks, Mitra                                        [Page 14]

INTERNET-DRAFT          Model Primary MIME Type          October 1995

   Additional example Mesh objects:

   Various IGES compliant test objects:

   VRML Test Suite:

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

Nelson, Parks, Mitra                                        [Page 15]