idnits 2.17.1 draft-nelson-model-mail-ext-04.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-24) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 59 lines 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 (June 1996) is 10175 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 445 looks like a reference -- Missing reference section? '11' on line 498 looks like a reference -- Missing reference section? '14' on line 509 looks like a reference -- Missing reference section? '8' on line 485 looks like a reference -- Missing reference section? '9' on line 489 looks like a reference -- Missing reference section? '10' on line 493 looks like a reference -- Missing reference section? '2' on line 450 looks like a reference -- Missing reference section? '3' on line 457 looks like a reference -- Missing reference section? '4' on line 462 looks like a reference -- Missing reference section? '5' on line 466 looks like a reference -- Missing reference section? '6' on line 477 looks like a reference -- Missing reference section? '7' on line 480 looks like a reference -- Missing reference section? '12' on line 501 looks like a reference -- Missing reference section? '13' on line 505 looks like a reference -- Missing reference section? '2-7' on line 557 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 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 June 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 Table of Contents: 54 1. Overview 55 2. Definition 56 3. Consultation Mechanisms 57 4. Encoding and Transport 58 5. Security Considerations Section 59 6. Authors' Addresses 60 7. Expected subtypes 61 8. Appendix 62 9. Acknowledgements 64 1. Overview 66 This document will outline what a model is, show examples of models, 67 and discuss the benifits of grouping models together. This document 68 will not directly deal with the intended subtypes since those will be 69 covered by their seperate registrations. Some immediately expected 70 subtypes are listed in section 7. 72 This document is a discussion document for an agreed definition, 73 intended eventually to form a standard accepted extension to RFC 1521. 74 We are also targeting developers of input/output filters, viewer 75 software and hardware, those involved in MIME transport, and decoders. 77 2. Definition of a model 79 A model primary MIME type is an electronically exchangable behavioral 80 or physical representation within a given domain. Each subtype in 81 the model structure has unique features, just as does each subtype 82 in the other primary types. The important fact is that these 83 various subtypes can be converted between each other with less loss 84 of information then to that of other primary types. This fact groups 85 these subtypes together into the model primary type. All of the 86 expected subtypes have several features in common and that are 87 unique to this primary type. 89 To loosely summarize: models are multidimensional structures 90 composed of one or more objects. If there are multiple objects 91 then one object defines the arrangement/setting/relationship 92 of the others. These objects all have calibrated coordinate 93 systems but these systems need not be in the same units nor 94 need they have the same dimensionality. In detail: 96 1. have 3 or more dimensions which are bases of the system and 97 form an orthogonal system (any orthogonal system is sufficient). 99 This system is specifically defined in terms of an orthogonal 100 set of basis functions [for a subspace of the L^2 function space] 101 over a coordinate system of dimension 3 or more. Note that this 102 does not preclude regular skewed systems, elliptical coordinates, 103 different vector spaces, etc. 105 2. contain a structural relationship between model elements. 107 3. have scaling or calibration factors which are related to physical 108 units (force, momentum, time, velocity, acceleration, size, etc.). 109 Thus, an IGES file will specify a building of non-arbitrary size, 110 computational meshes and VRML models will have real spatial/ 111 temporal units. This allows for differing elements to be combined 112 non-arbitrarily. 114 4. Models can be single objects or composed of a collection of 115 objects. These normally independent objects are arranged 116 in a master/slave scenario so that one object acts as the 117 reference, or primary object, which defines how the other 118 objects interrelate and behave. This allows for the creation 119 of mathematical, physical, economic, behaviorial, etc. models 120 which typically are composed of different elements. The key is 121 in the description: these types describe how something 122 ``behaves''; contrasted to typical data types which describe 123 how something ``is''. 125 The inclusion of this "collective" system works similar to the 126 Email system's multipart/related type which defines the actions 127 of the individual parts. Further specification of the model/* 128 subtypes utilizing these properties is left to the subtype 129 authors. 131 With these assumptions: 133 a. the default dimensionality will be spatial and temporal (but 134 any are allowed). 136 b. it is presumed that models will contain underlying structure 137 which may or may not be immediately available to the 138 user. (fluid dynamics vector fields, electromagnetic 139 propagation, interrelated IGES dimensional specifiers, VRML 140 materials and operators, etc.) 142 c. it is assumed that basis set conversion between model domains 143 is lossless. The interpretation of the data may change but 144 the specification will not. i.e. convert the model of the 145 U.S.A. Gross Domestic Product into a VRML model and navigate 146 it to explore the variances and interrelationships. The model 147 has many dimensions but also ``passages'' and ``corridors'' 148 linking different parts of it. A similar situation is true 149 for meshes and CAD files. The key is identifying the basis set 150 conversion which makes sense. 152 d. models are grouped to assure LESS loss of information between 153 the model subtypes than to subtypes of other primary 154 types. (i.e. converting a chemical model into an image is 155 more lossy than concerting it into a VRML model). 157 Items c and d above define the grouping for model similar to the 158 way that ``images'' and ``videos'' are grouped together; to 159 assure less loss of information. Obviously converting from a GIF 160 image to a JPEG image looses less information than converting from 161 a GIF image to an AU audio file. 163 3. Consultation Mechanisms. 165 Before proposing a subtype for the model/* primary type, it is 166 suggested that the subtype author examine the definition (above) 167 of what a model/* is and the listing (below) of what a model/* is 168 not. Additional consultations with the authors of the existing 169 model/* subtypes is also suggested. 171 Copies of Internet drafts and RFCs are available on: 173 ftp://ftp.isi.edu/in-notes/ 175 Similarly, the VRML discussion list has been archived as: 177 http://vrml.wired.com/arch/ 179 and discussions on the comp.mail.mime group may be of interest. 180 Discussion digests for the existing model/* subtypes may be 181 referenced in the respective documents. 183 The mesh community presently has numerous different mesh 184 geometries as part of different packages. Freely available 185 libraries need to be advertised more than they have been in the 186 past to spur the development of interoperable packages. It is 187 hoped that by following the example of the VRML community and 188 creating a freely available comprehensive library of input/output 189 functions for meshes[11] that this problem will be alleviated for 190 the mesh community. A freely available mesh viewer conforming to 191 these standards is available now for various platforms. 192 Consulations with the authors of the mesh system, 194 http://www-dsed.llnl.gov/documents/test/mesh.html 196 will be benificial. 198 The IGES community has a suite of tests and conformance utilities 199 to gauge the conformance to specifications and software authors 200 are encouraged to seek those out from NIST[14]. 202 4. Encoding and Transport 204 a. A parameter which makes sense for all subtypes of model is the 205 initial viewing condition, consisting of the view position (a 206 3D point), the view vector, and the up vector. This parameter 207 is optional. Some subtypes will contain one or more viewing 208 conditions as part of there internal data. If present, this 209 parameter over-rides any internal viewing condition. Note 210 that these parameters are not specific to visualizations on 211 computer screens but also the default fabrication orientation 212 on milling machines. 214 b. Unrecognized subtypes of model should at a minimum be treated 215 as "application/octet-stream". Implementations may optionally 216 elect to pass subtypes of model that they do not specifically 217 recognize to a robust general-purpose model viewing 218 application, if such an application is available. 220 c. Different subtypes of model may be encoded as textual 221 representations or as binary data. Unless noted in the 222 subtype registration, subtypes of model should be assumed to 223 contain binary data, implying a content encoding of base64 for 224 email and binary transfer for ftp and http. 226 d. The formal syntax for the subtypes of the model primary type 227 should look like this: 229 MIME type name: model 230 MIME subtype name: xxxxxxxx 231 Required parameters: none 232 Optional parameters: dimensionality, static/dynamic, def. view 233 Encoding considerations: may be encoded 234 Security considerations: see section 5 below 235 Published specification: see Appendix B for references 236 Person and email address to contact for further information: 237 S. D. Nelson 239 5. Security Considerations Section 241 Note that the data files are ``read-only'' and do not contain file 242 system modifiers or batch/macro commands. The transported data is 243 not self-modifying but may contain interrelationships. The data 244 files may however contain a ``default view'' which is added by the 245 author at file creation time. This ``default view'' may 246 manipulate viewer variables, default look angle, lighting, 247 visualization options, etc. This visualization may also involve 248 the computation of variables or values for display based on the 249 given raw data. For motorized equipment, this may change the 250 position from the hardware's rest state to the object's starting 251 orientation. 253 The internal structure of the data files may direct agents to 254 access additional data from the network (i.e. inclusions); the 255 security limits of whom are not pre-supposed. Actions based on 256 these inclusions are left to the security definitions of the 257 inclusions. Further comments about the security considerations 258 for the subtypes will be contained in each subtype's registration. 260 6. Authors' Addresses. 262 S. D. Nelson, Lawrence Livermore National Laboratory, 263 7000 East Ave., L-153, Livermore CA 94550, USA. 264 E-Mail: nelson18@llnl.gov 266 C. Parks, National Institute of Standards & Technology 267 Bldg 220, Room B-344, Gaithersburg, MD 20899, USA. 268 E-Mail: parks@eeel.nist.gov 270 Mitra, WorldMaker, 271 1056 Noe, San Francisco, CA 94114 272 E-Mail: mitra@earth.path.net 274 7. Expected subtypes 276 Table 1 lists some of the expected model sub-type names. Suggested 277 3 letter extensions are also provided for DOS compatibility but their 278 need is hopefully diminished by the use of more robust operating 279 systems on PC platforms. The ``silo'' extension is provided for 280 backwards compatibility. Mesh has an extensive list of hints since the 281 present variability is so great. In the future, the need for 282 these hints will diminish since the files are self describing. 283 This document is not registering these subtypes. They will be 284 handled under separate documents. 286 Table 1. 288 Primary/sub-type Suggested extension(s) Reference 290 model/iges igs,iges [8] 291 model/vrml wrl [9] 292 model/mesh msh, mesh, silo [10] 294 It is expected that model/mesh will also make use of a number 295 of parameters which will help the end user determine the data 296 type without examinine the data. However, note that mesh files 297 are self-describing. 299 regular+static, unstructed+static, unstructured+dynamic, 300 conformal+static, conformal+dynamic, isoparametric+static, 301 isoparametric+dynamic 303 The sub-types listed above are some of the anticipated types that are 304 already in use. Notice that the IGES type is already registered 305 as "application/iges" and that RFC states that a more appropriate 306 type is desired. Note that the author of "application/iges" is 307 one of the authors of this "model" submission and application/iges 308 will be re-registered as model/iges at the appropriate time. 310 The VRML type is gaining wide acceptance and has numerous parallel 311 development efforts for different platforms. These efforts are 312 fueled by the release of the QvLib library for reading VRML files; 313 without which the VRML effort would be less further along. This 314 has allowed for a consistent data type and has by defacto 315 established a set of standards. Further VRML efforts include 316 interfaces to other kinds of hardware (beyond just visual 317 displays) and it is proposed by those involved in the VRML effort 318 to encompass more of the five senses. Unlike other kinds of 319 "reality modeling" schemes, VRML is not proprietary to any one 320 vendor and should experience similar growth as do other open 321 standards. 323 The mesh type is an offshoot of existing computational meshing 324 efforts and, like VRML, builds on a freely available library set. 325 Also like VRML, there are other proprietary meshing systems but 326 there are converters which will convert from those closed systems 327 to the mesh type. Meshes in general have an association feature 328 so that the connectivity between nodes is maintained. It should be 329 noted that most modern meshes are derived from CAD solids files. 331 8. Appendices 333 8.1 Appendix A -- extraneous details about expected subtypes 335 VRML Data Types 337 The 3D modeling and CAD communities use a number of file 338 formats to represent 3D models, these formats are widely used 339 to exchange information, and full, or lossy, converters 340 between the formats exist both independently and integrated 341 into widely used applications. The VRML format is rapidly 342 becoming a standard for the display of 3D information on the 343 WWW. 345 Mesh Data Types 347 For many decades, finite element and finite difference time domain 348 codes have generated mesh structures which attempt to use the 349 physical geometry of the structures in connection with various 350 physics packages to generate real world simulations of events 351 including electromagnetic wave propagation, fluid dynamics, motor 352 design, etc. The resulting output data is then post processed to 353 examine the results in a variety of forms. This proposed mesh 354 subtype will include both geometry and scalar/vector/tensor 355 results data. An important point to note is that many modern 356 meshes are generated from solids constructed using CAD packages. 358 Motivation for mesh grew out of discussions with other 359 communities about their design requirements. Many CAD or scene 360 descriptions are composed of a small number of complex objects 361 while computational meshes are composed of large numbers of 362 simple objects. A 1,000,000 element 3D mesh is small. A 363 100,000,000 element 3D structured mesh is large. Each object can 364 also have an arbitrary amount of associated data and the mesh 365 connectivity information is important in optimizing usage of the 366 mesh. Also, the mesh itself is usually uninteresting but 367 postprocessing packages may act on the underlying data or a 368 computational engine may process the data as input. 370 Meshes differ principally from other kinds of scenes in that 371 meshes are composed of a large number of simple objects which may 372 contain arbitrary non-spatial parameters, not all of whom need be 373 visible, and who have an implicit connectivity and neighbor list. 374 This latter point is the key feature of a mesh. It should be 375 noted that most meshes are generated from CAD files however. The 376 mesh type has association functions because the underlying 377 physics was used to calculate the interaction (if you crash a car 378 into a telephone pole, you get a crumpled car and a bent pole). 379 Most interesting computational meshes are 4D with additional 380 multidimensional results components. 382 IGES CAD Data Types 384 (The following text, reproduced for reference purposes only, is from 385 ``U.S. Product Data Association and IGES/PDES Organization Reference 386 Manual,'' June 1995; by permission.) 388 IGES, the Initial Graphics Exchange Specification, defines a 389 neutral data format that allows for the digital exchange of 390 information among computer-aided design (CAD) systems. 392 CAD systems are in use today in increasing numbers for 393 applications in all phases of the design, analysis, and 394 manufacture and testing of products. Since the designer may use 395 one supplier's system while the contractor and subcontractor may 396 use other systems, there is a need to be able to exchange data 397 digitally among all CAD systems. 399 The databases of CAD systems from different vendors often 400 represent the same CAD constructs differently. A circular arc on 401 one system may be defined by a center point, its starting point 402 and end point, while on another it is defined by its center, its 403 diameter starting and ending angle. IGES enables the exchange of 404 such data by providing, in the public domain, a neutral definition 405 and format for the exchange of such data. 407 Using IGES, the user can exchange product data models in the form 408 of wireframe, surface, or solid representations as well as surface 409 representations. Translators convert a vendor's proprietary 410 internal database format into the neutral IGES format and from the 411 IGES format into another vendor's internal database. The 412 translators, called pre- and post-processors, are usually 413 available from vendors as part of their product lines. 415 Applications supported by IGES include traditional engineering 416 drawings as well as models for analysis and/or various 417 manufacturing functions. In addition to the general specification, 418 IGES also includes application protocols in which the standard is 419 interpreted to meet discipline specific requirements. 421 IGES technology assumes that a person is available on the 422 receiving end to interpret the meaning of the product model 423 data. For instance, a person is needed to determine how many holes 424 are in the part because the hole itself is not defined. It is 425 represented in IGES by its component geometry and therefore, is 426 indistinguishable from the circular edges of a rod. 428 The IGES format has been registered with the Internet Assigned 429 Numbers Authority (IANA) as a Multipurpose Internet Mail Extension 430 (MIME) type "application/iges". The use of the message 431 type/subtype in Internet messages facilitates the uniform 432 recognition of an IGES file for routing to a viewer or translator. 434 Version 1.0 of the specification was adopted as an American 435 National Standards (ANS Y14.26M-1981) in November of 436 1981. Versions 3.0 and 4.0 of the specification have subsequently 437 been approved by ANSI. The current version of IGES 5.2 was 438 approved by ANSI under the new guidelines of the U.S. Product Data 439 Association. Under these guidelines, the IGES/PDES Organization 440 (IPO) became the accredited standards body for product data 441 exchange standards. This latest standard is USPRO/IPO-100-1993. 443 8.2 Appendix B -- References and Citations 445 [1] N. Borenstein, and N. Freed, "MIME (Multipurpose Internet Mail 446 Extensions) Part One: Mechanisms for Specifying and Describing the 447 Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, 448 September 1993. 450 [2] Fitzgerald P., "Molecules-R-Us Interface to the Brookhaven 451 Data Base", Computational Molecular Biology Section, National 452 Institutes of Health, USA; see http://www.nih.gov/htbin/pdb for 453 further details; Peitsch M.C, Wells T.N.C., Stampf D.R., Sussman 454 S. J., "The Swiss-3D Image Collection And PDP-Browser On The 455 Worldwide Web", Trends In Biochemical Sciences, 1995, 20, 82. 457 [3] "Proceedings of the First Electronic Computational Chemistry 458 Conference", Eds. Bachrach, S. M., Boyd D. B., Gray S. K, Hase W., 459 Rzepa H.S, ARInternet: Landover, Nov. 7- Dec. 2, 1994, in press; 460 Bachrach S. M, J. Chem. Inf. Comp. Sci., 1995, in press. 462 [4] Richardson D.C., and Richardson J.S., Protein Science, 1992, 463 1, 3; D. C. Richardson D. C., and Richardson J.S., Trends in 464 Biochem. Sci.,1994, 19, 135. 466 [5] Rzepa H. S., Whitaker B. J., and Winter M. J., "Chemical 467 Applications of the World-Wide-Web", J. Chem. Soc., Chem. Commun., 468 1994, 1907; Casher O., Chandramohan G., Hargreaves M., Murray-Rust 469 P., Sayle R., Rzepa H.S., and Whitaker B. J., "Hyperactive 470 Molecules and the World-Wide-Web Information System", 471 J. Chem. Soc., Perkin Trans 2, 1995, 7; Baggott J., "Biochemistry 472 On The Web", Chemical & Engineering News, 1995, 73, 36; Schwartz 473 A.T, Bunce D.M, Silberman R.G, Stanitski C.L, Stratton W.J, Zipp 474 A.P, "Chemistry In Context - Weaving The Web", Journal Of Chemical 475 Education, 1994, 71, 1041. 477 [6] Rzepa H.S., "WWW94 Chemistry Workshop", Computer Networks and 478 ISDN Systems, 1994, 27, 317 and 328. 480 [7] S.D. Nelson, "Email MIME test page", Lawrence Livermore 481 National Laboratory, 1994. See 482 http://www-dsed.llnl.gov/documents/WWWtest.html and 483 http://www-dsed.llnl.gov/documents/tests/email.html 485 [8] C. Parks, "Registration of new Media Type application/iges", 486 ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ 487 application/iges, 1995. 489 [9] G. Bell, A. Parisi, M. Pesce, "The Virtual Reality Modeling 490 Language", 491 http://sdsc.edu/SDSC/Partners/vrml/Archives/vrml10-3.html, 1995. 493 [10] S.D. Nelson, "Registration of new Media Type model/mesh", 494 (will be) 495 ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/model/ 496 mesh, 1995. 498 [11] "SILO User's Guide", Lawrence Livermore National Laboratory, 499 University of California, UCRL-MA-118751, March 7, 1995, 501 [12] E. Brugger, "Mesh-TV: a graphical analysis tool", Lawrence 502 Livermore National Laboratory, University of California, 503 UCRL-TB-115079-8, http://www.llnl.gov/liv_comp/meshtv/mesh.html 505 [13] S. Brown, "Portable Application Code Toolkit (PACT)", the 506 printed documentation is accessible from the PACT Home Page 507 http://www.llnl.gov/def_sci/pact/pact_homepage.html 509 [14] L. Rosenthal, ``Initial Graphics Exchange Specification 510 (IGES) Test Service'', 511 http://speckle.ncsl.nist.gov/~jacki/igests.htm 513 8.3 Appendix C -- hardware 515 Numerous kinds of hardware already exist which can process some 516 of the expected model data types and are listed here for illustration 517 purposes only: 519 stereo glasses, 3D lithography machines, automated manufacturing 520 systems, data gloves (with feedback), milling machines, 521 aromascopes, treadmills. 523 8.4 Appendix D -- Examples 525 This section contains a collection of various pointers to 526 examples of what the model type encompasses: 528 Example mesh model objects can be found on this mesh page: 529 http://www-dsed.llnl.gov/documents/tests/mesh.html 531 Various IGES compliant test objects: 532 http://www.eeel.nist.gov/iges/specfigures/index.html 534 VRML Test Suite: 535 http://www.chaco.com/vrml/test/ 537 An image of a model of a shipping cage crashing into the ground: 538 http://www.llnl.gov/liv_comp/meiko/apps/dyna3d/cagefig2.gif 540 An image of a 100,000,000 zone mesh: 541 http://www.llnl.gov/liv_comp/meiko/apps/hardin/PMESH.gif 543 A video of a seismic wave propagation through a computational mesh: 544 http://www.llnl.gov/liv_comp/meiko/apps/larsen/movie.mpg 546 9. Acknowledgements 548 Thanks go to Henry Rzepa (h.rzepa@ic.ac.uk), Peter Murray-Rust 549 (pmr1716@ggr.co.uk), Benjamin Whitaker 550 (B.J.Whitaker@chemistry.leeds.ac.uk), Bill Ross 551 (ross@cgl.ucsf.EDU), and others in the chemical community on which 552 the initial draft of this document is based. That document 553 updated IETF Internet Draft, draft-rzepa-chemical-mime-type-01.txt 554 in which the initial chemical submission was made, incorporated 555 suggestions received during the subsequent discussion period, and 556 indicated scientific support for and uptake of a higher level 557 document incorporating physical sciences[2-7]. This Model 558 submission benefited greatly from the previous groundwork laid, and 559 the continued interest by, those communities. 561 The authors would additionally like to thank Keith Moore 562 (moore@cs.utk.edu), lilley (lilley@afs.mcc.ac.uk), Wilson Ross 563 (ross@cgl.ucsf.EDU), hansen (hansen@pegasus.att.com), Alfred 564 Gilman (asg@severn.wash.inmet.com), and Jan Hardenbergh 565 (jch@nell.oki.com) without which this document would not have been 566 possible. Additional thanks go to Mark Crispin 567 (MRC@CAC.Washington.EDU) for his comments on the previous version and 568 Cynthia Clark (cclark@CNRI.Reston.VA.US) for editing the submitted 569 versions.