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

Document Type RFC - Proposed Standard (January 1997; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2077 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        S. Nelson
Request for Comments: 2077                                        LLNL
Category: Standards Track                                     C. Parks
                                                                  NIST
                                                                 Mitra
                                                            WorldMaker
                                                          January 1997

                   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.

Introduction

   The purpose of this memo is to propose an update to Internet RFC 2045
   to include a new primary content-type to be known as "model". RFC
   2045 [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.

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

Nelson, et. al.             Standards Track                     [Page 1]
RFC 2077                Model Primary MIME Types            January 1997

1. Overview

   This document will outline what a model is, show examples of models,
   and discuss the benefits of grouping models together.  This document
   will not directly deal with the intended subtypes since those will be
   covered by their separate registrations.  Some immediately expected
   subtypes are listed in section 7.

   This document is a discussion document for an agreed definition,
   intended eventually to form a standard accepted extension to RFC
   2045.  We are also targeting developers of input/output filters,
   viewer software and hardware, those involved in 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.  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
   expected subtypes have several features in common and that are unique
   to this primary type.

   To loosely summarize: models are multidimensional structures composed
   of one or more objects.  If there are multiple objects then one
   object defines the arrangement/setting/relationship of the others.
   These objects all have calibrated coordinate systems but these
   systems need not be in the same units nor need they have the same
   dimensionality.  In detail:

   1. have 3 or more dimensions which are 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 preclude regular skewed systems, elliptical coordinates,
      different vector spaces, etc.

   2. contain a structural relationship between model elements.

   3. have scaling or calibration factors which are related 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/

Nelson, et. al.             Standards Track                     [Page 2]
Show full document text