Suggested Interactive Fiction Mediatypes

Technical Note 3 March 2006

Current Version:

http://purl.org/int-fiction/ifmi/documents/mediatypes

This Version:

http://purl.org/int-fiction/ifmi/documents/2006/NOTE-mediatypes-20060303

Previous version:

None

Date Issued:

2006-03-03

Publisher:

Interactive Fiction Metadata Initiative

Editor:

M.D. Dollahite <master.ryukage @gmail.com>

Document Status

This is an IFMI Technical Note

Copyright © 2006 M.D. Dollahite & Contributors.

This work is licensed under a Creative Commons Attribution 2.5 License. This copyright applies to this document and does not apply to IF data formats, media types, or technology.

Abstract

This document is a brief technical note enumerating suggested mediatypes for registration under RFC 4288 to replace the unregistered mediatypes previously in use within the Interactive Fiction community.

Status of this Document

This document is a Technical Note. It does not describe a standard or official Recommendation, but may be used as a style guide or suggestion for best current practices.

Table of Contents

1. 1 Purpose of this Document
2. 2 Media Type Summary
3. 3 Media Type Details
   1. 3.1 Z-Machine
   2. 3.2 Glulx
   3. 3.3 Blorb
   4. 3.4 TADS 3
   5. 3.5 Quetzal
4. 4 Security Considerations
5. Changes
6. References (Informative)

1 Purpose of this Document

This document makes suggestions of new Internet Media Types for Interactive Fiction games. Historically, IF has been transferred under unregistered experimental media types. However RFC 4288 [MEDIATYPES] published in December 2005 reduces the barriers to media type registration so greatly that unregistered types are effectively obsolete. RFC 4288 itself discourages both the traditional 'x-' and the new 'x.' prefixes in favor of registration in the 'prs.' or 'vnd.' trees. Described here are IFMI's suggestions for registered IF media types, however the actual decisions of whether to register and what types to use is left to the controllers of the various formats.

2 Media Type Summary

The following table summarizes the suggestions made by this document for IF media types. The "More Information" column references other sections of this document where the suggestion is explained in more detail. The suggested media type names are linked to sample registration forms.

The TADS 2 game and save formats cannot be registered because they do not have an explicit written specification. This document may be revised in the future to include suggestions for Hugo and ADRIFT formats.

3 Media Type Details

This section provides references to specifications and suggested changes to those specifications for improved suitability as media type formats.

3.1 Z-Machine

The Z-Machine format was originally created by Infocom, and is now probably owned by Activision. However, the de facto maintainer of the format for practical purposes is Graham Nelson, who has deconstructed and extended the format for continued use by other IF developers. (As noted in the Z-Machine specification [ZMACHINE], Nelson had a good deal of help doing this, but most of the credit seems to have accrued to him.)

There seems to be no explicit specification of the Z-Machine file format itself. The format is specified implicitly in the Z-Machine specification by virtue of being a binary dump of the VM's memory core. It may be necessary to write a specification dealing specifically with the file format in order to register a media type. The registration form itself may be able to serve this purpose.

The media types suggested for Z-Machine Stories are 'application/prs.zmachine' for standard game files and 'application/prs.zmachine+blorb' for games packaged in Blorb files (see Section 3.3).

The Z-Machine format comes in eight (8) versions, six (6) created by Infocom and two (2) more devised by Graham Nelson. An optional parameter 'version' is suggested, with an integer value giving the version number.

There is no standard filename suffix for Z-Machine games. Infocom typically used '.DAT' or no suffix at all, while later developers using the format typically use '.z?' or '.Z?', where '?' is the format version number. Filename suffixes for Blorbed Z-Machine files are defined by the Blorb specification.

3.2 Glulx

The Glulx format [GLULX] was created by Andrew Plotkin to replace the aging Z-Machine format. The media types suggested for Glulx files is 'application/prs.glulx' for standard game files and 'application/prs.glux+blorb' for games packaged in Blorb files (see Section 3.3).

Like the Z-Machine, Glulx story files are a simple binary dump of the VM memory core. Unlike the Z-Machine specification, the Glulx specification does not state this explicitly. It will likely also need a new document describing the file format specifically in order to be registered. Again, the registration form itself will probably suffice.

The standard filename suffix for Glulx Stories is '.ulx' or '.ULX'. Filename suffixes for Blorbed Glulx Stories are defined by the Blorb specification. MacIntosh file type codes are listed on Plotkin's web site, but are absent from the specification.

3.3 Blorb

The Blorb format is a generic wrapper for Z-Machine games, Glulx games, and multimedia resources. It allows multimedia resources to be packaged in a single file with the game they belong to. The format is controlled by Andrew Plotkin, who is currently working on a new version of the format [BLORB]. Suggestions here are for the Blorb 2.0 format, but may apply to Blorb 1.1 as well.

The generic media type suggested for Blorb files is 'application/prs.blorb'. When the type of executable game within the Blorb is known, the suffix '+blorb' may be appended to the media type for the executable. RFC 4288 cautions against the use of '+' suffixes on the basis that they may conflict with future reserved suffixes, however they are not explicitly reserved. It seems unlikely that 'blorb' will cause a problem of this nature. The use of the '+blorb' syntax is somewhat consistent with the '+xml' syntax, in that most of the concerns outlined in RFC 3023 Appendix A [RFC3023] also apply to Blorb.

Rather than the suffix syntax, it might be preferable to treat Blorb as a "bucket" format requiring various codecs. These codecs could then be specified as a parameter similar to that defined in RFC 4281 [RFC4281]. Unfortunately, the issues described in RFC 3023, Appendix A.6 regarding the inability of MIME dispatchers to differentiate media types based on parameters applies to Blorb as well. The set of applications that accept Blorbed Z-Machine Stories is currently disjoint with the set that accept Blorbed Glulx Stories; MIME dispatchers must therefore be able to send Blorb files to different applications based on the type of Story they contain. This situation is not expected to change in the foreseeable future, so the parameter method is simply not viable in the real world at this time.

It is suggested that URI fragment identifiers [RFC3986] be added to the Blorb specification. Such identifiers could include #Pict(n), #Snd(n), and #Exec(n), corresponding to the sections identified in the RIdx chunk. Additionally, the IFhd, IFmd, Plte, and Fspc chunks could also have corresponding fragment identifiers. Note that the #Fspc fragment would be evaluated as the actual image resource, rather than the Fspc chunk itself.

A discussion of security considerations should also be added to the specification, see Section 4.

3.4 TADS 3

The T3 VM Image format [T3VM] was created by Michael J. Roberts to replace his own aging (and undocumented) TADS 2 format. The specification for this format is included in the specification for the T3 VM itself. This specification is somewhat out-of-date, and it is not known whether the VM Image format has been affected by this aging; however the flexibility built into the format suggests that it has probably not been affected by changes to other features.

The suggested media type for T3 VM Images is 'application/prs.t3vm.image'; this type can have the optional parameter 'profile', with a value of either "executable" or "resource" to indicate whether the image is executable or resource-only.

The specification is fairly thorough in most areas, but does not include an explicit discussion of security (see Section 4), nor does it define the meaning of fragment identifiers.

The T3 VM Image format can contain additional files embedded in multimedia resource blocks. It may be useful to refer to these embedded files through fragment identifiers, therefore it is suggested that the specification be revised to include a definition of such. The suggested syntax is '#mres(path)', where path is the name of the desired resource file, which has the form of a relative filesystem path.

The T3 VM also uses state deltas as save formats; unlike resource-only images these are a completely different format. The suggested media type for T3 VM Saved States is 'application/prs.t3vm.state'. This format is not designed for long-term data integrity or widespread interoperability, and is not a normative part of the T3 VM specification. However, most implementations of T3 will probably use the same format, and it is designed for transport to other machines than the one it was created one, so it will still be useful to register it as a media type.

3.5 Quetzal

Quetzal is a standardized save game format for Z-Machine interpreters [QUETZAL]. The specification is quite thorough; only the addition of a security statement is necessary for registration.

4 Security Considerations

Media type registration requires disclosure of security concerns involved with the use of the format. Few of the specifications for these formats includes security information, but most can be accurately described by the general statements made in this section.

Security for IF formats is under ongoing evaluation. Most of these formats are executable bytecode that runs in a virtual machine; therefore security concerns are similar to Java applications. The native application hosting the VM must provide suitable sandboxing to prevent malicious code from accessing the host system. Typical procedures include restricting IO capabilities to allow access only to nonsensitive areas, forbidding direct memory access, and other restrictions on host system access.

Refer to RFC 3552 [RFC3552] for a discussion of best current practices regarding writing security texts for RFCs.

Changes

• [2006-02-27] Added Quetzal format.
• [2006-02-26] Made concrete suggestions for Blorb fragment IDs.
• [2006-02-22] Revised justification for '+blorb' syntax, added relevant references. Changes human-readable names for media types to improve consistency. Changed fragment syntax for T3 resources.
• [2006-02-19] Initial draft.

References (Informative)

[BLORB]

Blorb: An IF Resource Collection Format Standard, Version 2.0

http://eblong.com/zarf/blorb/

[GLULX]

Glulx, A 32-Bit Virtual Machine for IF

http://eblong.com/zarf/glulx/

[MEDIATYPES]

Media Type Specifications and Registration Procedures, BCP 13, Internet RFC 4288

http://www.ietf.org/rfc/rfc4288.txt

[QUETZAL]

Quetzal: Z-Machine Common Save-File Format Standard

http://www.inform-fiction.org/zmachine/standards/quetzal/

[RFC3023]

XML Media Types, Internet RFC 3023

http://www.ietf.org/rfc/rfc3023.txt

[RFC3552]

Guidelines for Writing RFC Text on Security Considerations, BCP 72, Internet RFC 3552

http://www.ietf.org/rfc/rfc3552.txt

[RFC3986]

Uniform Resource Identifiers (URI): Generic Syntax, Internet RFC 3986.

http://www.ietf.org/rfc/rfc3986.txt

[RFC4281]

The Codecs Parameter for "Bucket" Media Types, Internet RFC 4281

http://www.ietf.org/rfc/rfc4281.txt

[T3VM]

The T3 Virtual Machine

http://www.tads.org/tads3/t3spec/intro.htm

[ZMACHINE]

Z-Machine Standards Document 1.0

http://www.inform-fiction.org/zmachine/standards/z1point0/

Copyright © 2006 M.D. Dollahite & Contributors.

This work is licensed under a Creative Commons Attribution 2.5 License. This copyright applies to this document and does not apply to IF data formats, media types, or technology.