Created Sunday 02 September 2007 Modified Tuesday 11 September 2007 Version 0.2
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Note: This is the 0.1 version. It will be progressively modified to create the 0.2 version.
For specific bundle specifications, see:
Often, there is a need to pack multiples files together. For example the Open Document file format is just a ZIP file that pack XML and other files. When a web browser saves a webpage, it often saves the included documents as well (CSS styles, images, scripts ...). So this specification aims at defining a standard way to pack files together.
A bundle is defined as a folder that contains others folders or files. A bundle MUST include a type database. It is a file named types.bundle placed directly in the bundle directory and its conded is defined later.
A bundle has one or more mime types and each file of the bundle (except the required files) has zero or more mime types.
A bundle MUST have the mime type inode/bunle. Others mime-types applied to the bundle SHOULD begin by inode/bundle. (the point is included) or bundle/.
Applications that handle bundles MAY define extanded attributes for the bundle itself and the files it contains to set the mime type. However as this strongly depends on the platform, it is not specified here. However it is recommended to look at freedesktop specifications about that (See Shared MIME-info Database).
The names of the files in the bundle are highly dependent on the filesystem. For example some filesystems defines an encoding for files names when for others filesystems, the filename is just a sequence of bytes.
This specification defines that filenames MUST NOT contains any unicode character below 32 (not included). That means that among others, the tabulator and line breaks are forbidden whereas the space is allowed.
A file name MUST NOT contains the character /.
A file name MUST NOT be . or ...
File names are case sensitive and two file can have the same name in different cases. However it is NOT RECOMMANDED.
The type database is a files that store all mime types for the bundle. It is defined as a text file. As the characters below 3 are not allowed in files names, they are used to format the file.
The file is line-oriented and encoded in UTF-8. and lines are delimited by the ASCII character 10 (LF, linefeed).
The first line is a number, the version of the file format. It is a decimal number and the decimal separator is the dot (.). This specification defines the version 1.
In case the version number of an existing bundle is below 1, this is an error and this file in unusable.
If the version number in the file is above the version a program can understand but the entire part is a version that the program can understand, that means that the file is formatted according to a new version compatible with the old one. For example the file contains the version 1.5 when the program can only understand the version 1.
In this case the program SHOULD ignore lines it doesn't understand in the file. if not, it MUST NOT read the file. And when writing the file, unknown lines SHOULD be kept in the file and not discarded. If not, it MUST NOT write the file.
If the version number in the file is below a version a program can understand, this version of MUST be used to read the file. For example if the file has the version 1 but the program only understand version 1.5, the file MUST be read according to the version 1.5.
In case of writing, the program SHOULD write a file with a lower or same version of the actual file. For example of the file has a the version 1.1, the program should write a version 1.1 file and if not possible, version 1.
The following lines MUST begin with ASCII characters above 32 (space not included) and below 127 (not included) defining the type of the lines followed. This is followed by a tabulator (ASCII character 9). The rest of the line is completely dependant of the type of the line.
The first line must be followed by bundle types lines. Those are starting with the characters BT followed by a tabulator. The characters following the tabulator until the end of the line are defining the mime-types of the bundle.
The first bundle type line MUST define the type inode/bundle. Others lines do not have order.
If others bundles types are present and if there is a specifications related to these types, the bundle MUST follow these specifications as well.
Following the bundle types lines, are the file type lines. Those are beginning by FT and a tabulator. the rest of the line is composed of two fields separated by a tabulator. The first field contains the mime-type associated with the cannonical file path present in the second field.
A cannonical file path references a file in the bundle. It contains in order the directories names used to access to the file followed by the file name. All of those are separated by the character /. The special files . and .. MUST NOT be included.
A bundle can be detected by the presence of the file named types.bundle in a directory. The file being a text-file (lines being separated by ASCII character 10, LF) whose first lines begins with the ASCII character 1 and whose second line begins by BT, followed by a tabulator, by the string inode/bundle and the line feed.
In some cases, the bunle must be packed, for example when sending it as attachement by e-mail. We define this new format as a ZIP bundle whereas the other is defined as unpacked bundle. We use the words packing and unpacking to express the transformation between the two formats.
The ZIP bundle is a ZIP file that contains all files present in the bundle. The comment string in the ZIP file MUST be "Type: inode/bundle.zip".
The detection of a ZIP bundle is the same as detecting a ZIP file with the comment defined earlier.
If the files of the bundle cannot be inclded if the ZIP file, then an error MUST be reported and the operation aborted. It is possible that in the future, others packed bundle format will be defined.
Any file manager, open/save dialog box or any software intended for the end-user that follow this specification MUST follow the requested behaviour if it is relevant.