Talk:ISO 9660

ISO 9660:2023 vs earlier releases

In the 2023 version, a new technical requirement has been added, namely that the earlier 'standard for recording' (not well specified) is now specified to refer to ISO/IEC 10149 (Data interchange on read-only 120 mm optical disk (CD-ROM)). "Each sector shall be identified with a unique physical address in accordance with ISO/IEC 10149." (Introduction, 5.1 (where ISO 9660 conformance is stated to presuppose 10149 conformance), and 7.1.1.)

It looks like this may tie the standard even closer to CD-ROM as physical medium, and that volumes written to DVD or Blu-Ray can no longer be considered to be ISO-9660:2023-conformant.

ISO 9660 in the current revision can therefore probably no longer be described as intended for optical disks in general. Athulin (talk) 09:16, 3 September 2024 (UTC)

However ... after reading ECMA-130 2nd ed, which is said to be 'fully aligned' with 10149, I'm confused. There seems to be nothing about numbering of sectors, apart from "Physical Address of the Sector expressed in terms of the absolute time elapsed since the beginning of the User Data Area". That seems to exclude any non-CD medium from being used, though, and that may very well be the intention. Athulin (talk) 07:58, 6 September 2024 (UTC)

Applications

The lead indicates this is used for data exchange between different operating systems. I know it is used on CDROMs. What other media is this used on. I think this background should be in to the article and, scanning the lead and TOC, I don't see it there. ~Kvng (talk) 14:31, 10 November 2016 (UTC)

The ISO 9660 standard is formulated in a way that makes it independent of the carrier medium. While the original was intended for CD-ROM, there is no technical reasons to limit it to CD-ROM only. That makes the question of other medium almost uninteresting: you can implement ISO-9660 on a floppy disk if you care to, without breaking the standard. (Added: No longer true since the 2023 relase, and possibly not true earlier.)

As to 'data exchange' ... that was not the only reason for the standard. perhaps not even the most important reason. Early on, High Sierra was regarded as a data publication standard (CD-ROMs are read-only). Much of what to IT people seems strange in the standard, such as volume sets, are clearly targeted to the field of publication, particularly publication of serials.Athulin (talk) 19:04, 28 December 2016 (UTC)

To add to my previous comment, I'm more and more leaning to the idea that ISO 9660 was primarily intended for publication of technical documentation in serial form, or similar types of publication, like regulatory information. Examples of this type of publication is computer documentation, which in the 1980s typically took the form of dozens of binders, and heaps of printed pages which the customer was intended to insert in those binders, and remove when updates and corrections appeared some months later. Or when field service personnel were on-site, and needed to refer to some volumes that were sufficiently seldom used that keeping them updated was just not practical. Technical infrastructure components also comes (or came) with similar forms of documentation: telephone exchange systems, power stations, railway carriages and motors, buses, air planes, etc.

In that kind of context, some of the restrictions present in ISO 9660, for example the one that foreign character sets (used in supplementary and enhanced volume descriptors, and in extended attribute records anywhere) may only be used after agreement between originator and recipient. In 'normal' settings that is simply not practical, but in a situation where the recipient is a customer to the originator, who also may produce the receiving software (file system driver, or separate reading application), it makes considerably better sense. 78.82.180.168 (talk) 05:42, 29 June 2020 (UTC)

(Those paragraphis should have been signed by me ... )Athulin (talk) 05:52, 29 June 2020 (UTC)

Copyright issues

I am afraid the information on this page might be copyrighted. The International Standards Organisation owns all copyrights regarding ISO 9660, and redistribution of their $150 documentation is illegal. This page bypasses this by providing anyone with free information regarding CDs.

Please take this page down.

--  ApChrKey   ^Talk 23:21, 4 September 2020 (UTC)

Might be copyrighted? Copyright does not relate to information, it relates to form. The form that the copyright owner uses is what is copyrighted, not the information in it. Thus, copies of pages, or direct quotations of text would be copyrighted, but paraphrases of the same information would not normally be. (Some copyright apply to information, but that is not relevant here.)

Please identify the parts that infringe copyright. That makes it easier to investigate or discuss your claim. Alternatively, identify your locus standi.

As for 'free information' ... ECMA 119 is almost entirely the same as ISO 9660, with only some minor technical difference of no practical importance. ECMA 119 is free already. Athulin (talk) 11:20, 21 September 2020 (UTC)

File name character encoding in Rock Ridge?

As of this edit, ISO 9660 § Rock Ridge said:

Longer file names (up to 255 bytes) and fewer restrictions on allowed characters (support for lowercase, etc.) with the ISO-8859 or UTF-16 character set

That edit added the "with the ISO-8859 or UTF-16 character set" part, along with the reference. (I cleaned it up a bit to say "with ISO/IEC 8859 or UTF-16 character sets".)

The reference says:

Joliet uses UTF-16 coding while Rock Ridge uses ISO-8859 or UTF-16 based chars and allows 255 octets. Using UTF-8, Rock Ridge allows 85 Japanese characers or 255 US-ASCII chars.

It also says that "Rock Ridge became a IEEE standard around 1992.", although I have been unable to find it from standards.ieee.org. The IEEE P1282 draft version 1.12 claims that it was "Adopted 1994-07-08", but I couldn't find any 1282 standard with a search for 1282 on standards.ieee.org.

So if we use the 1.12 draft, it says:

3.4 File Naming Conventions

In all fields defined in ISO 9660, the character set to be used shall be as specified in ISO 9660. The character set to be used in the System Use Entries defined herein shall depend upon whether the entries are recorded in a Directory Hierarchy (defined in ISO 9660:6.8.2) associated with a Primary Volume Descriptor or in one associated with a Supplementary Volume Descriptor.

3.4.1 Primary Volume Descriptor File Naming Convention

Within a Directory Hierarchy identified by a Primary Volume Descriptor of an ISO 9660 volume, "SL" Component Content (see 4.1.3.1) and "NM" Name Content (see 4.1.4) shall be as defined in POSIX:2.2.2.32 and shall use the portable filename character set as defined in POSIX:2.2.2.60.

3.4.2 Supplementary Volume Descriptor File Naming Convention

Within a Directory Hierarchy identified by a Supplementary Volume Descriptor of an ISO 9660 volume, the character set used in the System Use Entries defined for the RRIP shall be the coded graphic character sets identified by the escape sequences in the Supplementary Volume Descriptor (see ISO 9660:7.4.2).

It appears that, if you're not lucky enough to own a printed version of IEEE Std 1003.1-1988, you're out of luck - my copy is either no longer in my possession or stashed away in a box in a storage unit, and all the searches I did online for 1003.1-1988 found the interpretations document, which is completely useless if I want to see what "POSIX:2.2.2.32" and "POSIX:2.2.2.60" are, so I'll just go with the current Single UNIX Specification.

The Portable Filename Character Set is A-Z. a-z, 0-9, ., _, and -. That's it - no ISO 8859/anything, no UTF-16, not UTF-8, nothing. So I'm not even seeing all of printable ASCII there, much less any non-ASCII characters from an ISO 8859 character set or from Unicode (whether encoded with UTF-16 or with UTF-8), for a Directory Hierarchy identified by a Primary Volume Descriptor of an ISO 9660 volume.

As for a Directory Hierarchy identified by a Supplementary Volume Descriptor of an ISO 9660 volume, section 7.4.2 of ISO 9660 says "The characters of the coded graphic character sets identified by the escape sequences in a Supplementary Volume Descriptor are referred to as c-characters." Section 8.5 "Supplementary Volume Descriptor" contains subsection 8.5.6 "Escape Sequences (BP 89 to 120)", which says:

This field shall specify one or more escape sequences according to ISO 2022 that designate the G0 graphic character set and, optionally, the G1 graphic character set to be used in an 8-bit environment according to ISO 2022 to interpret descriptor fields related to the Directory Hierarchy identified by this Volume Descriptor (see 7.4.4). If the G1 set is designated, it is implicitly invoked into columns 10 to 15 of the code table.

These escape sequences shall conform to ISO 2022, except that the ESCAPE character shall be omitted from each designating escape sequence when recorded in this field. The first or only escape sequence shall begin at the first byte of the field. Each successive escape sequence shall begin at the byte in the field immediately following the last byte of the preceding escape sequence. Any unused byte positions following the last sequence shall be set to (00).

If all the bytes of this field are set to (OO), it shall mean that the set of a l-characters is identical with the set of a-characters and that the set of dl-characters is identical with the set of d-characters. In this case both sets are coded according to ISO 646.

which would seem to indicate that *any* encoding supported by ISO/IEC 2022 can be used. There are several of them, including several "Right-hand Part of ... 8859/n" for various values of n - presumably those mean that the G1 set is the aforementioned 'Right-hand Part" with the G0 set being printable ASCII - in addition to "UTF-8 Level {1,2,3}" and "UTF-16 Level {1,2,3}".

So it sounds as if Rock Ridge could use any of that large set of encodings, including the Third supplementary set of Mosaic Characters/ Videotex and Facsimile; if the intent in the reference was to say that it can support the 8859/n encodings (and UTF-8?) in addition to UTF-16, that's true, but incomplete. Guy Harris (talk) 08:28, 7 April 2022 (UTC)

References

I guess you know better 😊 Seeaver (talk) 20:34, 8 April 2022 (UTC)

The reference to ISO-IR.pdf must be taken carefully. It is not restricted to escape character sequences that can be used in ISO 9660, but also includes other sequences. ISO 9660 is restricted to those that can be used by ISO 2022, and this excludes those mentioned in ISO-IR 2.8 and subsections ... which is where various UTF-? and UCS-? code tables are mentioned. ISO 9660 (as currently specified) does not allow Unicode. (Quick check in ISO/IEC DIS 9660:2022 -- which makes looking for ISO 2022-related stuff a real pain -- does not show any changes on this ... basically 9.5.7 and 10.5.19.) Athulin (talk) 09:52, 15 July 2022 (UTC)