idnits 2.17.1 draft-nelson-model-mail-ext-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1996) is 10297 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 450 looks like a reference -- Missing reference section? '11' on line 505 looks like a reference -- Missing reference section? '14' on line 518 looks like a reference -- Missing reference section? '8' on line 492 looks like a reference -- Missing reference section? '9' on line 496 looks like a reference -- Missing reference section? '10' on line 500 looks like a reference -- Missing reference section? '2' on line 455 looks like a reference -- Missing reference section? '3' on line 464 looks like a reference -- Missing reference section? '4' on line 469 looks like a reference -- Missing reference section? '5' on line 473 looks like a reference -- Missing reference section? '6' on line 484 looks like a reference -- Missing reference section? '7' on line 487 looks like a reference -- Missing reference section? '12' on line 508 looks like a reference -- Missing reference section? '13' on line 514 looks like a reference -- Missing reference section? '2-7' on line 568 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. D. Nelson 2 Internet Draft Lawrence Livermore National Laboratory 3 Livermore, CA 94550, USA. 4 C. Parks 5 National Institute of Standards and Technology 6 Gaithersburg, MD 20899, USA. 7 Mitra 8 WorldMaker 9 1056 Noe, San Francisco, CA 94114 10 February 1996 11 Expires in six months 13 The Model Primary Content Type for 14 Multipurpose Internet Mail Extensions 15 17 Status of this Memo 19 This document specifies an Internet standards track protocol for 20 the Internet community, and requests discussion and suggestions 21 for improvements. Please refer to the current edition of the 22 "Internet Official Protocol Standards" (STD 1) for the 23 standardization state and status of this protocol. Distribution 24 of this memo is unlimited. 26 The original version of this draft benefitted from discussions 27 between the authors and their respective communities. 29 Draft documents are valid for a maximum of six months and may be 30 updated, replaced, or obsoleted by other documents at any time. 31 It is inappropriate to use draft documents as reference material 32 or to cite them other than as ``work in progress.'' 34 To learn the current status of any Internet-Draft, please check 35 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 36 Shadow Directories on ds.internic.net (US East Coast), 37 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 38 munnari.oz.au (Pacific Rim). 40 Introduction 42 The purpose of this Internet Draft is to propose an update to 43 Internet RFC 1521 to include a new primary content-type to be 44 known as "model". RFC 1521[1] describes mechanisms for specifying 45 and describing the format of Internet Message Bodies via 46 content-type/subtype pairs. We believe that "model" defines a 47 fundamental type of content with unique presentational, hardware, 48 and processing aspects. Various subtypes of this primary type are 49 immediately anticipated but will be covered under separate 50 documents. 52 Internet-draft Model Primary MIME Type February 1996 54 Table of Contents: 56 1. Overview 57 2. Definition 58 3. Consultation Mechanisms 59 4. Encoding and Transport 60 5. Security Considerations Section 61 6. Authors' Addresses 62 7. Expected subtypes 63 8. Appendix 64 9. Acknowledgements 66 1. Overview 68 This document will outline what a model is, show examples of models, 69 and discuss the benifits of grouping models together. This document 70 will not directly deal with the intended subtypes since those will be 71 covered by their seperate registrations. Some immediately expected 72 subtypes are listed in section 7. 74 This document is a discussion document for an agreed definition, 75 intended eventually to form a standard accepted extension to RFC 1521. 76 We are also targeting developers of input/output filters, viewer 77 software and hardware, those involved in MIME transport, and decoders. 79 2. Definition of a model 81 Each subtype in the model structure has unique features, just as 82 does each subtype in the other primary types. The important fact is 83 that these various subtypes can be converted between each other with 84 less loss of information then to that of other primary types. This 85 fact groups these subtypes together into the model primary type. All 86 of the expected subtypes have several features in common and that are 87 unique to this primary type: 89 1. have 3 or more dimensions which are bases of the system and 90 form an orthogonal system (any orthogonal system is sufficient). 92 The basis functions need to form an orthogonal system, but the 93 coordinate system need not be orthogonal. This also allows for 94 regular skewed systems, elliptical coordinates, different vector 95 spaces, etc. 97 2. contains a structural relationship between model elements. 99 3. have calibration factors to physical units (force, momentum, 100 time, velocity, acceleration, size, etc.). Thus, an IGES file 101 will specify a building of non-arbitrary size, computational 102 meshes and VRML models will have real spatial/ temporal units. 103 This allows for differing elements to be combined 104 non-arbitrarily. 106 Internet-draft Model Primary MIME Type February 1996 108 4. Models can also be single descriptive objects or composed of a 109 collection of objects. These normally independent objects are 110 arranged in a master/slave scenario so that one object acts as 111 the reference which defines how the other objects interrelate 112 and behave. This allows for the creation of mathematical, 113 physical, economic, behaviorial, etc. models which typically are 114 composed of different elements. The key is in the description: 115 these types describe how something ``behaves''; contrasted to 116 typical data types which describe how something ``is''. 118 The inclusion of this "collective" system works similar to the 119 Email system's multipart/related type which defines the actions 120 of the individual parts. Further specification of the model/* 121 subtypes utilizing these properties is left to the subtype 122 authors. 124 With these assumptions: 126 a. the default dimensionality will be spatial and temporal (but 127 any are allowed). 129 b. it is presumed that models will contain underlying structure 130 which may or may not be immediately available to the 131 user. (fluid dynamics vector fields, electromagnetic 132 propagation, interrelated IGES dimensional specifiers, VRML 133 materials and operators, etc.) 135 c. it is assumed that basis set conversion between model domains 136 is lossless. The interpretation of the data may change but 137 the specification will not. i.e. convert the model of the 138 U.S.A. Gross Domestic Product into a VRML model and navigate 139 it to explore the variances and interrelationships. The model 140 has many dimensions but also ``passages'' and ``corridors'' 141 linking different parts of it. A similar situation is true 142 for meshes and CAD files. The key is identifying the basis set 143 conversion which makes sense. 145 d. models are grouped to assure LESS loss of information between 146 the model subtypes than to subtypes of other primary 147 types. (i.e. converting a chemical model into an image is 148 more lossy than concerting it into a VRML model). 150 Items c and d above define the grouping for model similar to the 151 way that ``images'' and ``videos'' are grouped together; to 152 assure less loss of information. Obviously converting from a GIF 153 image to a JPEG image looses less information than converting from 154 a GIF image to an AU audio file. 156 Internet-draft Model Primary MIME Type February 1996 158 3. Consultation Mechanisms. 160 Before proposing a subtype for the model/* primary type, it is 161 suggested that the subtype author examine the definition (above) 162 of what a model/* is and the listing (below) of what a model/* is 163 not. Additional consultations with the authors of the existing 164 model/* subtypes is also suggested. 166 Copies of Internet drafts and RFCs are available on: 168 ftp://ftp.isi.edu/in-notes/ 170 Similarly, the VRML discussion list has been archived as: 172 http://vrml.wired.com/arch/ 174 and discussions on the comp.mail.mime group may be of interest. 175 Discussion digests for the existing model/* subtypes may be 176 referenced in the respective documents. 178 The mesh community presently has numerous different mesh 179 geometries as part of different packages. Freely available 180 libraries need to be advertised more than they have been in the 181 past to spur the development of interoperable packages. It is 182 hoped that by following the example of the VRML community and 183 creating a freely available comprehensive library of input/output 184 functions for meshes[11] that this problem will be alleviated for 185 the mesh community. A freely available mesh viewer conforming to 186 these standards is available now for various platforms. 187 Consulations with the authors of the mesh system, 189 http://www-dsed.llnl.gov/documents/test/mesh.html 191 will be benificial. 193 The IGES community has a suite of tests and conformance utilities 194 to gauge the conformance to specifications and software authors 195 are encouraged to seek those out from NIST[14]. 197 4. Encoding and Transport 199 a. A parameter which makes sense for all subtypes of model is the 200 initial viewing condition, consisting of the view position (a 201 3D point), the view vector, and the up vector. This parameter 202 is optional. Some subtypes will contain one or more viewing 203 conditions as part of there internal data. If present, this 204 parameter over-rides any internal viewing condition. Note 205 that these parameters are not specific to visualizations on 206 computer screens but also the default fabrication orientation 207 on milling machines. 209 Internet-draft Model Primary MIME Type February 1996 211 b. Unrecognized subtypes of model should at a minimum be treated 212 as "application/octet-stream". Implementations may optionally 213 elect to pass subtypes of model that they do not specifically 214 recognize to a robust general-purpose model viewing 215 application, if such an application is available. 217 c. Different subtypes of model may be encoded as textual 218 representations or as binary data. Unless noted in the 219 subtype registration, subtypes of model should be assumed to 220 contain binary data, implying a content encoding of base64 for 221 email and binary transfer for ftp and http. 223 d. The formal syntax for the subtypes of the model primary type 224 should look like this: 226 MIME type name: model 227 MIME subtype name: xxxxxxxx 228 Required parameters: none 229 Optional parameters: dimensionality, static/dynamic, def. view 230 Encoding considerations: may be encoded 231 Security considerations: see section 5 below 232 Published specification: see Appendix B for references 233 Person and email address to contact for further information: 234 S. D. Nelson 236 5. Security Considerations Section 238 Note that the data files are ``read-only'' and do not contain file 239 system modifiers or batch/macro commands. The transported data is 240 not self-modifying but may contain interrelationships. The data 241 files may however contain a ``default view'' which is added by the 242 author at file creation time. This ``default view'' may 243 manipulate viewer variables, default look angle, lighting, 244 visualization options, etc. This visualization may also involve 245 the computation of variables or values for display based on the 246 given raw data. For motorized equipment, this may change the 247 position from the hardware's rest state to the object's starting 248 orientation. 250 The internal structure of the data files may direct agents to 251 access additional data from the network (i.e. inclusions); the 252 security limits of whom are not pre-supposed. Actions based on 253 these inclusions are left to the security definitions of the 254 inclusions. Further comments about the security considerations 255 for the subtypes will be contained in each subtype's registration. 257 Internet-draft Model Primary MIME Type February 1996 259 6. Authors' Addresses. 261 S. D. Nelson, Lawrence Livermore National Laboratory, 262 7000 East Ave., L-153, Livermore CA 94550, USA. 263 E-Mail: nelson18@llnl.gov 265 C. Parks, National Institute of Standards & Technology 266 Bldg 220, Room B-344, Gaithersburg, MD 20899, USA. 267 E-Mail: parks@eeel.nist.gov 269 Mitra, WorldMaker, 270 1056 Noe, San Francisco, CA 94114 271 E-Mail: mitra@earth.path.net 273 7. Expected subtypes 275 Table 1 lists some of the expected model sub-type names. Suggested 276 3 letter extensions are also provided for DOS compatibility but their 277 need is hopefully diminished by the use of more robust operating 278 systems on PC platforms. The ``silo'' extension is provided for 279 backwards compatibility. Mesh has an extensive list of hints since the 280 present variability is so great. In the future, the need for 281 these hints will diminish since the files are self describing. 282 This document is not registering these subtypes. They will be 283 handled under separate documents. 285 Table 1. 287 Primary/sub-type Suggested extension(s) Reference 289 model/iges igs,iges [8] 290 model/vrml wrl [9] 291 model/mesh msh, mesh, silo [10] 293 It is expected that model/mesh will also make use of a number 294 of parameters which will help the end user determine the data 295 type without examinine the data. However, note that mesh files 296 are self-describing. 298 regular+static, unstructed+static, unstructured+dynamic, 299 conformal+static, conformal+dynamic, isoparametric+static, 300 isoparametric+dynamic 302 The sub-types listed above are some of the anticipated types that are 303 already in use. Notice that the IGES type is already registered 304 as "application/iges" and that RFC states that a more appropriate 305 type is desired. Note that the author of "application/iges" is 306 one of the authors of this "model" submission and application/iges 307 will be re-registered as model/iges at the appropriate time. 309 Internet-draft Model Primary MIME Type February 1996 311 The VRML type is gaining wide acceptance and has numerous parallel 312 development efforts for different platforms. These efforts are 313 fueled by the release of the QvLib library for reading VRML files; 314 without which the VRML effort would be less further along. This 315 has allowed for a consistent data type and has by defacto 316 established a set of standards. Further VRML efforts include 317 interfaces to other kinds of hardware (beyond just visual 318 displays) and it is proposed by those involved in the VRML effort 319 to encompass more of the five senses. Unlike other kinds of 320 "reality modeling" schemes, VRML is not proprietary to any one 321 vendor and should experience similar growth as do other open 322 standards. 324 The mesh type is an offshoot of existing computational meshing 325 efforts and, like VRML, builds on a freely available library set. 326 Also like VRML, there are other proprietary meshing systems but 327 there are converters which will convert from those closed systems 328 to the mesh type. Meshes in general have an association feature 329 so that the connectivity between nodes is maintained. It should be 330 noted that most modern meshes are derived from CAD solids files. 332 8. Appendices 334 8.1 Appendix A -- extraneous details about expected subtypes 336 VRML Data Types 338 The 3D modeling and CAD communities use a number of file 339 formats to represent 3D models, these formats are widely used 340 to exchange information, and full, or lossy, converters 341 between the formats exist both independently and integrated 342 into widely used applications. The VRML format is rapidly 343 becoming a standard for the display of 3D information on the 344 WWW. 346 Mesh Data Types 348 For many decades, finite element and finite difference time domain 349 codes have generated mesh structures which attempt to use the 350 physical geometry of the structures in connection with various 351 physics packages to generate real world simulations of events 352 including electromagnetic wave propagation, fluid dynamics, motor 353 design, etc. The resulting output data is then post processed to 354 examine the results in a variety of forms. This proposed mesh 355 subtype will include both geometry and scalar/vector/tensor 356 results data. An important point to note is that many modern 357 meshes are generated from solids constructed using CAD packages. 359 Internet-draft Model Primary MIME Type February 1996 361 Motivation for mesh grew out of discussions with other 362 communities about their design requirements. Many CAD or scene 363 descriptions are composed of a small number of complex objects 364 while computational meshes are composed of large numbers of 365 simple objects. A 1,000,000 element 3D mesh is small. A 366 100,000,000 element 3D structured mesh is large. Each object can 367 also have an arbitrary amount of associated data and the mesh 368 connectivity information is important in optimizing usage of the 369 mesh. Also, the mesh itself is usually uninteresting but 370 postprocessing packages may act on the underlying data or a 371 computational engine may process the data as input. 373 Meshes differ principally from other kinds of scenes in that 374 meshes are composed of a large number of simple objects which may 375 contain arbitrary non-spatial parameters, not all of whom need be 376 visible, and who have an implicit connectivity and neighbor list. 377 This latter point is the key feature of a mesh. It should be 378 noted that most meshes are generated from CAD files however. The 379 mesh type has association functions because the underlying 380 physics was used to calculate the interaction (if you crash a car 381 into a telephone pole, you get a crumpled car and a bent pole). 382 Most interesting computational meshes are 4D with additional 383 multidimensional results components. 385 IGES CAD Data Types 387 (The following text, reproduced for reference purposes only, is from 388 ``U.S. Product Data Association and IGES/PDES Organization Reference 389 Manual,'' June 1995; by permission.) 391 IGES, the Initial Graphics Exchange Specification, defines a 392 neutral data format that allows for the digital exchange of 393 information among computer-aided design (CAD) systems. 395 CAD systems are in use today in increasing numbers for 396 applications in all phases of the design, analysis, and 397 manufacture and testing of products. Since the designer may use 398 one supplier's system while the contractor and subcontractor may 399 use other systems, there is a need to be able to exchange data 400 digitally among all CAD systems. 402 The databases of CAD systems from different vendors often 403 represent the same CAD constructs differently. A circular arc on 404 one system may be defined by a center point, its starting point 405 and end point, while on another it is defined by its center, its 406 diameter starting and ending angle. IGES enables the exchange of 407 such data by providing, in the public domain, a neutral definition 408 and format for the exchange of such data. 410 Internet-draft Model Primary MIME Type February 1996 412 Using IGES, the user can exchange product data models in the form 413 of wireframe, surface, or solid representations as well as surface 414 representations. Translators convert a vendor's proprietary 415 internal database format into the neutral IGES format and from the 416 IGES format into another vendor's internal database. The 417 translators, called pre- and post-processors, are usually 418 available from vendors as part of their product lines. 420 Applications supported by IGES include traditional engineering 421 drawings as well as models for analysis and/or various 422 manufacturing functions. In addition to the general specification, 423 IGES also includes application protocols in which the standard is 424 interpreted to meet discipline specific requirements. 426 IGES technology assumes that a person is available on the 427 receiving end to interpret the meaning of the product model 428 data. For instance, a person is needed to determine how many holes 429 are in the part because the hole itself is not defined. It is 430 represented in IGES by its component geometry and therefore, is 431 indistinguishable from the circular edges of a rod. 433 The IGES format has been registered with the Internet Assigned 434 Numbers Authority (IANA) as a Multipurpose Internet Mail Extension 435 (MIME) type "application/iges". The use of the message 436 type/subtype in Internet messages facilitates the uniform 437 recognition of an IGES file for routing to a viewer or translator. 439 Version 1.0 of the specification was adopted as an American 440 National Standards (ANS Y14.26M-1981) in November of 441 1981. Versions 3.0 and 4.0 of the specification have subsequently 442 been approved by ANSI. The current version of IGES 5.2 was 443 approved by ANSI under the new guidelines of the U.S. Product Data 444 Association. Under these guidelines, the IGES/PDES Organization 445 (IPO) became the accredited standards body for product data 446 exchange standards. This latest standard is USPRO/IPO-100-1993. 448 8.2 Appendix B -- References and Citations 450 [1] N. Borenstein, and N. Freed, "MIME (Multipurpose Internet Mail 451 Extensions) Part One: Mechanisms for Specifying and Describing the 452 Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, 453 September 1993. 455 [2] Fitzgerald P., "Molecules-R-Us Interface to the Brookhaven 456 Data Base", Computational Molecular Biology Section, National 457 Institutes of Health, USA; see http://www.nih.gov/htbin/pdb for 458 further details; Peitsch M.C, Wells T.N.C., Stampf D.R., Sussman 459 S. J., "The Swiss-3D Image Collection And PDP-Browser On The 460 Worldwide Web", Trends In Biochemical Sciences, 1995, 20, 82. 462 Internet-draft Model Primary MIME Type February 1996 464 [3] "Proceedings of the First Electronic Computational Chemistry 465 Conference", Eds. Bachrach, S. M., Boyd D. B., Gray S. K, Hase W., 466 Rzepa H.S, ARInternet: Landover, Nov. 7- Dec. 2, 1994, in press; 467 Bachrach S. M, J. Chem. Inf. Comp. Sci., 1995, in press. 469 [4] Richardson D.C., and Richardson J.S., Protein Science, 1992, 470 1, 3; D. C. Richardson D. C., and Richardson J.S., Trends in 471 Biochem. Sci.,1994, 19, 135. 473 [5] Rzepa H. S., Whitaker B. J., and Winter M. J., "Chemical 474 Applications of the World-Wide-Web", J. Chem. Soc., Chem. Commun., 475 1994, 1907; Casher O., Chandramohan G., Hargreaves M., Murray-Rust 476 P., Sayle R., Rzepa H.S., and Whitaker B. J., "Hyperactive 477 Molecules and the World-Wide-Web Information System", 478 J. Chem. Soc., Perkin Trans 2, 1995, 7; Baggott J., "Biochemistry 479 On The Web", Chemical & Engineering News, 1995, 73, 36; Schwartz 480 A.T, Bunce D.M, Silberman R.G, Stanitski C.L, Stratton W.J, Zipp 481 A.P, "Chemistry In Context - Weaving The Web", Journal Of Chemical 482 Education, 1994, 71, 1041. 484 [6] Rzepa H.S., "WWW94 Chemistry Workshop", Computer Networks and 485 ISDN Systems, 1994, 27, 317 and 328. 487 [7] S.D. Nelson, "Email MIME test page", Lawrence Livermore 488 National Laboratory, 1994. See 489 http://www-dsed.llnl.gov/documents/WWWtest.html and 490 http://www-dsed.llnl.gov/documents/tests/email.html 492 [8] C. Parks, "Registration of new Media Type application/iges", 493 ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ 494 application/iges, 1995. 496 [9] G. Bell, A. Parisi, M. Pesce, "The Virtual Reality Modeling 497 Language", 498 http://sdsc.edu/SDSC/Partners/vrml/Archives/vrml10-3.html, 1995. 500 [10] S.D. Nelson, "Registration of new Media Type model/mesh", 501 (will be) 502 ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/model/ 503 mesh, 1995. 505 [11] "SILO User's Guide", Lawrence Livermore National Laboratory, 506 University of California, UCRL-MA-118751, March 7, 1995, 508 [12] E. Brugger, "Mesh-TV: a graphical analysis tool", Lawrence 509 Livermore National Laboratory, University of California, 510 UCRL-TB-115079-8, http://www.llnl.gov/liv_comp/meshtv/mesh.html 512 Internet-draft Model Primary MIME Type February 1996 514 [13] S. Brown, "Portable Application Code Toolkit (PACT)", the 515 printed documentation is accessible from the PACT Home Page 516 http://www.llnl.gov/def_sci/pact/pact_homepage.html 518 [14] L. Rosenthal, ``Initial Graphics Exchange Specification 519 (IGES) Test Service'', 520 http://speckle.ncsl.nist.gov/~jacki/igests.htm 522 8.3 Appendix C -- hardware 524 Numerous kinds of hardware already exist which can process some 525 of the expected model data types and are listed here for illustration 526 purposes only: 528 stereo glasses, 3D lithography machines, automated manufacturing 529 systems, data gloves (with feedback), milling machines, 530 aromascopes, treadmills. 532 8.4 Appendix D -- Examples 534 This section contains a collection of various pointers to 535 examples of what the model type encompasses: 537 Example mesh model objects can be found on this mesh page: 538 http://www-dsed.llnl.gov/documents/tests/mesh.html 540 Various IGES compliant test objects: 541 http://www.eeel.nist.gov/iges/specfigures/index.html 543 VRML Test Suite: 544 http://www.chaco.com/vrml/test/ 546 An image of a model of a shipping cage crashing into the ground: 547 http://www.llnl.gov/liv_comp/meiko/apps/dyna3d/cagefig2.gif 549 An image of a 100,000,000 zone mesh: 550 http://www.llnl.gov/liv_comp/meiko/apps/hardin/PMESH.gif 552 A video of a seismic wave propagation through a computational mesh: 553 http://www.llnl.gov/liv_comp/meiko/apps/larsen/movie.mpg 555 Internet-draft Model Primary MIME Type February 1996 557 9. Acknowledgements 559 Thanks go to Henry Rzepa (h.rzepa@ic.ac.uk), Peter Murray-Rust 560 (pmr1716@ggr.co.uk), Benjamin Whitaker 561 (B.J.Whitaker@chemistry.leeds.ac.uk), Bill Ross 562 (ross@cgl.ucsf.EDU), and others in the chemical community on which 563 the initial draft of this document is based. That document 564 updated IETF Internet Draft, draft-rzepa-chemical-mime-type-01.txt 565 in which the initial chemical submission was made, incorporated 566 suggestions received during the subsequent discussion period, and 567 indicated scientific support for and uptake of a higher level 568 document incorporating physical sciences[2-7]. This Model 569 submission benefited greatly from the previous groundwork laid, and 570 the continued interest by, those communities. 572 The authors would additionally like to thank Keith Moore 573 (moore@cs.utk.edu), lilley (lilley@afs.mcc.ac.uk), Wilson Ross 574 (ross@cgl.ucsf.EDU), hansen (hansen@pegasus.att.com), Alfred 575 Gilman (asg@severn.wash.inmet.com), and Jan Hardenbergh 576 (jch@nell.oki.com) without which this document would not have been 577 possible. Additional thanks go to Mark Crispin 578 (MRC@CAC.Washington.EDU) for his comments on the previous version and 579 Cynthia Clark (cclark@CNRI.Reston.VA.US) for editing the submitted 580 versions.