RFC 2077

RFC 2077: The Model Primary Content Type for Multipurpose Internet Mail Extensions 🎀

Part 1 of 3 💖

Okay bestie, this one's from January 1997 and it's written by S. Nelson (LLNL), C. Parks (NIST), and Mitra (WorldMaker) 👑. It's a Standards Track doc, so it's meant to become an actual standard. The header doesn't list anything it obsoletes or updates, but its whole goal is to propose an update to RFC 2045 ✨. Its big idea is a brand-new primary content type called "model" 🦋.

---

Status of this Memo 📜

So this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌈.

Introduction 🌸

The point of this memo is to propose an update to Internet RFC 2045 and add a new primary content-type called "model" 💅. RFC 2045 [1] explains how content-type/subtype pairs are used to describe the format of Internet Message Bodies 📬. The authors think "model" is a fundamental kind of content with its own presentation, hardware, and processing aspects 🔥. A bunch of subtypes of this primary type are expected right away, but those will get their own separate documents 🧚.

Table of Contents

      1. Overview.............................................  2
      2. Definition...........................................  2
      3. Consultation Mechanisms..............................  4
      4. Encoding and Transport...............................  5
      5. Security Considerations Section......................  6
      6. Authors' Addresses...................................  7
      7. Expected subtypes....................................  7
      8. Appendix.............................................  9
      9. Acknowledgements..................................... 13

---

1. Overview ✨

This doc is going to explain what a model is, show some examples, and talk about why it's useful to group models together 🍓. It's not going to get into the specific subtypes, because those have their own registrations 📝. A few of the expected subtypes are listed in section 7 💜.

This is a discussion document for a definition the authors agreed on, and the goal is for it to eventually become a standard extension to RFC 2045 🎀. They're also aiming this at developers of input/output filters, viewer software and hardware, people working on MIME transport, and decoders 💻.

2. Definition of a model 💅

A model primary MIME type is an electronically exchangeable behavioral or physical representation within a given domain 🦋. Every subtype in the model structure has its own unique features, just like every subtype in the other primary types does 🌈. The big thing is that these subtypes can be converted into each other with less loss of information than you'd get with other primary types 🔥. That's what groups them together into the model primary type 🫶. All of the expected subtypes share several features with each other, and those features are unique to this primary type ✨.

To loosely sum it up, models are multidimensional structures made of one or more objects 💖. If there are multiple objects, one of them defines the arrangement, setting, or relationship of the others 👑. All of these objects have calibrated coordinate systems, but those systems don't have to use the same units, and they don't have to have the same dimensionality 🧚. Here's the detailed version 🎀:

1. they have 3 or more dimensions that are the bases of the system and form an orthogonal system (any orthogonal system is sufficient) 💜.

This system is specifically defined in terms of an orthogonal set of basis functions [for a subspace of the L^2 function space] over a coordinate system of dimension 3 or more. Note that this does not rule out regular skewed systems, elliptical coordinates, different vector spaces, etc. 🌸

2. they contain a structural relationship between model elements 🔗.
3. they have scaling or calibration factors that are tied to physical units (force, momentum, time, velocity, acceleration, size, etc.) 📏. So an IGES file can specify a building of non-arbitrary size, and computational meshes and VRML models have real spatial and temporal units 🏗️. That lets different elements be combined in a non-arbitrary way 🍓.
4. models can be single objects or a collection of objects 🌈. These usually independent objects are arranged in a master/slave setup, so one object acts as the reference, or primary object, that defines how the other objects relate to each other and behave 👑. This is what makes it possible to create mathematical, physical, economic, behavioral, and other kinds of models, which are typically made of different elements 🦋. The key is in the description: these types describe how something "behaves", while typical data types describe how something "is" 🔥.

The inclusion of this "collective" system works similarly to the Email system's multipart/related type, which defines the actions of the individual parts 💅. Further specification of the model/* subtypes that use these properties is left up to the subtype authors 🫶.

With these assumptions in mind 💖:

a. the default dimensionality will be spatial and temporal (but any are allowed) ✨.

b. it is presumed that models will contain underlying structure that may or may not be immediately available to the user (fluid dynamics vector fields, electromagnetic propagation, interrelated 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. For example, you could 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 it also has "passages" and "corridors" linking different parts of it 🌈. A similar situation is true for meshes and CAD files 🎀. The key is figuring out the basis set conversion that makes sense 💜.

d. models are grouped so there is LESS loss of information between model subtypes than between subtypes of other primary types. For example, converting a chemical model into an image is more lossy than converting it into a VRML model 🔥.

Items c and d above are what define the grouping for model, and it's similar to how "images" and "videos" are grouped together, to make sure there's less loss of information 💖. Obviously, converting a GIF image to a JPEG image loses less information than converting a GIF image to an AU audio file 🙈.

4. Encoding and Transport ✨

a. okay so, if a model subtype isn't one you recognize, the bare minimum is treating it as "application/octet-stream" 🫶. Implementations may optionally pass unrecognized subtypes to a robust general-purpose model viewing application, but only if one is actually available 🧚.

b. model subtypes can be textual or binary 💅. Unless the subtype registration says otherwise, you should assume binary data, which means base64 content encoding for email and binary transfer for ftp and http 🎀.

c. the formal syntax for the model subtypes looks like this 💖:

Media type name:          model
Media subtype name:       xxxxxxxx
Required parameters:      none
Optional parameters:      dimensionality, state
                          (see below)
Encoding considerations:  base64 encoding is recommended when
                          transmitting model/* documents through
                          MIME electronic mail.
Security considerations:  see section 5 below
Published specification:  This document.
                          See Appendix B for references to some of
                          the expected subtypes.
Person and email address to contact for further information:
                          Scott D. Nelson <nelson18@llnl.gov>
                          7000 East Ave.
                          Lawrence Livermore National Laboratory
                          Livermore, CA  94550

The optional parameters hold starting conditions and variable values for the subtypes 🌸. The base set below is just for illustration, and each subtype will cover its own parameters in detail ✨.

dimension := string ; a number indicating the number of dimensions.
                      This is used as a "hint" in selecting
                      applicable viewer programs.

state     := string ; "static" or "dynamic".  In "static", the
                      observer may move about, thus effecting
                      translations, rotations, pans, zooms, etc.
                      but the data does not change.  In "dynamic",
                      the data itself is manipulated via
                      skews, elongations, scales, etc.  Note that
                      time evolution is still a static operation
                      since it is just a translation along one of
                      the principal dimensions while the elongation
                      of a cube or object deformation are dynamic
                      operations.

Also, this optional parameter list does not limit the ones each subtype specifies 🦋.

d. the specifics for each subtype are covered in that subtype's own description 🌈. Here's a typical MIME header for mail transport 📬:

To:   you@some.org
From: nelson18@llnl.gov
Date: Fri, 30 Aug 96 13:33:19 -0700
Content-Type: model/mesh; dimension="4"; state="static"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: model data file

I1ZSTUwgVjEuMCBhc2NpaQojIFRoaXMgZmlsZSB3YXMgIGdlbmVyY...
byBDb21tdW5pY2F0aW9ucwojIGh0dHA6Ly93d3cuY2hhY28uY29tC...
IyB1c2VkIGluIHJvb20gMTkyICh0ZXN0IHJvb20pCiAgIAojIFRvc...
.
.
.

---

5. Security Considerations Section 💀

Okay, bestie, this part is serious 😭. The data files are "read-only" 🔒, and they don't carry file system modifiers or batch/macro commands. The transported data isn't self-modifying, but it can have interrelationships 🕸️. The files can contain a "default view" that the author sets at creation time 👀. That default view can manipulate viewer variables, default look angle, lighting, visualization options, and so on. The visualization might also involve computing values for display from the raw data 🧮. For motorized equipment, this could move the hardware from its rest state into the object's starting orientation 🤖.

The internal structure of a data file can direct agents to fetch extra data from the network (i.e. inclusions) 🌐, and who gets to do that isn't pre-supposed 🚨. What happens with those inclusions is left to their own security definitions 🫣. More security comments for each subtype will be in that subtype's registration 📝.

---

6. 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
WorldMaker
1056 Noe
San Francisco, CA 94114
E-Mail: mitra@earth.path.net

---

7. Expected subtypes 🧚‍♀️

Table 1 lists some of the expected model subtype names 📋. There are suggested 3-letter extensions for DOS compatibility 💾, though hopefully the more robust operating systems on PCs mean we won't need them much anymore. The "silo" extension is there for backwards compatibility 🕰️. Mesh has a huge list of hints because the variability is just so big 🤯. Later on, those hints won't be as needed, since the files will be self-describing 🪞. This document doesn't register these subtypes. They'll be handled in separate documents 📂.

Table 1.

Primary/sub-type           Suggested extension(s)    Reference

model/iges                         igs,iges              [8]
model/vrml                         wrl                   [9]
model/mesh                         msh, mesh, silo       [10]

model/mesh is also expected to use a number of parameters that help the end user figure out the data type without examining the data 🔍. Note that mesh files are self-describing 🫶.

regular+static, unstructed+static, unstructured+dynamic,
conformal+static, conformal+dynamic, isoparametric+static,
isoparametric+dynamic

Those subtypes are some of the anticipated types already in use 💅. The IGES type is already registered as "application/iges", and RFC says a more appropriate type is wanted 👀. The author of "application/iges" is also one of the authors of this "model" submission, so application/iges will be re-registered as model/iges at the appropriate time 🔁.

VRML is gaining wide acceptance, with lots of parallel development efforts for different platforms 🌏. Those efforts are fueled by the QvLib library for reading VRML files, and VRML would be a lot less further along without it 📚. That has given us a consistent data type and, by de facto, a set of standards 🏆. Further VRML work includes interfaces to other kinds of hardware (not just visual displays), and the people behind VRML propose covering more of the five senses 👃👂. Unlike other "reality modeling" schemes, VRML isn't proprietary to any one vendor, so it should grow like other open standards 🌱.

The mesh type comes from existing computational meshing efforts and, like VRML, builds on a freely available library set 🧩. There are other proprietary meshing systems too, but converters exist that turn those closed formats into the mesh type 🔄. Meshes in general have an association feature so the connectivity between nodes is kept 🔗. It's worth noting that most modern meshes come from CAD solids files 🛠️.

---

8. Appendices ✨

8.1 Appendix A -- extraneous details about expected subtypes ✨

VRML Data Types

okay so the 3D modeling and CAD crowd uses a whole bunch of file formats to represent 3D models 🧚 these formats get passed around a ton, and full or lossy converters between them exist both as standalone tools and built right into popular apps. the VRML format is rapidly becoming a standard for showing 3D info on the WWW 🌈

Mesh Data Types

for many decades, finite element and finite difference time domain codes have been generating mesh structures 🕸️ they try to use the physical geometry of structures together with various physics packages to run real-world simulations of things like electromagnetic wave propagation, fluid dynamics, motor design, etc. the output data then gets post-processed so people can look at the results in a bunch of different forms. this proposed mesh subtype will include both the geometry and the scalar/vector/tensor results data. an important note: lots of modern meshes are generated from solids built in CAD packages 💅

the motivation for mesh came out of chats with other communities about their design needs. lots of CAD or scene descriptions are made of a small number of complex objects, while computational meshes are made of huge 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 carry an arbitrary amount of associated data, and the mesh connectivity info matters a lot for optimizing how the mesh gets used. also, the mesh itself is usually kind of boring, but postprocessing packages might act on the underlying data, or a computational engine might process the data as input 🙈

meshes differ mainly from other kinds of scenes because they're made of a large number of simple objects that can contain arbitrary non-spatial parameters. not all of those objects need to be visible, and they have an implicit connectivity and neighbor list. this last part is the key feature of a mesh 🔑 it should be noted that most meshes come from CAD files, though. 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 🦋

IGES CAD Data Types

(the following text is reproduced for reference purposes only, and it's 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 lets computer-aided design (CAD) systems swap information digitally 💖

CAD systems are being used in bigger and bigger numbers for every phase of design, analysis, manufacturing, and testing of products. the designer might use one supplier's system while the contractor and subcontractor use other systems, so there's a real need to exchange data digitally across all CAD systems 🫶

the databases of CAD systems from different vendors often represent the same CAD constructs in different ways. a circular arc on one system might be defined by a center point, its starting point, and its end point, while on another system it's defined by its center, its diameter, and its starting and ending angle 🤯 IGES makes data exchange possible by providing, in the public domain, a neutral definition and format for exchanging that kind of data ✨

with IGES, a 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 then from IGES 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. on top of the general specification, IGES also includes application protocols, where 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 figure out how many holes are in the part, because the hole itself isn't defined. it's represented in IGES by its component geometry, so it's 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". using the message type/subtype in Internet messages makes it easy to recognize an IGES file for routing to a viewer or translator 📬

version 1.0 of the specification was adopted as an American National Standard (ANS Y14.26M-1981) in November of 1981. versions 3.0 and 4.0 were later approved by ANSI. the current version, 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 🏆

8.2 Appendix B -- References and Citations 📚

[1] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996.

[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.

[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", ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/model/mesh, 1997.

[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

8.3 Appendix C -- hardware 🛠️

numerous kinds of hardware already exist that can process some of the expected model data types. they're listed here for illustration purposes only: stereo glasses, 3D lithography machines, automated manufacturing systems, data gloves (with feedback), milling machines, aromascopes, treadmills.

8.4 Appendix D -- Examples 🎬

this section contains a collection of pointers to examples of what the model type encompasses 🍓

example mesh model objects can be found on this mesh page: http://www-dsed.llnl.gov/documents/tests/mesh.html

various IGES compliant test objects: http://www.eeel.nist.gov/iges/specfigures/index.html

VRML Test Suite: http://www.chaco.com/vrml/test/

an image of a model of a shipping cage crashing into the ground: http://www.llnl.gov/liv_comp/meiko/apps/dyna3d/cagefig2.gif

an image of a 100,000,000 zone mesh: http://www.llnl.gov/liv_comp/meiko/apps/hardin/PMESH.gif

a video of a seismic wave propagation through a computational mesh: http://www.llnl.gov/liv_comp/meiko/apps/larsen/movie.mpg

---

9. 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 an IETF Internet Draft in which the initial chemical submission was made, incorporated suggestions received during the subsequent discussion period, and indicated scientific support for and uptake of a higher level document incorporating physical sciences[2-7]. this Model submission 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. additional thanks go to Mark Crispin (MRC@CAC.Washington.EDU) for his comments on the previous version, and Cynthia Clark (cclark@ietf.org) for editing the submitted versions 🌷