(Registered 2014-04-08, last updated 2014-04-08) Name : Leonard Daly & Don Brutzman Email : x3d-chair&web3d.org MIME media type name : Model MIME subtype name : Standards Tree - x3d+fastinfoset Required parameters : None Optional parameters : None Encoding considerations : binary Security considerations : * Complex media types: There are no X3D directives that access local resources except those related to the graphical display of content and the necessary system resources to make that happen. The X3D specification does allow for scripts to execute a variety of actions including changing the URL and accessing local resources. Any implementations that execute scripts MUST give consideration to their application's threat models and those of the individual features they implement; in particular, they MUST ensure that untrusted content is not executed in an unprotected environment. * Active content: We are interpreting active content to mean any and all content that is not static and unchanging while the designated URL is displayed. The intent of X3D is to provide active content to the user. This requires system resources in the form of memory, CPU processing, and graphics processing. Users of X3D desire active and are aware of the system demands. * Release of information: The X3D specification does not require any information be sent from the user's computer. A particular implementation may request information and distribute it. It is up to the implementer and user to negotiate the terms of service for that particular application. * Decompression issues: Several activities can occur when loading an X3D scene that have security implications. - X3D files can embed url links for loading other resources such as images, scripts, movies, audio files and other X3D scenes. - Embedded or linked scripts can be in Javascript, Java or (optionally) other languages. - Compressed binary scenes can contain two types of decompression: information-based (.gzip, Fast Infoset) and geometric-based (produces polygonal structures) which can be computationally expensive. - Recursive techniques are not typically allowed in 3D scene constructs. - Regular user-agent precautions used by Web browsers for HTML content should also apply. - It is possible to construct compressed input that expands to many times the original size. * External security considerations: There is nothing in the X3D specification that requires or prevents security assurances. A particular implementation may request information and distribute it. It is up to the implementer and user to negotiate the terms of service for that particular application. Scripting is defined as being available for the specification. Two scripting languages are defined: ECMAScript and Java. Each scripting language is controlled by its local security model. As the content may run in many different situations, the X3D specification does not impose specific security policies. For example, some standalone applications will want to directly interact with the local file system, network or database, while others that run in a web browser would use the web-browser's security model. X3D Graphics scenes can utilize the World Wide Web Consortium (W3C) Security Recommendations for XML Signature and XML Encryption, in either the .x3d (plain text) and .x3db (compressed binary) encodings. * Basic examples demonstrating use of the current W3C Recommendations for XML Signature and XML Encryption are maintained online at - http://www.web3d.org/x3d/content/examples/Basic/Security - http://www.web3d.org/x3d/content/examples/Basic/Security/X3dSecurityReadMe.html X3D security considerations are a close match to HTML. JavaScript or Java scripts may be linked internal to an X3D scene, or external to an X3D scene by an encapsulating HTML browser. Relevant informational review references follow. * HTML Mime Type Security Considerations - Excerpt: In addition, the introduction of scripting languages and interactive capabilities in HTML 4.0 introduced a number of security risks associated with the automatic execution of programs written by the sender but interpreted by the recipient. User agents executing such scripts or programs must be extremely careful to insure that untrusted software is executed in a protected environment. * HTML4 Recommendation, B.10 Notes on security - Excerpt: Anchors, embedded images, and all other elements that contain URIs as parameters may cause the URI to be dereferenced in response to user input. In this case, the security issues of [RFC1738], section 6, should be considered. The widely deployed methods for submitting form requests -- HTTP and SMTP -- provide little assurance of confidentiality. Information providers who request sensitive information via forms -- especially with the INPUT element, type="password" -- should be aware and make their users aware of the lack of confidentiality. * HTML5 security references - Details regarding specific HTML5 elements seem to be not applicable to X3D mime types Interoperability considerations : The definition of the file format is maintained by the Web3d Consortium and published through the ISO process. Several revisions of the specification have been made and it continues to be made. All revisions use the same MIME type definitions, and are backwards compatible internally and structurally. In addition, each of the file format encodings may be losslessly transformed between each other. There are no known interoperability issues. There are existing applications that run on PC, Macintosh, and Unix/Linux systems that work with the file format. The Web3D Consortium makes an effort to keep the file format interoperable across all platforms. Published specification : All revisions of the X3D specification is maintained online at http://www.web3d.org/realtime-3d/specification/all The most recent specification is available from the ISO website (for a fee) or from Web3D Consortium (without charge) ISO/IEC 19776-3:2007 - Compressed Binary Encoding (http://www.web3d.org/files/specifications/19776-3/V3.3/index.html) Applications which use this media : The applications that use (or would use) the media type model/x3d+fastinfoset are those that display, create, edit, import, or export 3D model content using the X3D standard. A short list of the applications include: Blender (Open source, runs on Windows, Macintosh, Linux) BS Contact (from Bitmanagement, runs on Windows, Macintosh, Linux) FreeWRL (Open source, runs on Windows, Macintosh, Linux) Instant Reality (Fraunhofer, runs on Windows, Macintosh, Linux) Octaga VS Player (from Octaga VS, runs on Windows) X3D-Edit and X3D Validator (from Naval Postgraduate School, Java based) X3DOM (Open source, runs on Windows, Macintosh, Linux, iPad) Xj3D (Open source from Web3D Consortium, Java based) See X3D Resources for a comprehensive list of supporting applications Fragment identifier considerations : No fragment identifier syntax is defined or planned for this media type. There is no guarantee that a partial document can be parsed if some fragments are missing. Restrictions on usage : None Provisional registration? (standards tree only) : No Additional information : 1. Deprecated alias names for this type : N/A 2. Magic number(s) : None 3. File extension(s) : x3db 4. Macintosh file type code : None 5. Object Identifiers: None The X3D standard is a continuation of the VRML standard that is defined in RFC2077. As part of this work, several large modifications were made to the file format and specification. The basic premise for the specification continues the VRML design rational. The MIME types and file extensions were changed to indicate this modified standard. Content Sub-types Each content type may have an additional Content-Encoding to indicate whether the content has been compressed using GZIP in addition to the basic textual encoding. This is also indicated by modifying each file extension with the character "z". For example, the compressed binary-encoded file format would use the extension ".x3db", and if compressed using GZIP uses the extension ".x3dbz" Person to contact for further information : 1. Name : X3D Working Group Chairs (Leonard Daly & Don Brutzman) 2. Email : x3d-chair&web3d.org Intended usage : Common N/A Author/Change controller : Web3D Consortium