The Model Primary Content Type for Multipurpose Internet Mail Extensions
updated by
- rfc-9141 — Updating References to the IETF FTP Service
Extracted elements (18)
Basis set conversion between model domains is assumed to be lossless in terms of specification (though interpretation may change). This property—that inter-subtype conversion preserves more information than conversion to other primary types—is the defining criterion for grouping subtypes under 'model'.
The default dimensionality for model/* is spatial and temporal, though any orthogonal coordinate system is allowed. Models are presumed to contain underlying structure (e.g., fluid dynamics fields, IGES dimensional specifiers) that may not be immediately visible to the user.
The 'model' primary type is justified because various model subtypes (VRML, mesh, IGES) can be converted between each other with less loss of information than to subtypes of other primary types. This is analogous to how images and videos are grouped together to minimize conversion loss.
The optional parameter list (dimension, state) is provided for illustration only and does not limit parameters defined by individual subtypes. Each subtype registration may define additional parameters as needed.
IGES was previously registered as 'application/iges'. The author of that registration is also an author of this document, and application/iges is to be re-registered as model/iges at the appropriate time.
The VRML community's release of the freely available QvLib library is cited as a key enabler of interoperability; the mesh community is similarly encouraged to advertise freely available mesh I/O libraries to spur development of interoperable packages.
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.
Unrecognized subtypes of model MUST at a minimum be treated as 'application/octet-stream'. Implementations may optionally pass unrecognized model subtypes to a general-purpose model viewer if one is available.
A model/* MIME type is defined as a multidimensional structure with 3 or more orthogonal dimensions, structural relationships between elements, and calibrated coordinate systems related to physical units. Models describe how something 'behaves' rather than how something 'is'.
Models may be composed of multiple objects in a master/slave arrangement where one primary object defines how the others interrelate and behave, analogous to the multipart/related MIME type for email.
The 'dimension' optional parameter is a string indicating the number of dimensions of the model, used as a hint for selecting applicable viewer programs.
The formal content-type registration template for model/* subtypes requires: media type name 'model', a subtype name, no required parameters, and optional parameters 'dimensionality' and 'state'. Base64 encoding is recommended for MIME email transport.
The model/mesh subtype is expected to use parameters describing mesh topology and dynamism, including: regular+static, unstructured+static, unstructured+dynamic, conformal+static, conformal+dynamic, isoparametric+static, and isoparametric+dynamic.
The 'state' optional parameter is either 'static' or 'dynamic'. In 'static', the observer may move (translations, rotations, zooms) but data does not change; in 'dynamic', the data itself is manipulated (skews, elongations, scales). Time evolution is a static operation; object deformation is dynamic.
Three immediately anticipated subtypes are listed: model/iges (extensions: igs, iges), model/vrml (extension: wrl), and model/mesh (extensions: msh, mesh, silo). These are not registered by this document but by separate documents.
Establishes 'model' as a new primary MIME content type, alongside existing types such as text, image, audio, video, and application. Subtypes are to be registered separately.
Model data files are treated as read-only and do not contain file system modifiers or batch/macro commands. The transported data is not self-modifying, though files may contain a 'default view' set by the author that can manipulate viewer variables, lighting, and visualization options, including hardware position changes for motorized equipment.
The internal structure of model data files may direct agents to access additional data from the network (inclusions); the security limits of those inclusions are not predefined. Actions based on network inclusions are governed by the security definitions of the inclusions themselves. Subtype-specific security considerations are deferred to individual subtype registrations.