diff --git a/doc/devel/cookbook/ISO 9660-1999 b/doc/devel/cookbook/ISO 9660-1999 new file mode 100644 index 0000000..4b813b7 --- /dev/null +++ b/doc/devel/cookbook/ISO 9660-1999 @@ -0,0 +1,119 @@ +=============================================================================== + ISO/IEC 9660:1999 Cookbook +=============================================================================== + +Creation date: 2008-Jan-14 +Author: Vreixo Formoso +_______________________________________________________________________________ + +Contents: +--------- + +1. References +2. General +3. Features +4. Implementation +5. Known implementation bugs and specification ambiguities/problems + + +------------------------------------------------------------------------------- +1. References: + +ISO/IEC DIS 9660:1999(E) "Information processing. Volume and file structure of + CD­-ROM for Information Interchange" + + +------------------------------------------------------------------------------- +2. General + +ISO 9660:1999, also known as ISO-9660 version 2 is an update of the old +ISO 9660:1988 standard for writing data images for CD. + +In the same way Joliet does, it is based on a Secondary Volume Descriptor (that +is called Enhanced Volume Descriptor), that provides a second tree where the +new file information is recorded. + +------------------------------------------------------------------------------- +3. Features + +It makes some improvements with respect to ECMA-119, mainly related to relax +the constraints imposed by its predecessor. + +- It removes the limit to the deep of the directory hierarchy (6.8.2.1). +However, it still keep a limit to the path length, of 255 characters as in +ECMA-119. + +- File names don't need the version number (;1) anymore, and the "." and ";", +used as SEPARATORS for extension and version number, have no special meaning +now. + +- The file name max length is incremented to 207 bytes. + +- The file name is not restricted to d-characters. + +------------------------------------------------------------------------------- +4. Implementation + +ISO 9660:1999 is very similar to old ISO 9660:1988 (ECMA-119). It needs two +tree hierarchies: one, identified by the Primary Volume Descriptor, is recorded +in the same way that an ECMA-119 structure. + +The second structure is identified by a Enhanced Volume Descriptor (8.5). The +structure is exactly like defined in ECMA-119, with the exceptions named above. + +Thus, to write an ISO 9660:1999: + +- First 16 blocks are set to 0. +- Block 16 identifies a PVD (8.4), associated with a directory structure +written following ECMA-119. +- It is needed a Enhanced Volume descriptor to describe the additional +structure. It is much like a SVD, with version number set to 2 to identify +this new version. +- We can also write boot records (El-Torito) and additional SVD (Joliet). +- We write a Volume Descriptor Set Terminator (8.3) +- We write directory structure and path tables (L and M) for both ECMA-119 +tree and enhanced tree. Path table record and directory record format is +the same in both structures. However, ECMA-119 is constrained by the usual +restrictions. +- And write the contents of the files. + +Interchange levels 1, 2 and 3 are also defined. For PVD tree, they have the +same meaning as in ECMA-119. For EVD tree, in levels 1 and 2 files are +restricted to one file section (i.e., 4 GB filesize limit). In level 3 we can +have more than one section per file. Level 1 does not impose other +restrictions than that in the EVD tree. + +It seems that both El-Torito and Joliet can coexist in a ISO 9660:1999 image. +However, Joliet has no utility at all in this kind of images, as it has no +benefit over ISO 9660:1999, and it is more restrictive in filename length. + +------------------------------------------------------------------------------- +5. Known implementation bugs and specification ambiguities/problems + +- While the specification clearly states that the tree speficied by the Primary +Volume Descriptor should remain compatible with ISO-9660 (ECMA-119), i.e., it +should be constrained by ECMA-119 restrictions, some image generation +applications out there just make both Primary and Enhanced Volume Descriptors +to point to the same directory structure. That is a specification violation, as +for a) the directory hierarchy specified in the Primary Volume Descriptor +doesn't follow the restrictions specified in the specs, and b) the same +directories are part of two different hiearchies (6.8.3 "A directory shall not +be a part of more than one Directory Hierarchy."). +Thus, we should keep two trees as we do with Joliet. Or are there strong +reasons against this? + +- It's not very clear what characters are allowed for files and dir names. For +the tree identified in the Enhanced Volume Descriptor, it seems that a +"sequence of characters rather than d-characters or d1-characters" is allowed. +It also seems that the charset is determined by the escape sequence in the +EVD. Anyway, leaving escape sequence to 0 and use any user-specified sequence +(such as UTF-8) seems a good solution and is what many other applications do. +Linux correctly mounts the images in this case. + +- It is not clear if RR extensions are allowed in the tree identified by the +Enhanced Volume Descriptor. However, it seems not a good idea. With 207 bytes +filenames and XA extensions, there is no place for RR entries in the directory +records of the enhanced tree. In my opinion, RR extension should be attached to +the ECMA-119 tree that must also be written to image. + +