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