Talk:ISO 9660

ECMA-119 vs. ISO 9660

The note "this standard is identical to ISO 9660 (but please be careful because it has several small incompatibilities with real-life iso images)" for ECMA-119 lacks proof or reference. What are the actual differences? I don't think there are any because the 2nd edition of ECMA-119 states that it is "technically identical with ISO 9660" (see Brief History). — Preceding unsigned comment added by 84.176.238.81 (talk • contribs) 20:39, 26 October 2006 (UTC)

I agree. Unless someone can quote differences that we can verify, this unspecific warning is no help to anyone. -- Tempel 19:09, 12 November 2006 (UTC)

Here's a minor one. In section 8.5, the table over the fields in a Supplementary Volume Descriptor contains some significant techical differences. ECMA-119 specifies several fields as 'a-characters' or 'd-characters' or 'd-characters, SEPARATOR 1, SEPARATOR 2', while ISO 9660 specifies these fields as using a1-characters or d1-characters correspondingly.

The text descriptions of the fields do specify 'a1' and 'd1', but someone who didn't double-check things might go with the table. -- Athulin (talk) 10:13, 1 July 2014 (UTC)

A major difference is, of course, the changes introduced in ISO 9660 Amendment 1 in 2013. The claim of 'technical identity' in ECMA-119 is therefore no longer correct. (Though it must be admitted it is a bit of a chore to refer to ISO 9660:1988/Amd.1:2013 to refer to the latest text.) Athulin (talk) 09:35, 28 December 2014 (UTC)

That difference has since disappeared, as ECMA-119 has been issued in a later version (rev. 3), covering also the Amendment 1 changes. If there remain any technical differences (except such minor differences that ISO refers to the ISO character code standards and ECMA refers to ECMAs code standards) they are almost certainly unintentional. Athulin (talk) 18:41, 27 October 2019 (UTC)

Misunderstanding of the Standard?

Is that something that should be included? I'm thinking of the 8+3 file name restriction that far too many people say is a restriction in ISO 9660, when it's either a restriction selected by a CD-ROM publisher, or a failure of an implementation to implement the standard correctly. I think 2.1 makes that clear: 'Level of Interchange' is something that applies to a CD-ROM, not to a subset of the standard. — Preceding unsigned comment added by Athulin (talk • contribs) 10:16, 1 January 2016 (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.

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)