Difference between revisions of "X3D MIME-Type"

From Web3D.org
Jump to: navigation, search
(12. Other Information/GeneralComment:)
m (15. Other Information/General Comment)
 
(169 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Current work to gain final MIME-type approval ==
+
A MIME [http://en.wikipedia.org/wiki/Media_type Media Type] is a two-part identifier for file formats on the Internet.
 +
The X3D Working Group has provided formal submissions to the [http://www.iana.org Internet Assigned Names Authority (IANA)
 +
] to support X3D MIME Media Types. This work is now complete with all submitted types(.x3d .x3dv .x3db) approved.
 +
 
 +
__TOC__
 +
 
 +
== Future work for MIME-type approval ==
 +
 
 +
With additional effort, the X3D Working Group expects to submit MIME-type requests for
 +
* X3D JSON Encoding
 +
* X3D Efficient Binary Encoding (EBE)
 +
* Shape Resource Container (SRC) - possibly
 +
 
 +
== Completed work that gained final MIME-type approval ==
 +
 
 
In 1997 the Internet Engineering Task Force (IETF) approved [http://www.ietf.org/rfc/rfc2077.txt?number=2077 IETF RFC 2077] for the Model MIME type.
 
In 1997 the Internet Engineering Task Force (IETF) approved [http://www.ietf.org/rfc/rfc2077.txt?number=2077 IETF RFC 2077] for the Model MIME type.
 
This supports VRML and establishes a MIME basis for other 3D model formats.
 
This supports VRML and establishes a MIME basis for other 3D model formats.
However, the IETF has not yet approved X3D as an official MIME type, primarily due our incomplete prior efforts which did not submit a formal final application.
+
However, the IETF had not originally approved X3D as an official MIME type, primarily due our incomplete prior efforts which did not submit a formal final application.
 
This page is where we are building that formal application for official status of the X3D MIME-Type.
 
This page is where we are building that formal application for official status of the X3D MIME-Type.
  
 
The current round of work started in 2008 with an initial application submission late that year.  
 
The current round of work started in 2008 with an initial application submission late that year.  
Review comments were received from IETF MIME-Type task force, reconciled and incorporated back into the application in February 2009.
+
Review comments were received from IETF MIME-Type task force, reconciled and incorporated back into the application in February 2009.  
 
This effort was reported and collected as [http://www.ietf.org/mail-archive/web/ietf-types/current/msg00766.html Registration of media type model/x3d+XXX].  
 
This effort was reported and collected as [http://www.ietf.org/mail-archive/web/ietf-types/current/msg00766.html Registration of media type model/x3d+XXX].  
  
The updated document appears below. All edits need to be done in conformance with the current application standard. When completed, the application needs to be sent to 'ietf-types@iana.org' with the subject line "Registration of media type model/x3d+XXX" included.
+
The updated document appears below. All edits were accomplished in conformance with the current application standard. The completed application was sent to 'ietf-types@iana.org' with the subject line "Registration of media type model/x3d+XXX" included.
  
 
==== References ====
 
==== References ====
  
* [http://www.ietf.org/rfc/rfc2077.txt?number=2077 IETF RFC 2077, The Model Primary Content Type for Multipurpose Internet Mail Extensions]
+
* IANA [http://www.iana.org/cgi-bin/mediatypes.pl MIME Type Submission Form]
* [http://www.web3d.org/x3d/learn/mimetypes X3D MIME Types and File Extensions]
+
* IETF [http://tools.ietf.org/html/rfc2077 RFC 2077, The Model Primary Content Type for Multipurpose Internet Mail Extensions]
* 19776-1 X3D XML encoding, [http://www.web3d.org/files/specifications/19776-1/V3.2/Part01/concepts.html#FileExtensionAndMIMETypes 4.4.1 File extension and MIME types]
+
* IETF [http://tools.ietf.org/html/rfc3023 RFC 3023, XML Media Types] and especially [http://tools.ietf.org/html/rfc3023#appendix-A Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types?]
* 19776-2 ClassicVrml encoding, [http://www.web3d.org/files/specifications/19776-2/V3.2/Part02/concepts.html#ClassicVRMLEncodedX3DFilesAndWWW 4.4.1 File extension and MIME type]
+
* IETF [http://tools.ietf.org/html/rfc6838 RFC 6838, Media Type Specifications and Registration Procedures (Publication Requirements)] (obsoletes [http://tools.ietf.org/html/rfc4288 RFC 4288)]
* 19776-3: Compressed binary encoding, [http://www.web3d.org/files/specifications/19776-3/V3.2/Part03/concepts.html#FileExtensionsAndMIMETypes 4.5.2 File extensions and MIME types]
+
* ISO 19776-1 X3D XML encoding, [http://www.web3d.org/files/specifications/19776-1/V3.3/Part01/concepts.html#FileExtensionAndMIMETypes 4.4.1 File extension and MIME types]
* [http://www.iana.org/cgi-bin/mediatypes.pl MIME Type Submission Form]
+
* ISO 19776-2 ClassicVRML encoding, [http://www.web3d.org/files/specifications/19776-2/V3.3/Part02/concepts.html#ClassicVRMLEncodedX3DFilesAndWWW 4.4.1 File extension and MIME type]
 +
* ISO 19776-3 Compressed binary encoding, [http://www.web3d.org/files/specifications/19776-3/V3.3/Part03/concepts.html#FileExtensionsAndMIMETypes 4.5.2 File extensions and MIME types]
 +
* Web3D [http://www.web3d.org/x3d/learn/mimetypes X3D MIME Types and File Extensions]
  
==== Work list ====
+
==== Approval Complete ====
* Ensure that the application is fully complete
+
** Develop Section 5, Security Considerations
+
** "Encoding considerations" to update the binary encoding to current state
+
** Update all X3D specification references to the latest version and description
+
* Perform public review on x3d-public@web3d.org mailing list
+
* Gain approval of [http://www.web3d.org/realtime-3d/working-groups/x3d X3D Working Group] and concurrence of [http://www.web3d.org/realtime-3d/about/board Web3D Board of Directors]
+
  
==== Submission steps ====
+
All of the current X3D MIME media type submissions are complete, approved by the Internet Assigned Names Authority ([http://iana.org IANA]) and online:
 +
 
 +
* [http://www.iana.org/assignments/media-types/media-types.xhtml#model Model/Standards Tree] - [http://www.iana.org/assignments/media-types/model/x3d+xml x3d+xml]
 +
* [http://www.iana.org/assignments/media-types/media-types.xhtml#model Model/Standards Tree] - [http://www.iana.org/assignments/media-types/model/x3d-vrml x3d-vrml]
 +
* [http://www.iana.org/assignments/media-types/media-types.xhtml#model Model/Standards Tree] - [http://www.iana.org/assignments/media-types/model/x3d+fastinfoset x3d+fastinfoset]
 +
 
 +
NOTE: use correct combinations of plus '''+''' and minus '''-''' signs as shown above
 +
 
 +
==== TODO: Deployment Action Items ====
 +
 
 +
* Configure http servers and document the configuration procedure as part of a Web3D announcement
 +
** Ensure that web3d.org apache http configuration is updated to match
 +
** NPS servers can also be set, it will be good to compare
 +
** Ask Web3D Members and browser builders if they need to push out a software update
 +
** Ensure that sourceforge.net applies the change for our several-thousand .x3d models
 +
** Do major web browsers also need a modification?
 +
** Test all of the above
 +
* Confirmed: update is part of Apache configuration [http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types mime.types] file
 +
** Confirm whether there is an Apache patch system should have this going out to existing servers (yes the original name was "a patch-y server")
 +
* Once proper settings are confirmed to work with Web3D tools, issue corresponding press release
 +
* Update all X3D specification references to match the approved version and descriptions
 +
* Update the [http://www.web3d.org/x3d/content/examples/X3dResources.html X3D Resources] page. Do we need to add HTTP Server Configuration Hints to accompany the [http://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html X3D Scene Authoring Hints] page?
 +
 
 +
==== Original Work List ====
 +
 
 +
The MIME media type applications are fully complete, accomplishing all previously identified preparatory tasks:
 +
* Confirmed correct use of conjunction with sub-type (+xml, -vrml)
 +
* Comments on base reference RFC 2077
 +
** "Similarly, the VRML discussion list has been archived as: http://vrml.wired.com/arch" can be updated to X3D public mailing list - April 2009 to present [http://web3d.org/pipermail/x3d-public_web3d.org/]
 +
** If they ask us to modify RFC 2077, we can point to the updated mailing list link
 +
** Other model subtypes: on Wikipedia Media Type [http://en.wikipedia.org/wiki/Internet_media_type#Type_model]
 +
* Review complete on following HTML5-related issues
 +
**Note there is not a new HTML5 mime type defined
 +
** W3C Working Draft [http://www.w3.org/TR/html5-diff/ HTML5 differences from HTML4]
 +
** Section 2 [http://www.w3.org/TR/html5-diff/#syntax Syntax] includes some media type (i.e. MIME type) details. Interestingly it refers to multiple media types, providing both '''text/html''' and '''application/xml''' examples.
 +
** Perhaps we should discuss both '''model/x3d''' and '''application/xml''' examples? No, not desired.
 +
** Interesting point, possibly relevant to X3D: ''Some MIME types (e.g. text/plain) that are guaranteed to never be supported as scripting types for script were specified, so authors can safely use them for custom data blocks.''
 +
* Perform public review on [http://www.web3d.org/x3d/publiclists x3d-public@web3d.org mailing list]
 +
* Gain approval of [http://www.web3d.org/realtime-3d/working-groups/x3d X3D Working Group] and concurrence of [http://www.web3d.org/realtime-3d/about/board Web3D Board of Directors]
 
* Review the IETF [http://www.iana.org/cgi-bin/mediatypes.pl MIME Type Submission] references
 
* Review the IETF [http://www.iana.org/cgi-bin/mediatypes.pl MIME Type Submission] references
 
* Finalize application details that follow
 
* Finalize application details that follow
 
* Submit to IETF and follow up on any resulting actions or approvals
 
* Submit to IETF and follow up on any resulting actions or approvals
  
Our goal is make this submission during May 2012.
+
== Registration application for X3D MIME type ==
  
----
+
''Editors note: XML, ClassicVRML, and Binary encoding responses are merged together in this explanatory document. Three separate applications are submitted for the three different encodings.''
  
== Draft registration application for X3D MIME type ==
+
''Editors note: See [http://tools.ietf.org/html/rfc3023 RFC 3023, XML Media Types] for requirements specific to XML media types.''
XML, ClassicVRML, and Binary responses merged together. In the end, three separate applications will need to be created. See [http://tools.ietf.org/html/rfc3023 RFC 3023, XML Media Types] for requirements specific to XML media types.
+
 
 +
===1. Media Type Name===
  
===1. Media Type Name:===
 
 
Model
 
Model
  
===2. Subtype names:===
+
===2. Subtype names===
 +
 
 
Standards Tree
 
Standards Tree
* x3d-vrml
 
 
* x3d+xml
 
* x3d+xml
 +
* x3d-vrml
 
* x3d+fastinfoset
 
* x3d+fastinfoset
  
===3. Required parameters:===
+
===3. Required parameters===
 +
 
 
None
 
None
  
===4. Optional parameters:===
+
===4. Optional parameters===
 +
 
 
None
 
None
  
===5. Encoding considerations:===
+
===5. Encoding considerations===
 +
 
 
This application represents the different MIME types used for three different encodings of the X3D ISO standard (see [1]). The standard defines an abstract information structural representation, for which several file formats are available. These formats are currently defined to be:
 
This application represents the different MIME types used for three different encodings of the X3D ISO standard (see [1]). The standard defines an abstract information structural representation, for which several file formats are available. These formats are currently defined to be:
  
Line 62: Line 114:
 
* Compressed Binary: 'binary'
 
* Compressed Binary: 'binary'
  
===6. Security considerations:===
+
''Editors notes regarding encodings:''
This needs to be rewritten to address the questions and statements in [http://tools.ietf.org/html/rfc4288#section-4.6 RFC 4288, Media Type Specifications and Registration Procedures (Security Requirements)]. Specifically need to address/state response for
+
* ''A variety of character encodings are possible for the XML-based .x3d encoding (reference [http://www.web3d.org/files/specifications/19776-1/V3.3/Part01/concepts.html#FileExtensionAndMIMETypes 19776-1 paragraph 4.4.1]).''
* Complex media types
+
* ''Only the utf8 character encoding is allowed for the ClassicVRML .x3dv encoding (reference [http://www.web3d.org/files/specifications/19776-2/V3.3/Part02/concepts.html#ClassicVRMLEncodedX3DFilesAndWWW 19776-2 paragraph 4.4]).''
* Active content
+
* ''Name identifiers (DEF, Prototype names, [http://tools.ietf.org/html/rfc6838#section-4.11 fragment identifiers] etc.) must only use UTF-8 characters.''
* Release of information
+
* ''Further information is available on the Unicode FAQ [http://www.unicode.org/faq/utf_bom.html UTF-8, UTF-16, UTF-32 & BOM].''
* Decompression issues
+
* External security considerations
+
  
Scripting is defined as being available for the specification. Two languages are defined: Java and ECMAScript. 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.
+
===6. Security considerations===
 +
 
 +
''Editors note: A number of relevant references pertain to X3D model security, particularly [http://tools.ietf.org/html/rfc4288#section-4.6 RFC 4288, Media Type Specifications and Registration Procedures (Security Requirements)].''
 +
* '''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
 +
[http://www.w3.org/Security World Wide Web Consortium (W3C) Security Recommendations]
 +
for
 +
[http://www.w3.org/TR/xmldsig-core XML Signature]
 +
and
 +
[http://www.w3.org/TR/xmlenc-core 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.
 +
* [http://tools.ietf.org/html/rfc2854#section-7 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.''
 +
* [http://www.w3.org/TR/html401/appendix/notes.html#h-B.10 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 [[http://tools.ietf.org/html/rfc1738 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.''
 +
* [http://www.w3.org/Security/wiki/HTML5 HTML5 security references]
 +
** Details regarding specific HTML5 elements seem to be not applicable to X3D mime types
 +
 
 +
===7. Interoperability considerations===
 +
 
 +
The definition of the file format is maintained by the [http://www.web3d.org 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.
  
===7. Interoperability considerations:===
 
 
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.
 
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.
  
Previous text:
+
===8. Published specification===
''The definition of the file format is maintained by the Web3d Consortium (http://www.web3d.org) 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.''
+
  
===8. Published specification:===
+
See [http://tools.ietf.org/html/rfc6838#section-4.10 RFC 6838, Media Type Specifications and Registration Procedures (Publication Requirements)] for detailed instructions.
See [http://tools.ietf.org/html/rfc4288#section-4.10 RFC 4288, Media Type Specifications and Registration Procedures (Publication Requirements)] for detailed instructions.
+
All revisions of the X3D specification is maintained online at
All revisions of the X3D specification can be found here:
+
 
http://www.web3d.org/realtime-3d/specification/all
 
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
+
The most recent specification is available from the ISO website (for a fee) or from Web3D Consortium (without charge)
* [http://www.web3d.org/files/specifications/19776-1/V3.2/index.html ISO/IEC 19776-1.2:2009 - XML Encoding]
+
* [http://www.web3d.org/files/specifications/19776-1/V3.3/index.html ISO/IEC 19776-1.2:2009 - XML Encoding]
* [http://www.web3d.org/files/specifications/19776-2/V3.2/index.html ISO/IEC 19776-2.2:2008 - ClassicVRML Encoding]
+
* [http://www.web3d.org/files/specifications/19776-2/V3.3/index.html ISO/IEC 19776-2.2:2008 - ClassicVRML Encoding]
* [http://www.web3d.org/files/specifications/19776-3/V3.2/index.html ISO/IEC 19776-3:2007 - Compressed Binary Encoidng]
+
* [http://www.web3d.org/files/specifications/19776-3/V3.3/index.html ISO/IEC 19776-3:2007 - Compressed Binary Encoding]
  
===9. Applications that use this media type:===
+
===9. Applications that use this media type===
The applications that use (or would use) the
+
 
* model/x3d-vrml
+
The applications that use (or would use) the media type
 
* model/x3d+xml
 
* model/x3d+xml
 +
* model/x3d-vrml
 
* model/x3d+fastinfoset  
 
* model/x3d+fastinfoset  
media type are those that display, create, edit, import, or export 3D model content using the X3D standard. A short list of the applications include:
+
are those that display, create, edit, import, or export 3D model content using the X3D standard. A short list of the applications include:
* BS Contact (Bitmanagement)
+
* Blender (Open source, runs on Windows, Macintosh, Linux)
* Instant Reality (Fraunhofer)
+
* BS Contact (from Bitmanagement, runs on Windows, Macintosh, Linux)
* ''Maya exporter''
+
* Flux (from Media Machines, runs on Windows)
* ''TBD''
+
* 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)
 +
* Rawkee (Open source Maya exporter, runs in Maya)
 +
* Vivaty (from Vivaty, runs on Windows, Flash based)
 +
* 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 [http://www.web3d.org/x3d/content/examples/X3dResources.html X3D Resources] for a comprehensive list of supporting applications
 +
 
 +
===10. Fragment identifier considerations===
 +
 
 +
[http://tools.ietf.org/html/rfc6838#section-4.11 Fragment identifiers] must be encoded in utf-8.
 +
 
 +
===11. Restrictions on usage===
 +
 
 +
None
 +
 
 +
===12. Provisional registration?===
 +
 
 +
None
 +
 
 +
===13. Additional information===
  
===10. Additional information:===
 
 
* XML Encoding
 
* XML Encoding
** Magic number(s): Use XML's specification
+
** Magic number(s): None
 
** File extension: '.x3d'
 
** File extension: '.x3d'
** Macintosh File Type Code(s): ''TBD''
+
** Macintosh File Type Code(s): TEXT
** Object Identifier(s): ''TBD''
+
** Object Identifier(s): None
 
+
<!-- Object Identifier(s): http://www.alvestrand.no/objectid/index.html -->
 
* ClassicVRML Encoding
 
* ClassicVRML Encoding
 +
** Deprecated alias names for this type: No deprecated alias name for x3d-vrml.
 
** Magic number(s): #X3D
 
** Magic number(s): #X3D
 
** File extension: '.x3dv'
 
** File extension: '.x3dv'
** Macintosh File Type Code(s): ''TBD''
+
** Macintosh File Type Code(s): TEXT
** Object Identifier(s): ''TBD''
+
** Object Identifier(s): None
 
+
 
* Compressed Binary Encoding
 
* Compressed Binary Encoding
** Magic number(s): ''TBD''
+
** Deprecated alias names for this type: No deprecated alias name for x3d+fastinfoset.
 +
** Magic number(s): None
 
** File extension: '.x3db'
 
** File extension: '.x3db'
** Macintosh File Type Code(s): ''TBD''
+
** Macintosh File Type Code(s): None
** Object Identifier(s): ''TBD''
+
** Object Identifier(s): None
 +
 
 +
===14. Intended usage===
  
===11. Intended usage:===
 
 
COMMON
 
COMMON
  
===12. Other Information/GeneralComment:===
+
===15. Other Information/General Comment===
''TBD: It is not clear what should (or needs) to go in this section. The text below is what was previously here.''
+
 
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.
+
x3d-vrml files are encoded using utf-8.
 +
 
 +
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 rationale. The MIME types and file extensions were changed to indicate this modified standard.
 
# Content Sub-types
 
# 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 plaintext VRML-encoded file format would use the extension ".x3dv", and if compressed using GZIP uses the extension ".x3dvz"
+
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 plain text VRML-encoded file format would use the extension ".x3dv", and if compressed using GZIP uses the extension ".x3dvz".
 +
 
 +
===16. Person to contact for further information===
  
===13. Person to contact for further information:===
+
* Name: Leonard Daly and Don Brutzman (X3D Working Group Co-Chairs)
* Name: Leonard Daly (X3D Working Group Co-Chair)
+
* E-mail: x3d-chair AT web3d.org
* E-mail: <use appropriate alias>
+
* Author/Change controller: Web3D Consortium
* Author / Change controller: The Web3D Consortium
+

Latest revision as of 14:09, 17 June 2016

A MIME Media Type is a two-part identifier for file formats on the Internet. The X3D Working Group has provided formal submissions to the [http://www.iana.org Internet Assigned Names Authority (IANA) ] to support X3D MIME Media Types. This work is now complete with all submitted types(.x3d .x3dv .x3db) approved.

Future work for MIME-type approval

With additional effort, the X3D Working Group expects to submit MIME-type requests for

  • X3D JSON Encoding
  • X3D Efficient Binary Encoding (EBE)
  • Shape Resource Container (SRC) - possibly

Completed work that gained final MIME-type approval

In 1997 the Internet Engineering Task Force (IETF) approved IETF RFC 2077 for the Model MIME type. This supports VRML and establishes a MIME basis for other 3D model formats. However, the IETF had not originally approved X3D as an official MIME type, primarily due our incomplete prior efforts which did not submit a formal final application. This page is where we are building that formal application for official status of the X3D MIME-Type.

The current round of work started in 2008 with an initial application submission late that year. Review comments were received from IETF MIME-Type task force, reconciled and incorporated back into the application in February 2009. This effort was reported and collected as Registration of media type model/x3d+XXX.

The updated document appears below. All edits were accomplished in conformance with the current application standard. The completed application was sent to 'ietf-types@iana.org' with the subject line "Registration of media type model/x3d+XXX" included.

References

Approval Complete

All of the current X3D MIME media type submissions are complete, approved by the Internet Assigned Names Authority (IANA) and online:

NOTE: use correct combinations of plus + and minus - signs as shown above

TODO: Deployment Action Items

  • Configure http servers and document the configuration procedure as part of a Web3D announcement
    • Ensure that web3d.org apache http configuration is updated to match
    • NPS servers can also be set, it will be good to compare
    • Ask Web3D Members and browser builders if they need to push out a software update
    • Ensure that sourceforge.net applies the change for our several-thousand .x3d models
    • Do major web browsers also need a modification?
    • Test all of the above
  • Confirmed: update is part of Apache configuration mime.types file
    • Confirm whether there is an Apache patch system should have this going out to existing servers (yes the original name was "a patch-y server")
  • Once proper settings are confirmed to work with Web3D tools, issue corresponding press release
  • Update all X3D specification references to match the approved version and descriptions
  • Update the X3D Resources page. Do we need to add HTTP Server Configuration Hints to accompany the X3D Scene Authoring Hints page?

Original Work List

The MIME media type applications are fully complete, accomplishing all previously identified preparatory tasks:

  • Confirmed correct use of conjunction with sub-type (+xml, -vrml)
  • Comments on base reference RFC 2077
    • "Similarly, the VRML discussion list has been archived as: http://vrml.wired.com/arch" can be updated to X3D public mailing list - April 2009 to present [1]
    • If they ask us to modify RFC 2077, we can point to the updated mailing list link
    • Other model subtypes: on Wikipedia Media Type [2]
  • Review complete on following HTML5-related issues
    • Note there is not a new HTML5 mime type defined
    • W3C Working Draft HTML5 differences from HTML4
    • Section 2 Syntax includes some media type (i.e. MIME type) details. Interestingly it refers to multiple media types, providing both text/html and application/xml examples.
    • Perhaps we should discuss both model/x3d and application/xml examples? No, not desired.
    • Interesting point, possibly relevant to X3D: Some MIME types (e.g. text/plain) that are guaranteed to never be supported as scripting types for script were specified, so authors can safely use them for custom data blocks.
  • Perform public review on x3d-public@web3d.org mailing list
  • Gain approval of X3D Working Group and concurrence of Web3D Board of Directors
  • Review the IETF MIME Type Submission references
  • Finalize application details that follow
  • Submit to IETF and follow up on any resulting actions or approvals

Registration application for X3D MIME type

Editors note: XML, ClassicVRML, and Binary encoding responses are merged together in this explanatory document. Three separate applications are submitted for the three different encodings.

Editors note: See RFC 3023, XML Media Types for requirements specific to XML media types.

1. Media Type Name

Model

2. Subtype names

Standards Tree

  • x3d+xml
  • x3d-vrml
  • x3d+fastinfoset

3. Required parameters

None

4. Optional parameters

None

5. Encoding considerations

This application represents the different MIME types used for three different encodings of the X3D ISO standard (see [1]). The standard defines an abstract information structural representation, for which several file formats are available. These formats are currently defined to be:

  • XML: '8-bit text'
  • ClassicVRML: '8-bit text'
  • Compressed Binary: 'binary'

Editors notes regarding encodings:

6. Security considerations

Editors note: A number of relevant references pertain to X3D model security, particularly RFC 4288, Media Type Specifications and Registration Procedures (Security Requirements).

  • 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.

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

7. 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.

8. Published specification

See RFC 6838, Media Type Specifications and Registration Procedures (Publication Requirements) for detailed instructions. 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)

9. Applications that use this media type

The applications that use (or would use) the media type

  • model/x3d+xml
  • model/x3d-vrml
  • 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)
  • Flux (from Media Machines, runs on Windows)
  • 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)
  • Rawkee (Open source Maya exporter, runs in Maya)
  • Vivaty (from Vivaty, runs on Windows, Flash based)
  • 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

10. Fragment identifier considerations

Fragment identifiers must be encoded in utf-8.

11. Restrictions on usage

None

12. Provisional registration?

None

13. Additional information

  • XML Encoding
    • Magic number(s): None
    • File extension: '.x3d'
    • Macintosh File Type Code(s): TEXT
    • Object Identifier(s): None
  • ClassicVRML Encoding
    • Deprecated alias names for this type: No deprecated alias name for x3d-vrml.
    • Magic number(s): #X3D
    • File extension: '.x3dv'
    • Macintosh File Type Code(s): TEXT
    • Object Identifier(s): None
  • Compressed Binary Encoding
    • Deprecated alias names for this type: No deprecated alias name for x3d+fastinfoset.
    • Magic number(s): None
    • File extension: '.x3db'
    • Macintosh File Type Code(s): None
    • Object Identifier(s): None

14. Intended usage

COMMON

15. Other Information/General Comment

x3d-vrml files are encoded using utf-8.

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 rationale. The MIME types and file extensions were changed to indicate this modified standard.

  1. 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 plain text VRML-encoded file format would use the extension ".x3dv", and if compressed using GZIP uses the extension ".x3dvz".

16. Person to contact for further information

  • Name: Leonard Daly and Don Brutzman (X3D Working Group Co-Chairs)
  • E-mail: x3d-chair AT web3d.org
  • Author/Change controller: Web3D Consortium