.RT
.SP 2i
.ce 99
.ps +3
.vs +3p
.ft 3
Working Paper for Volume and File Structure of Write-Once Media
Using Non-Sequential Recording for Information Interchange
.ft P
.ps
.vs
.ce 0
.in +10n
.SP 1i

This document is subject to change without notice, and may not be referred
to as a standard until approved by an accredited standards body.
Distribution of this document warrants neither completeness
nor correctness of this document.

Use this document at your own risk.
It may be incomplete,
it may be inconsistent, and
it may be incorrect.
That is why it is a working paper and not a draft standard.
The editor would appreciate constructive feedback.
.in -10n
.SP 2.2i
.nf
.in \n(zzu
Technical Editor:
.in \n(zzu
.SP
Andrew Hume
AT&T Bell Laboratories,  Room 2C-515
600 Mountain Ave
Murray Hill  NJ  07974
USA
.SP .5
Phone: +1 908-582-6262
Fax: +1 908-582-5857
Email: \f(CWandrew@research.att.com\fP
.in 0
.fi
.BP
.SH
Editor's Remarks

This draft purports to be in a format suitable for a standard with two exceptions.
The first are remarks by the editor
.X1
this is a sample of an editorial comment
.X2
which are meant to point out changes in, or difficulties with, the text.

The second exception are explanations which provide a rationale or
motivation for a particular piece of the standard.
.R1
The purpose of these comments is to prepare the reader
who might otherwise be puzzled at what seem to be random comments
strewn throughout the text.
.R2

It is important that these rationales are not part of the standard.
They are colocated with the text they refer to for the reader's convenience
but eventually they will probably become an annex to the standard.
It is also a mistake if the rationales are necessary in order to understand
what some part of the standard means.

For this draft, there has been no committee review of the rationales;
they are solely the work and responsibility of the editor and may be
significantly altered for the next draft.

I have made the latest version of this working paper available via
.I ftp .
Assuming you have access to the Internet, the scenario is approximately
.P1
	ftp research.att.com		# research's IP address is 192.20.225.2
	<login as netlib; password is your email address>
	cd research/memo
	get x3b11.1-wp.text
	binary
	get x3b11.1-wp.ps.Z
.P2

The two files of interest are
.I compress 'ed
Postscript and
.CW wp.text
which is a more or less useful form of the text used
to generate the working paper.
.BP
.ce
.B "Table of Contents"

.de xx
.if !\\$1-1 .sp .5
.if 4-\\$1 \h`\\n(zzu`\\$2\f2\a\f1\\$3
..
.nf
.fi
.LN
.BP
.2C
.HH "General"
.HH "Scope"
This standard specifies the volume and file structure of media for the
interchange of information between users of information processing
systems using a type of medium that shall be recorded as if the
following constraints applied:
.DL 3n
the recording of the data field of a sector is constrained by the
relationship of the address of the sector with the address of any
other sector;
.DL
once recorded, the data field of a sector shall not be
recorded again with different information.

This standard specifies:
.DL 3n
the attributes of a volume and the descriptors recorded on it;
.DL
the relationship among volumes of a volume set;
.DL
the placement of files;
.DL
the attributes of the files;
.DL
record structures intended for use when the information constituting
a file is required to be interpreted as a set of records;
.DL
requirements for the processes which are provided within information
processing systems, to enable information to be interchanged between
different systems; for this purpose it specifies the functions to be
provided within systems which are intended to originate or receive
media which conform to this standard;
.DL
nested levels of medium interchange.
.HH "Conformance"
.HH "Conformance of a Medium"
A medium shall be in conformance with this standard when
it conforms to a standard of recording (see 1.4.15)
and all information recorded on it conforms to the specifications of this
standard.
A statement of conformance shall identify the lowest level
of medium interchange (see 4.1)
to which the contents of the medium conform.
.HH "Conformance of an Information Processing System"
An information processing system shall be in conformance with this
standard if it meets the requirements specified in this standard
either for an originating system (see 4.3),
or for a receiving system (see 4.4), or for both types of system.
A statement of conformance
shall identify which level of these requirements can be met by the
system (see 4.1 and 4.2).
.HH "References"

ISO 646 \f2Information processing-ISO 7-bit coded character set for
information interchange\fP (International Reference Version)

ISO 1539 \f2Programming languages \- FORTRAN\fP

ISO 2022 \f2Information processing \- ISO 7-bit and 8-bit coded character
sets-Code extension techniques\fP

ISO 2375 \f2Data processing \- Procedure for registration of escape sequences\fP

ISO 8859-1 \f2Information processing \- 8-bit single-byte coded graphic
character set\fP Part 1:  Latin alphabet No. 1

.C1
ISO 9660 \f2Information Processing \- Volume and file structure of
CD\-ROM for information interchange\fP

ISO 9945-1
\f2Information Technology - Portable Operating System Interface (POSIX)\fP
Part 1: System Application Program Interface (API) [C Language]
.C2

International Register of Coded Character Sets to be Used with Escape
Sequences

Standards for recording:  This standard assumes the existence of a
standard for recording (see 1.4.15)
.HH "Definitions"
For the purpose of this standard, the following definitions apply:
.de xx
.HH "\\$1"
.xz "!\\$1"
..
.xx "Application Program"
A program that processes the contents of a file, and may also process
selected attribute data relating to the file or to the volume(s) on
which the file is recorded.
.xx "Byte"
A string of eight binary digits operated upon as a unit.
.xx "Descriptor"
A structure containing descriptive information about a volume or a
file.
.xx "Extent"
A set of sectors or logical blocks, the addresses of which form a
continuous ascending sequence.
The address, or location, of an extent is the address of the first
logical block or sector in the extent.
.X1
.C1
I added the definition of the address of an extent.
.C2
This should probably just be something like ``contiguous consecutive sequence
of integers'' and force the language say ``extents of sectors''
(or logical blocks or whatever).
.X2
.xx "File"
.C1
A collection of information recorded over one or more extents.
.C2
.xx "File Section"
That part of a file that is recorded in any one extent.
.xx "Implementation"
A set of processes which enable an information processing system to
behave as an originating system, or as a receiving system, or as both
types of system.
.xx "Logical Block"
.C1
The unit of allocation of a logical volume.
.C2
.xx "Logical Volume"
A logical volume is a nonempty set of partitions over which one or more
namespaces are recorded describing a set files.
.xx "Originating System"
As information processing system which can create a set of files on a
volume set for the purpose of data interchange with another system.
.xx Partition
A partition is an extent of a volume.
Partitions may overlap.
.xx "Receiving System"
An information processing system which can read a set of files from a
volume set which has been created by another system for the purpose of
data interchange.
.xx "Record"
A sequence of bytes treated as a unit of information.
.xx "Sector"
The smallest addressable part of the recordable area on a medium that
can be accessed independently of other addressable parts of the
recordable area.
.xx "Standard for Recording"
A standard that specifies the recording method and the addressing
method for the information recorded on a medium.
The specifications of the standard for recording that are relevant for
this standard are:
.RS
.DL
a unique address for each sector;
.DL
the length of the data field within each sector;
.DL
the means for detecting whether the data field of a sector has not
yet been recorded.
.RE

The standard for recording used in conjunction with this
standard is subject to agreement between the originator and the
recipient of the volumes.
.xx "User"
A person or other entity (for example, an application program) that
causes the invocation of the services provided by an implementation.
.xx "Volume"
A logical address space as specified in the relevant standard for
recording.
.xx "Volume Set"
A set of volumes with identical volume set identification.
A logical volume may only belong to one volume set.
.HH "Notation"
The following notation is used in this standard:
.HH "Numerical Notation"
.HH "Decimal Notation"
Numbers in decimal notation are represented by decimal digits, and are
not shown in parentheses.
.HH "Hexadecimal Notation"
Numbers in hexadecimal notation are represented as hexadecimal digits
within parentheses.
The (decimal) values of the hexadecimal digits are
.TS
center, tab(-);
r c1 c1 c1 c1 c1 c1 c1 c.
digit-(0)-(1)-(2)-(3)-(4)-(5)-(6)-(7)
value-0-1-2-3-4-5-6-7
.sp .5
digit-(8)-(9)-(A)-(B)-(C)-(D)-(E)-(F)
value-8-9-10-11-12-13-14-15
.TE
.HH "Bit Positions"
.EQ
delim $$
.EN
Bit positions within an $n$
bit integer field are numbered such that the least significant bit is numbered 0
and the most significant bit is numbered $n - 1$.
.EQ
delim off
.EN
.HH "Descriptor and Record Formats"
.C1
Descriptor and record formats shall be specified by a table;
an example is shown in figure 1.
.C2
.Fd figExample
.de zz
.Fg "1" "Example Structure"
..
.1C
.KF no_value
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
1-4	Data Length (= D_L)	\f(CWuint32\fP (1.6.1.5)
5-36	Application Identifier	32 a-characters
37-40	Reserved	4 (00) bytes
41-42	Type	\f(CWint16\fP (1.6.1.4) = 57
43-(42+D_L)	Implementation Use	D_L bytes
_
.TE
.zz
.KE
.2C

This record has five fields.
The first, Data Length (also referred to as D_L),
is a 32-bit unsigned integer recorded at bytes 1 through 4.
The second, Application Identifier, is a string of a-characters occupying at most
32 bytes recorded at bytes 5 through 36.
The third field, Reserved, is 4 bytes, each with the value (00), recorded
at bytes 37 through 40.
The fourth field, Type, is a 16-bit signed integer whose value shall be 57
and is recorded at bytes 41 and 42.
The fifth field, Implementation Use, is D_L
(the value of the first field) bytes whose meaning is
unspecified by this standard, recorded at bytes 43 through (42+D_L).

The table specifies the location, type and size of each field;
the field semantics shall be described after the table.

.C1
Many of the structures (descriptors and records) described in this standard
are recorded so that the first byte of the structure
is the first byte of a sector or logical block.
All space, if any, after the end of the structure up to the end of the
sector or logical block are reserved for future use and shall be recorded
as (00).
.br
.C2
.HH "Other Notation"
.TS
center;
c l
l l.
_
Notation	Significance
_
BP	Byte position within a descriptor,
	starting with 0
ZERO	A single bit with the value 0
ONE	A single bit with the value 1
_
.TE
.HH "Basic Types"
.HH "Numerical Values"
Numeric types are referred to by a type name such as
.CW uint16
as well as the clause number of its definition.
.HH "8-Bit Unsigned Numerical Values"
An 8-bit unsigned numerical value, or
.CW uint8 ,
shall be represented in binary notation by
an 8-bit number recorded in a one-byte field.
.HH "8-Bit Signed Numerical Values"
An 8-bit signed numerical value, or
.CW int8 ,
shall be represented in binary notation by an
8-bit two's complement number recorded in a one-byte field.
.HH "16-Bit Unsigned Numerical Values"
A 16-bit unsigned numerical value, or
.CW uint16 ,
represented by the hexadecimal representation (wxyz)
shall be recorded in a two-byte field as (yz) (wx).
For example, the decimal number 4660 has (1234) as its
hexadecimal representation and shall be recorded as (34) (12).
.HH "16-Bit Signed Numerical Values"
A 16-bit signed numerical value, or
.CW int16 ,
represented in two's complement form by the hexadecimal representation (wxyz)
shall be recorded in a two-byte field as (yz) (wx).
For example, the decimal number \-30875 has (8765) as its
hexadecimal representation and shall be recorded as (65) (87).
.HH "16-Bit Signed Numerical Values (MSB)"
A 16-bit signed numerical value (MSB), or
.CW int16MSB ,
represented in two's complement form by the hexadecimal representation (wxyz)
shall be recorded in a two-byte field as (wx) (yz).
For example, the decimal number \-30875 has (8765) as its
hexadecimal representation and shall be recorded as (87) (65).
.HH "32-Bit Unsigned Numerical values"
A 32-bit unsigned numerical value represented in binary notation by a 32-bit
number represented by the hexadecimal representation (stuvwxyz)
shall be recorded in a four-byte field as (yz) (wx) (uv) (st).
For example, the decimal number 305419896 has (12345678) as
.C1
its hexadecimal representation and shall be recorded as (78) (56) (34) (12).
.C2
.HH "64-Bit Unsigned Numerical values"
A 64-bit unsigned numerical value represented in binary notation by a 64-bit
number represented by the hexadecimal representation (klmnopqrstuvwxyz)
shall be recorded in a eight-byte field as (yz) (wx) (uv) (st) (qr) (op) (mn) (kl).
For example, the decimal number 12345678987654321012 has (AB54A9A10A23D374) as
its hexadecimal representation and shall be recorded as
.C1
(74) (D3) (23) (0A) (A1) (A9) (54) (AB).
.C2
.HH "Character Sets and Coding"
Except as specified in this clause, the characters in the descriptors
shall be coded according to ISO 646.
All character strings whose interpretation is defined by this standard shall
consist of either a-characters, c-characters or f-characters as defined below.
The definitions depend on the current character set specification or
.CW charspec ,
which has the format shown in figure 2.
.xz "!\f(CWcharspec\fP"
.Fd figcharspec
.de zz
.Fg "2" "\f(CWcharspec\fP"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0	Character Set Type	\f(CWuint8\fP (1.6.1.1)
1-31	Escape Sequences	31 bytes
_
.TE
.zz
.KE
.2C
.HH "Character Set Type (BP 0)"
The Character Set Type is interpreted as a 5 bit number (bits 0-4) CS,
defined in the following subclauses and 3 single bit fields whose meaning is:
.ne 5v
Bit 5n
Interpretation
5
Registration: If set to ZERO, shall mean that the Escape Sequences
field specifies only escape
sequences registered according to ISO 2375;
If set to ONE, shall mean that the Escape Sequences field
specifies at least one escape sequence not registered
according to ISO 2375.
6
Interpretation:
If set to ZERO, shall mean that selected descriptor fields shall
be interpreted according to 1.6.2.7.
If set to ONE, shall
mean that selected descriptor fields shall be interpreted according
to 1.6.2.7.
.X1
This is the original wording; I won't change it until we find
out what 1.6.2.7 says.
.X2
7
Reserved:
this bit is reserved for future
standardization and shall be set to ZERO.
.R1
In general, the current character set is set by high level descriptors
such as the Volume Header Record and occasionally overridden for
specific lower level descriptors.
Thus, a volume may be Latin\-1 in general but have a Kanji partition.
.R2
.HH c-characters
.X1
.C1
c-characters are no longer used in this standard.
We should either use them or remove them.
There were previously listed as being used in the
.C2
Directory Identifier Record, Primary Volume
Descriptor and Logical Volume Descriptor.
.X2
.ne 5v
CS 7n
Interpretation
0-2
shall mean that the c-characters shall be the 95 characters in
positions 2/0 to 7/14 of the International Reference Version of ISO
646.
.X1
Why does this say International Reference Version?
.X2
3
shall mean that the c-characters shall be the 191 characters in
positions 2/0 to 7/14 and 10/0 to 15/15 of the character set of ISO
8859-1.
4-30
reserved for future standardization
31
shall mean the c-characters shall be a subset of the coded graphic
character sets specified by the Escape Sequences field.
This subset shall be subject to agreement between the
originator and the recipient of the volume.
.HH a-characters
The a-characters are a subset of the c-characters.
CS 7n
Interpretation
.ne 5v
0
shall mean that the a-characters shall be the 57 characters in
positions 2/0 to 2/2, 2/5 to 3/15, 4/1 to 5/10, and 5/15 of the
International Reference Version of ISO 646.
1
shall mean that the a-characters shall be the 83 characters in
position 2/0 to 2/2, 2/5 to 3/15, 4/1 to 5/10, 5/15, and 6/1 to 7/10
of the International Reference Version of ISO 646.
2
shall mean that the a-characters shall be the 95 characters in
positions 2/0 to 7/14 of the International Reference Version of ISO
646. 
3
shall mean that the a-characters shall be the 191 characters in
positions 2/0 to 7/14 and 10/0 to 15/15 of the character set of ISO
8859-1.
4-30
reserved for future standardization
31
shall mean that the a-characters shall be a subset of the
c-characters.  This subset shall be subject to agreement between the
originator and the recipient of the volume.
.HH f-characters
The f-characters are a subset of the a-characters.
.ne 5v
CS 7n
Interpretation
0
shall mean that the
f-characters shall be the 38 characters in the following positions of
the International Reference Version of ISO 646.
.TS
center;
c c c
l c l.
_
.C1
Character	Graphic	Position
.C2
_
FULL STOP	.	2/14
digits ZERO to NINE	0...9	3/0-3/9
capital letters A to Z	A...Z	4/15-5/10
LOW LINE	\&_	5/15
_
.TE
1
shall mean that the f-characters shall be the 65 characters in the
following positions of the International Reference Version of ISO 646.
.TS
center;
c c c
l c l.
_
.C1
Character	Graphic	Position
.C2
_
FULL STOP	.	2/14
digits ZERO to NINE	0...9	3/0-3/9
capital letters A to Z	A...Z	4/15-5/10
LOW LINE	\&_	5/15
small letters a...z	a..z	6/1-7/10
_
.TE
2
shall mean that the f-characters shall be the 95 characters in
positions 2/0 to 7/14 of the International Reference Version of ISO
646. 
3
shall mean that the f-characters and shall be the 191 characters in
positions 2/0 to 7/14 and 10/0 to 15/15 of the character set of ISO
8859-1.
4-30
reserved for future standardization.
31
shall mean that the f-characters and shall be a subset of the
a-characters.  This subset shall be subject to agreement between the
originator and the recipient of the volume.
.HH "Escape Sequences (BP 1-31)"
This field shall specify one or more escape sequences according to ISO
2022 that designate and implicitly invoke the graphic character sets
to be used in an 8-bit environment according to ISO 2022.

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.
.X1
why do we omit the ESCAPE?
.X2
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).

All the bytes of this field shall be set to (00) if the
Character Set Type field does not contain the number 31.
.HH "Justification of Characters"
In each fixed-length field the content of which is specified by this
standard to be characters, the characters shall be left-justified and
any remaining byte positions on the right shall be set to (00).
.C1
.X1
should we say that there is always at least one (00) after the string?
.X2
.C2
.HH "Embedded Escape Sequences and Shift Functions"
Text to be supplied in a later draft.
.X1
I have no idea what this means
.X2
.HH Timestamp
.C1
A
.CW timestamp
shall specify a date and time in the format shown in figure 3.
If all eight numbers are zero, it shall mean that the date and time
are not specified.
.xz "!\f(CWtimestamp\fP"
.Fd figtimestamp
.de zz
.Fg "3" "\f(CWtimestamp\fP"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Time Zone	\f(CWuint16\fP (1.6.1.3)
2-3	Year	\f(CWint16\fP (1.6.1.4)
4	Month	\f(CWuint8\fP (1.6.1.1)
5	Day	\f(CWuint8\fP (1.6.1.1)
6	Hour	\f(CWuint8\fP (1.6.1.1)
7	Minute	\f(CWuint8\fP (1.6.1.1)
8	Second	\f(CWuint8\fP (1.6.1.1)
9	Centiseconds	\f(CWuint8\fP (1.6.1.1)
10-11	Reserved	2 (00) bytes
_
.TE
.zz
.KE
.2C
.HH "Time Zone (BP 0-1)"
Offset from Universal Coordinated Time in minutes.
.HH "Year (BP 2-3)"
The year relative to 0 A.D.
.HH "Month (BP 4)"
Month of the year from 1 to 12.
.HH "Day (BP 5)"
Day of the month from 1 to 31.
.HH "Hour (BP 6)"
Hour of the day from 0 to 23.
.HH "Minute (BP 7)"
Minute of the hour from 0 to 59.
.HH "Second (BP 8)"
Second of minute, 0 to 59.
.R1
Leap seconds are not supported as there is no
model for how they might be used and it is incorrect to
specify how to record leap seconds without specifying their semantics.
.R2
.HH "Centiseconds (BP 9)"
Hundredths of a second, 0 to 99.
.HH "Reserved (BP 10-11)"
This is for padding out to 12 bytes.
.X1
I observe that we can encode the timestamp in 8 bytes as
12x31x24x60x60x100 fits in an \f(CWuint32\fP (1.6.1.5).
.X2
.C2
.HH "Checksums"
Some fields have a checksum.
The checksum shall be 16 bits long and be generated by the CRC-CCITT polynomial:
.SP .5
.EQ
delim $$
.EN
.ce
$x sup 16 + x sup 12 + x sup 5 + 1$
.EQ
delim off
.EN

.C1
As an example, the checksum of the three bytes (70) (6A) (77) is (168E).
Code to calculate the checksum is given in Annex 1.
.C2
.HH "Allocation Records"
Extents representing recorded data or space yet to be allocated shall
be described by allocation records.
.HH "Short Allocation Record"
The Short Allocation Record, or
.CW short_ar ,
shall have the format shown in figure 4.
.xz "!Short Allocation Record"
.Fd figShortAllocationRecord
.de zz
.Fg "4" "Short Allocation Record"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-3	Extent Location	\f(CWuint32\fP (1.6.1.5)
4-7	Data Length	\f(CWuint32\fP (1.6.1.5)
_
.TE
.zz
.KE
.2C
.HH "Extent Location (BP 0-3)"
This field shall specify the location of
the extent, if any information has been recorded in the extent, or
may be zero if no information has been recorded in the extent.
.HH "Data Length (BP 4-7)"
.C1
The lower 30 bits shall indicate the length of the extent in
.C2
bytes.
The high 2 bits shall indicate the state of the extent.  The value of
these 2 bits shall be one of the following:
.ne 5v
Number 8n
Interpretation
.C1
0
Extent not written and not allocated
1
Extent not written but allocated
2
Extent written and allocated
3
Extent location and length refer to the next extent of allocation records
.br
.C2
.BP
.HH "Volumes and Partitions"
This clause defines partitions, volumes and volume sets.

This clause describes how volumes are combined into volume sets.

This clause describes how to record data structures that label volumes,
describe the unallocated space on a volume,
and define an optional sector replacement scheme independent
from any scheme inherent in the standard of recording.

This clause describes how to divide a volume into partitions,
and how to label those partitions.

This clause does not describe any data structures specific to recording
user files or directories.
Such structures, whether they be those described in clause 3
or in some other document or standard, may be recorded within
partitions and as a partition descriptor.
.R1
This clause is intended to be largely independent from, but harmonious with,
the clause describing the file system.

There has been considerable debate in the committee over the need for
a sector replacement scheme.
With modern media and so-called ``error free'' interfaces such as SCSI,
the drive (and controller) is the best place to handle errors such as bad sectors.
If the interface to all media was like this, then perhaps this scheme might
not be necessary, although this doesn't help with non-drive errors such as
memory parity errors and bus interface errors.
However, particularly with WORM media and drives, there is a history of
drives without error correction and a history of turning off error
detection/correction for performance reasons.
Also, this standard, or a closely related one, can be used on existing
magnetic disk drives, and many such drives do not have an ``error free'' interface.
In fact, most SMD drives support a bad sector (or bad track) replacement scheme
similar to the one in this standard.
.R2

.C1
All the data structures defined in this clause shall be recorded so that
the first byte of the data structure coincides with the first byte of a sector.
.C2
.HH "Volume Space"
This clause takes a volume to be a sequence of sectors,
each with a unique sector number.
Sector numbers shall be consecutive integers starting at 0, assigned in the
order of the ascending physical addresses of the sectors of the volume
(as specified in the relevant standard for recording).
Sector 0 shall be assigned to the sector having the lowest physical
address which may contain recorded information.

The information on a volume shall be recorded in the data fields of
the set of all sectors on the volume.  This set shall be referred to
as the volume space of the volume.
.HH "Volume Data Structures"
.X1
overview to be done
.X2
.HH "Volume Header Sequence"
A volume header sequence shall consist of the following descriptors
consecutively recorded as follows.
.RS
.DL
The sequence shall contain zero or more Volume Header Records
(see 2.2.2)
each recorded consecutively at least once.
.DL
The sequence shall be terminated by either one or more unrecorded
sectors or, if there is a successor volume header sequence, by one
Volume Header Pointer Record (see 2.2.3)
recorded consecutively at least once.
The Volume Header Pointer Record shall identify the location of
the successor, if any, volume header sequence.
.RE

We define the governing Volume Header Record
.X1
I would suggest regnant as the best word here
but ruling and controlling are good too.
.X2
of a volume header sequence is the last Volume Header Record in the sequence,
including all successor volume header sequences.
The data structures describing the volume
shall be specified by the governing Volume Header Record. 

One or more volume header sequences shall be recorded on a volume subject
to the following restrictions:
.RS
.DL
volume header sequences containing only Volume Header Pointer Records
shall be recorded at one or more of the following sector addresses:
0, 16, 128, 192, 256, N-16, N-4,
where N is the largest recordable sector address in the volume.
.C1
All such volume header sequences must have the same governing Volume Header Record.
.DL
.C2
An occurrence of the volume header sequence shall be recorded such
that it terminates in the sector having largest sector number of the
volume.
.X1
I think this is detritus from earlier drafts.
.X2
.C1
.DL
There must be at least one Volume Header Record recorded.
.C2
.RE
.HH "Volume Header Record"
.xz "volume header record"
The Volume Header Record shall specify the size and location of the
primary file control block for the set of volume descriptors of the
volume, and certain attributes of the volume.
It shall be recorded in the format shown in figure 5.
.xz "!Volume Header Record"
.Fd figVolumeHeaderRecord
.de zz
.Fg "5" "Volume Header Record"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Predecessor Volume Header Sequence Location	\f(CWuint32\fP (1.6.1.5)
20-23	Volume Descriptor Set File Control Block Location	\f(CWuint32\fP (1.6.1.5)
24-27	Partition Descriptor Set File Control Block Location	\f(CWuint32\fP (1.6.1.5)
28-31	Unallocated Space Table Location	\f(CWuint32\fP (1.6.1.5)
32-35	Replacement Sector Record Location	\f(CWuint32\fP (1.6.1.5)
36-47	Recording Date and Time	\f(CWtimestamp\fP (1.6.3.9)
48-79	Implementation Use	32 bytes
80-511	Reserved	432 (00) bytes
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Predecessor Volume Header Sequence Location (BP 16-19)"
The field shall specify the address of the extent of the
volume in which a predecessor volume header sequence of the volume is
recorded.
If the number in this field is 0, it shall mean that no
such volume header sequence is identified.
.HH "Volume Descriptor Set File Control Block Location (BP 20-23)"
.C1
The field shall specify the address of file control block describing a set
of volume descriptors.
If the number in this field is 0, it shall mean that no
such volume descriptors are identified.
.C2
.HH "Partition Descriptor Set File Control Block Location (BP 24-27)"
.C1
The field shall specify the address of file control block describing a set
of partition descriptors.
If the number in this field is 0, it shall mean that no
such partition descriptors are identified.
.C2
.HH "Unallocated Space Table Location (BP 28-31)"
The field shall specify the address of the Unallocated Space Table for the volume.
.HH "Replacement Sector Record Location (BP 32-35)"
The field shall specify the address of the extent
in which Replacement Sector Records (see 2.2.7.1) are recorded.
A value of (0) shall indicate there are no such records.
.HH "Recording Date and Time (BP 36-47)"
This field shall indicate the date and the time of the day at which
the volume header record was recorded.
If all eight numbers in this field are zero, it shall mean
that the date and time are not specified.
.HH "Implementation Use (BP 48-79)"
This field shall be reserved for implementation use.
Its content is not specified by this standard.
.HH "Reserved (BP 80-511)"
This field shall be reserved for future standardization.
.HH "Volume Header Pointer Record"
The Volume Header Pointer Record shall specify the location of a
volume header sequence recorded on the volume.
It shall be recorded in the format shown in figure 6.
.C1
.X1
should we add a timestamp?
.X2
.C2
.xz "!Volume Header Pointer Record"
.Fd figVolumeHeaderPointerRecord
.de zz
.Fg "6" "Volume Header Pointer Record"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Successor Volume Header Sequence Location	\f(CWuint32\fP (1.6.1.5)
20-511	Reserved	492 bytes
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Successor Volume Header Sequence Location (BP 16-19)"
The field shall specify the address of the successor volume header sequence.
If the number in this field is 0, it shall mean
that no such volume header sequence is identified.
.HH "Reserved (BP 20-511)"
This field shall be reserved for future standardization.
.HH "Primary Volume Descriptor"
The Primary Volume Descriptor shall identify the volume and certain
attributes of the volume.
It shall be recorded in the format shown in figure 7.
.C1
.X1
should we add a timestamp?
.X2
.C2
.xz "!Primary Volume Descriptor"
.Fd figPrimaryVolumeDescriptor
.de zz
.Fg "7" "Primary Volume Descriptor"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-47	Volume Identifier	32 f-characters
48-49	Volume Sequence Number	\f(CWuint16\fP (1.6.1.3)
50-177	Volume Set Identifier	128 f-characters
178-209	Descriptor Character Set	\f(CWcharspec\fP (1.6.2)
210-213	Implementation Use	\f(CWuint32\fP (1.6.1.5)
214-469	Reserved	256 (00) bytes
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Volume Identifier (BP 16-47)"
This field shall specify an identification of the volume.
.HH "Volume Sequence Number (BP 48-49)"
This field shall specify the ordinal
number of the volume in the volume set of which the volume is a
member.
.HH "Volume Set Identifier (BP 50-177)"
This field shall specify an identification of the volume set of which
the volume is a member.
.HH "Descriptor Character Set (BP 178-209)"
This field shall specify the characters in certain fields of file
descriptors and directory descriptors that are associated with the
Primary Volume Descriptor (see 2.2.4).
.HH "Implementation Use (BP 210-213)"
This field shall be reserved for implementation use.
Its content is not specified by this standard.
.HH "Reserved (BP 214-469)"
This field shall be reserved for future standardization.
.X1
how many reserved bytes do we need? this doesn't have to be sector-sized.
.X2
.HH "Implementation Use Volume Descriptor"
The Implementation Use Volume Descriptor shall identify an
implementation which can recognize and act upon the content of the
implementation use field in the volume descriptor.
It shall be recorded in the format shown in figure 8.
.xz "!Implementation Use Volume Descriptor"
.Fd figImplementationUseVolumeDescriptor
.de zz
.Fg "8" "Implementation Use Volume Descriptor"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-47	Implementation Identifier	32 a-characters
48-79	Descriptor Character Set	\f(CWcharspec\fP (1.6.2)
80-511	Implementation Use	432 bytes
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Implementation Identifier (BP 16-47)"
This field shall specify an identification of an implementation which
can recognize and act upon the content of the implementation use field
in the volume descriptor.
.HH "Descriptor Character Set (BP 48-79)"
This field shall specify the characters in certain fields of file
descriptors and directory descriptors that are associated with the
Primary Volume Descriptor (see 2.2.4).
.C1
.X1
Why do we need this field?
It seems unnecessary.
.X2
.C2
.HH "Implementation Use (BP 80-511)"
This field shall be reserved for implementation use.
Its content is not specified by this standard.
.HH "Volume Space Management"
The unallocated parts of the volume are specified by an Unallocated Space Table.
It is a File Control Block (see 2.4)
consisting of indirect entries and space entries.
The space entry, defined below,
.C1
describes the unallocated volume space as the allocation records within the File Control Block.
.C2
.R1
A regular file has contents described by the allocation records in the File Control Block.
The Unallocated Space Table is like such a file, except that no data is
recorded and the extents are precisely the extents of unallocated space.
.R2
.HH "Space Entry"
.C1
The Space Entry shall specify extents that are unallocated and therefore,
available for use by an implementation.
.C2
It shall be recorded in the format shown in figure 9.
.xz "!Space Entry"
.Fd figSpaceEntry
.de zz
.Fg "9" "Space Entry"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Recorded Direct Entry Number	\f(CWuint32\fP (1.6.1.5)
20	Direct Entry Number	\f(CWuint8\fP (1.6.1.1)
21	Indirect Entry Number	\f(CWuint8\fP (1.6.1.1)
22	Flags	\f(CWuint8\fP (1.6.1.1)
23	File Type	\f(CWuint8\fP (1.6.1.1) = 5
24-25	Number of Allocation Records (=N_AR)	\f(CWuint16\fP (1.6.1.3)
26-[N_AR\(mu8+25]	Allocation Records	N_AR \f(CWshort_ar\fP (1.6.5.1)
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Recorded Direct Entry Number (BP 16-19)"
This field specifies the number of Direct Entries recorded in this File Control Block
prior to this entry.
.C1
.X1
we need to cover here (and everywhere else we talk about file control blocks)
exactly what this means: there is an implied hierarchy.
.X2
.C2
.HH "Direct Entry Number (BP 20)"
This field specifies the number of Direct Entries in this File Control Block.
.HH "Indirect Entry Number (BP 21)"
This field specifies the number of Indirect Entries in this File Control Block.
.HH "Flags (BP 22)"
This field shall specify recording information as specified in 2.4.2.8.
.C1
Bit 0 of this field shall be set to ZERO.
.C2
.HH "File Type (BP 23)"
.C1
This field shall be 5, specifying that this a unallocated space table.
.C2
.HH "Number of Allocation Records (=N_AR) (BP 24-25)"
This field shall specify the number of allocation records
recorded in this space entry.
.HH "Allocation Records (BP 26-[N_AR\(mu8+25])"
This field shall contain N_AR short form allocation records.
The type of allocation record shall be specified by the Flags field.
.HH "Sector Replacement"
This standard allows the specification of a sector replacement scheme
that is independent from any sector replacement performed
by the media recording subsystem.
The scheme is based on a sequence of Replacement Sector Records
which specify zero or more pairs of sector numbers
(\f2old\fP, \&\f2new\fP) with the meaning that references to sector
.I old
are translated into references to sector
.I new .
.HH "Replacement Sector Record Format"
The Replacement Sector Record shall be recorded in the format shown in
figure 10.
.xz "!Replacement Sector Record"
.Fd figReplacementSectorRecord
.de zz
.Fg "10" "Replacement Sector Record"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
.C1
16-17	Extent Length	\f(CWuint16\fP (1.6.1.3)
.C2
18-19	Number of Sector Addresses (=N_R)	\f(CWuint16\fP (1.6.1.3)
20-23	Next Replacement Sector Record Location	\f(CWuint32\fP (1.6.1.5)
24-27	Previous Replacement Sector Record Location	\f(CWuint32\fP (1.6.1.5)
28-31	Next Replacement Sector Record Extent Location	\f(CWuint32\fP (1.6.1.5)
32-35	Previous Replacement Sector Record Extent Location	\f(CWuint32\fP (1.6.1.5)
36-[N_R\(mu8+35]	Sector Addresses	N_R 2\(mu\f(CWuint32\fP (1.6.1.5)
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Extent Length (BP 16-17)"
This field shall specify the length, in sectors, of the extent
this record is recorded in.
.HH "Number of Sector Addresses (=N_R) (BP 18-19)"
.C1
This field shall specify the number of pairs of Sector Addresses in this record.
.C2
.HH "Next Replacement Sector Record Location (BP 20-23)"
.C1
This field, if nonzero, shall specify the location, in sectors, of the next Replacement Sector Record.
.C2
.HH "Previous Replacement Sector Record Location (BP 24-27)"
.C1
This field, if nonzero, shall specify the location, in sectors, of the previous Replacement Sector Record.
.C2
.HH "Next Replacement Sector Record Extent Location (BP 28-31)"
.C1
This field, if nonzero, shall specify the location, in sectors,
of the next extent of Replacement Sector Records.
.C2
.HH "Previous Replacement Sector Record Extent Location (BP 32-35)"
.C1
This field, if nonzero, shall specify the location, in sectors,
of the previous extent of Replacement Sector Records.
.C2
.HH "Sector Addresses (BP 36-[N_R\(mu8+35])"
.EQ
delim $$
.EN
.C1
This field contains N_R pairs of sector addresses recorded contiguously.
.C2
Each pair $(s sub i , s sub { i + 1 } )$ specifies that references to sector
$s sub i$ be treated as references to sector $s sub { i + 1 }$.
.EQ
delim off
.EN
.HH "Reading Replacement Sector Records"
.EQ
delim $$
.EN
This subclause specifies how the Replacement Sector Records are to be read.
The location of the first extent of Replacement Sector Records shall be specified
in the Volume Header Record.
The location of successor extents shall be specified in each Replacement Sector Record.
A Replacement Sector Record is recorded at the start of a sector.

Replacement Sector Records shall be read in the following order:
.RS
.DL
The first Replacement Sector Record to be read is that recorded in the first sector of the Replacement Sector Record
extent specified in the Volume Header Record.
.DL
After reading a Replacement Sector Record, it shall specify the location of the next Replacement Sector Record to be read
in the Next Replacement Sector Record Location field.
.DL
If a sector $s$ cannot be read, then the remaining sectors in the extent
$s+1$, $s+2$ shall be read in that order until a Replacement Sector Record is read.
If no Replacement Sector Record was read, then if the location of the next extent of Replacement Sector Records is known,
then scanning for a Replacement Sector Record shall resume at that location.
In this case, scanning shall cease at the first unrecorded sector
or recorded sector that is not a Replacement Sector Record.
.RE

When the Replacement Sector Records are read in the above order, a translation specification
for a sector overrides any previous translation.

All the references to sectors in a Replacement Sector Record 
shall not be translated according to this subclause.
.X1
Neither are any we encountered in determining the governing Volume Header Record.
Once we have that, then only the address of the Replacement Sector Record extent is untranslated.
I believe every other address is translated.
.X2
.EQ
delim off
.EN
.HH "Partition Data Structures"
.HH "Partition Descriptors"
Zero or more partition descriptors shall be recorded on a volume.
Each partition descriptor shall be numbered consecutively starting from 1.
This sequence number shall be the assigned sequence
number of the partition descriptor.
Each partition descriptor having the same sequence number shall be identical.
Partition descriptors shall be recorded contiguously in a stream of bytes
described by a file control block (pointed to by a field in the Volume Header Record).
.R1
The sequence number is solely for supporting redundant copies of descriptors.
.R2
.HH "Partition Geometry Descriptor"
The Partition geometry Descriptor shall specify the size and location of
a partition and shall be recorded in the format shown in
figure 11.
It does not imply that space has been allocated from the volume for this partition
(see the Flags field below).
.C1
.X1
does the descriptor need a timestamp?
.X2
.C2
.R1
Note that partitions may overlap.
This allows media to be generated with several predefined partition definitions
of varying sizes and locations.
In general,
it is inadvisable to use file systems on overlapping partitions.
.R2
.xz "!Partition Geometry Descriptor"
.Fd figPartitionGeometryDescriptor
.de zz
.Fg "11" "Partition Geometry Descriptor"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
.C1
16-19	Flags	\f(CWuint32\fP (1.6.1.5)
.C2
20-23	File System Type	\f(CWuint32\fP (1.6.1.5)
24-27	Partition Starting Location	\f(CWuint32\fP (1.6.1.5)
28-31	Partition Length	\f(CWuint32\fP (1.6.1.5)
32-35	Unallocated Space Table	\f(CWuint32\fP (1.6.1.5)
36-39	Access Table	\f(CWuint32\fP (1.6.1.5)
40-55	Unallocated Space Management	16 bytes
56-57	Partition Sequence Number	\f(CWuint16\fP (1.6.1.3)
58-73	Implementation Use	16 bytes
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Flags (BP 16-19)"
This field shall specify certain characteristics of the partition as follows.
.ne 5v
Bit 5n
Interpretation
0
If this bit is ONE,
it shall specify that space
has been allocated to this partition.
If this bit is ZERO,
it shall specify that space
has not been allocated to this partition.
1
If this bit is ONE,
it shall specify that unallocated space on this partition shall be
specified as described in 2.3.4.
If this bit is ZERO,
it shall specify that the method of unallocated space management on this partition
is not specified by this standard.
2
If this bit is ONE,
it shall specify that access to this partition shall be specified as
described in 2.3.5.
If this bit is ZERO,
it shall specify that the method of access management for this partition
is not specified by this standard.
.br
.C1
3-31
Reserved for future standardization.
.C2
.HH "File System Type (BP 20-23)"
This field shall specify an identification
of the file system structure written within the partition.
.TS
center;
c c
c l.
_
Number	Interpretation
0	Undefined file system type
1	X3B11.1 Write-Once File System
.C1
2	X3B11.1 Rewriteable File system
.C2
3-255	Reserved
256-	Registered file system types
_
.TE
.HH "Partition Starting Location (BP 24-27)"
This field shall specify the sector number at which the partition begins.
.HH "Partition Length (BP 28-31)"
This field shall specify the number of sectors which comprise the partition.
.HH "Unallocated Space Table (BP 32-35)"
This field shall specify the address of the Unallocated Space Table
(see 2.3.4) for this partition.
This field shall be zero unless bit 1 of the Flags field is set to ONE.
.HH "Access Table (BP 36-39)"
This field shall specify the address of the Access Table
(see 2.3.5) for this partition.
This field shall be zero unless bit 2 of the Flags field is set to ONE.
.HH "Unallocated Space Management (BP 40-55)"
This field is available for implementation use
for managing unallocated space for the partition.
.X1
the committee had explicitly requested that the previous two fields be merged
into this field for the case of an X3B11.1 file system.
I have split them out again because the space/access management mechanisms
are generic and this will encourage other file system types to use them.
.X2
.HH "Partition Sequence Number (BP 56-57)"
The field shall specify the sequence number for the partition.
.HH "Implementation Use (BP 58-73)"
This field shall be reserved for implementation use.
Its content is not specified by this standard.
.HH "Partition Implementation Use Descriptor"
The Partition Implementation Use Descriptor shall be recorded in the format
shown in 12
and shall identify a partition within the
volume space and an implementation which can recognize and act upon
the content of field reserved for implementation use in the partition
descriptor.
.X1
This descriptor need not be sector-sized.
.X2
.xz "!Partition Implementation Use Descriptor"
.Fd figPartitionImplementationUseDescriptor
.de zz
.Fg "12" "Partition Implementation Use Descriptor"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-47	Descriptor Character Set	\f(CWcharspec\fP (1.6.2)
48-49	Partition Sequence Number	\f(CWuint16\fP (1.6.1.3)
.C1
50-51	Reserved	2 (00) bytes
.C2
52-83	Partition Identifier	32 a-characters
84-211	Implementation Identifier	128 f-characters
212-467	Implementation Use	256 bytes
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Descriptor Character Set (BP 16-47)"
This field shall specify the characters in certain fields of the
Partition Descriptor.
.HH "Partition Sequence Number (BP 48-49)"
This field shall specify the partition sequence number.
.HH "Reserved (BP 50-51)"
.HH "Partition Identifier (BP 52-83)"
This field shall specify an identification of the partition.
.HH "Implementation Identifier (BP 84-211)"
This field shall specify an identification of an implementation which
.C1
can recognize and act upon the contents of the Implementation Use field.
.C2
.HH "Implementation Use (BP 212-467)"
This field shall be reserved for implementation use.
Its content is not specified by this standard.
.X1
Should we hardcode in a size or set up a scheme to allow a variable length?
.X2
.HH "Partition Space Management"
An implementation may specify (see 2.3.2.5) that the unallocated
space within a partition
.C1
shall be specified by an Unallocated Space Table.
.C2
This is a File Control Block consisting of indirect entries and space entries (see 2.2.6.1).
This is exactly the same mechanism as volume space management.
.R1
Managing unallocated space in partitions and in volumes are two isomorphic tasks.
Thus, we use the same data structure and mechanism.
.X1
This might change depending on how we handle the ordering of unallocated space extents.
.X2

This subclause, and the partition access subclause following,
are not explicitly referred to in this clause.
They are made available for clients, such as file systems,
to use as standard mechanisms.
.R2
.HH "Partition Access Management"
An implementation may specify (see 2.3.2.5)
that access to a partition shall be specified
by a Partition Access Table.
This is a File Control Block consisting of Indirect Entries and Access Entries described below.
.R1
Partition access management entails monitoring write access to a partition
and recording when the data structures described in this standard have
been successfully recorded.
.R2
.HH "Access Entry Format"
An Access Entry shall be recorded in the format shown in figure 13.
.xz "!Access Entry"
.Fd figAccessEntry
.de zz
.Fg "13" "Access Entry"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Recorded Direct Entry Number	\f(CWuint32\fP (1.6.1.5)
20	Direct Entry Number	\f(CWuint8\fP (1.6.1.1)
21	Indirect Entry Number	\f(CWuint8\fP (1.6.1.1)
22	Flags	\f(CWuint8\fP (1.6.1.1)
23	File Type	\f(CWuint8\fP (1.6.1.1) = 13
24	Access Type	\f(CWuint8\fP (1.6.1.1)
25-36	Recording Time	\f(CWtimestamp\fP (1.6.3.9)
37-511	Implementation Use	475 bytes
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Recorded Direct Entry Number (BP 16-19)"
This field specifies the number of Direct Entries recorded in this File Control Block hierarchy
prior to this entry.
.HH "Direct Entry Number (BP 20)"
This field specifies the number of Direct Entries in this File Control Block.
.HH "Indirect Entry Number (BP 21)"
This field specifies the number of Indirect Entries in this File Control Block.
.HH "Flags (BP 22)"
.C1
Reserved for future standardization.
.C2
.HH "File Type (BP 23)"
This field shall be 13, specifying that this a partition access table.
.HH "Access Type (BP 24)"
.C1
This field shall specify the type of Access Entry.
.C2
The types are
.ne 5v
"Type" 8n
Interpretation
0
Open: This Access Entry shall be recorded before any data
is recorded in the partition.
1
Close:
.C1
This Access Entry may be recorded only after all 
user data has been completely recorded and the volume 
and file data structures recorded on the medium conform to this standard.
.C2
2
.C1
Stable:
This Access Entry may be recorded only after the volume 
and file data structures recorded on the medium conform to this standard.
Some user data may not have been recorded.
.C2
3-255
Reserved for future standardization.
.HH "Recording Time (BP 25-36)"
This field shall specify the time of recording of this Access Entry.
If all eight numbers in this field are zero, it shall mean
that the date and time are not specified.
.HH "Implementation Use (BP 37-511)"
This field shall be reserved for implementation use.
Its content is not specified by this standard.
.R1
The partition access entries provide a standard, portable and convenient way
for implementations to indicate that write access to a medium has been successfully
terminated.
Because of optical media's large size and relatively slow access,
it is particularly important to avoid unnecessary consistency checks over
a partition or volume.

As an example, consider a partition mounted as a file system on a computer.
When the first write request for that partition is issued,
an Open Access Entry is recorded prior to performing the write request.
When the partition is unmounted, a Close Access Entry is recorded after
any queued write requests have been performed.
Periodically, Stable Access Entries may be written after bringing up to date
the data structures specified in this standard.
Finally, systems, such as file servers, that keep file systems mounted
for long periods of time and wish to minimize the risk of
a system failure and the use of lengthy recovery procedures,
might adopt heuristics such as recording a Close Access
Entry every 6 hours or after 10 minutes without a write request.
.R2
.HH "File Control Block"
This clause shall specify the recording of data bytes by
.I "file control blocks"
grouped together into a file control block hierarchy.
Each particular instance or version of the recorded data bytes
shall be specified by a
.I "direct entry" .

A file control block shall be a sequence of file control block entries
recorded over an extent.
An entry of the sequence shall be one of the following
.RS
.DL
unrecorded, if the entry has not yet been recorded
.DL
a direct entry, describing a recorded occurrence of a file or a set of extents
.DL
an indirect entry, describing additional file control blocks.
.RE

There are several types of direct entry.
However, all entries, both direct and indirect,
share several fields recorded identically.
In particular, each recorded entry contains
.I nd ,
the number of direct entries,
.I ni ,
the number of indirect entries, and
.I nrde ,
the number of recorded direct entries prior to recording this entry.
.R1
This standard requires a data structure that describes extents of bytes
recorded in a volume.
This can be used to record a user's file, the contents of a directory
or various system data.
Some media, such as WORM optical disks, cannot rerecord a sector
once it has been written, and thus this standard requires a data structure
that can describe successive versions of regions of bytes recorded in a volume.
.C1
Note that this structure is efficient on rewritable media by simply setting
.C2
.I nd
to one and
.I ni
to zero.
Alternatively, the same structures allow
.C1
rewritable media to support
a history of all versions of a file.
.C2

The file control block described here is not suitable for sequentially recorded media.
.R2
.HH "Traversing the File Control Block"
A file control block shall be recorded over an extent of
.C1
sectors or logical blocks.
The address of a file control block shall be
the address of the extent.
The extent shall consist of one or more file control block entries,
recorded one per sector or logical block, as follows:
.C2
.RS
.DL
The first Direct Entry Number
entries shall either be unrecorded or be recorded with direct entries.
.DL
The next Indirect Entry Number
entries shall either be unrecorded or be recorded with indirect entries
(see 2.4.3).
.DL
A direct entry shall not be recorded
until all lower numbered direct entries have been recorded.
.DL
The first indirect entry shall not be recorded until all of the
.C1
direct entries in this file control block have been recorded.
.C2
.DL
An indirect entry shall not be recorded
until the file control blocks specified by all lower numbered indirect entries
have been recorded.
.RE
.HH "Common File Control Block Entry Format"
All the entries in a File Control Block shall be recorded in a format of two parts.
The first part, shown in figure 14, shall be
the same for all types of entries.
The second part is unique to each entry and is described in the definition
of that entry.
.xz "!Common File Control Block Entry"
.Fd figCommonFileControlBlockEntry
.de zz
.Fg "14" "Common File Control Block Entry"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
.C1
16-19	Recorded Direct Entry Number	\f(CWuint32\fP (1.6.1.5)
.C2
20	Direct Entry Number	\f(CWuint8\fP (1.6.1.1)
21	Indirect Entry Number	\f(CWuint8\fP (1.6.1.1)
22	Flags	\f(CWuint8\fP (1.6.1.1)
23	File Type	\f(CWuint8\fP (1.6.1.1)
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field is different for each type of descriptor.
.HH "Recorded Direct Entry Number (BP 16-19)"
This field specifies the number of Direct Entries recorded in this File Control Block hierarchy
prior to this entry.
.HH "Direct Entry Number (BP 20)"
This field specifies the number of Direct Entries in this File Control Block.
.HH "Indirect Entry Number (BP 21)"
This field specifies the number of Indirect Entries in this File Control Block.
.HH "Flags (BP 22)"
This field shall specify recording
information about the file.
.ne 5v
Bit 8n
Interpretation
0
if set to ZERO, it shall mean that Short Form Allocation Records are used;
if set to ONE, it shall mean that Long Form Allocation Records are used
1
if set to ONE and the file is a directory,
the directory's entries are sorted according to 3.5.4.
If set to ZERO, the meaning is undefined.
2-7
Reserved for future standardization.
.HH "File Type (BP 23)"
This field shall specify the type of the file.
.ne 5v
Number 8n
Interpretation
0
shall mean that the type of the file is not specified by this field
1
shall mean that the file is a directory
2
shall mean that the file is regular file
3
shall mean that the information in the file is a set
of volume descriptors
4
shall mean that the information in the file is
.C1
a set of partition descriptors
.C2
5
.C1
shall mean that this is a Space Entry
.C2
6
.C1
.X1
no longer used
.X2
.C2
7
shall
mean that the file is an Extended Attribute file
8
shall mean that the
file is an Implementation Use file
9
shall mean that the file is an
Application Use file
10
shall mean that the file is a block special
device file
11
shall mean that the file is a character special device file
12
shall mean that this is an Indirect Entry
13
.C1
shall mean that this is an Access Entry
.C2
14-255
reserved for future standardization
.HH "Indirect Entry"
An Indirect Entry shall be recorded in the format
shown in figure 15.
.xz "!Indirect Entry"
.Fd figIndirectEntry
.de zz
.Fg "15" "Indirect Entry"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16	Recorded Direct Entry Number	\f(CWuint8\fP (1.6.1.1)
17	Direct Entry Number	\f(CWuint8\fP (1.6.1.1)
18	Indirect Entry Number	\f(CWuint8\fP (1.6.1.1)
19	Flags	\f(CWuint8\fP (1.6.1.1)
20	File Type	\f(CWuint8\fP (1.6.1.1) = 12
21-26	Indirect Entry Location	\f(CWaddress\fP (3.2.2)
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Recorded Direct Entry Number (BP 16)"
This field specifies the number of Direct Entries recorded in this File Control Block hierarchy
prior to this entry.
.HH "Direct Entry Number (BP 17)"
This field specifies the number of Direct Entries in this File Control Block.
.HH "Indirect Entry Number (BP 18)"
This field specifies the number of Indirect Entries in this File Control Block.
.HH "Flags (BP 19)"
This field shall specify recording information as specified in 2.4.2.8.
.HH "File Type (BP 20)"
This field shall contain 12.
.HH "Indirect Entry Location (BP 21-26)"
The field shall specify the location of an indirect File Control Block.
.HH "Direct Entry"
A direct entry shall be recorded as either a direct entry (see 3.6.1),
an access entry (see 2.3.5.1)
or a space entry (see 2.2.6.1).

.X1
This is confusing because we are using a file control block to describe
things which aren't files (like space tables and partition access).
I would propose a terminology change to help things out:
what is being controlled is data regions, so lets rename the file control block to
.I "data control block" .
Then what is now a direct entry can be split into three:
a file entry (which describes file-like things)
a space entry (which describes space-like things)
and an access entry (which describes partition access things).
The advantage is that the latter two don't need all those fields that the former
needs, and so can omit them and have more allocation records within the entry.
.X2
.HH "Volume Set"
A volume set shall consist of one or more volumes having common volume
set identification and identifying the same coded graphic character
sets for use within selected descriptor fields (see 1.6.2.5).
.C1
.X1
Which fields, exactly?
I suspect any that depend on the character set, namely [afc]-characters.
And referring to 1.6.2.5 seems weird.
.X2
.C2
All volumes in a volume set shall be numbered consecutively starting from 1.
This number shall be the assigned volume sequence number of the
volume.

The logical block size shall be the same for
all volumes of a volume set.
.C1
.X1
why do we talk of logical blocks here?
.X2
.C2
.BP
.HH "File System"
This clause describes how to record sets of files and directories.
It relies on a volume and partition labeling scheme, such as
clause 2 or other standards, for specifying
the location of recorded data.

This clause records data in partitions,
although it manages the partition sectors in larger units called logical blocks.
All directories, files and the content of files are recorded within partitions.
A set of files and directories, or file set, is described by a File Set Descriptor
.C1
which, among other things, specifies the root of a directory hierarchy.
.C2
Multiple file sets may be recorded in the same partition.
Finally, one or more file sets shall be combined together to form a logical volume.
.R1
This may seem harder or more difficult to understand than it needs to be.
Unfortunately, while there is considerable experience in file systems
spanning multiple volumes, there is little agreement in the 
terminology used nor semantics provided.

The basic building block is a file set.
It specifies administrative details (including the default character set)
and the root of a directory hierarchy.
The descriptors for files (and their contents) and directories (and their members)
use an addressing scheme which contains a partition number.
Thus, file sets (and files and directories) can span multiple partitions
and therefore, can span multiple volumes.

It is intended that the file system described here could use any volume/partition
labeling scheme; the main needs are a consistent means for identifying
partitions, such as (volume v, partition p), and a way of accessing
groups of sectors in partitions as logical blocks.
.R2
.HH "Interface to the Underlying Volume and Partition Labeling Scheme"
This clause shall specify the recording of directory hierarchies, files
and their contents.
.C1
This recording is done within partitions.
However, there are three accesses to data outside the partition:
.C2
"1) Space Management" 5n
.br
This shall be specified in a partition descriptor.
For the volume and partition scheme of clause 2,
this standard specifies that the Partition Geometry Descriptor
.C1
shall specify that the partition space management scheme of
2.3.4 be used (see 2.3.2.5).
.C2
"2) Access Management"
.br
This shall be specified in a partition descriptor.
For the volume and partition scheme of clause 2,
this standard specifies that the Partition Geometry Descriptor
.C1
shall specify that the partition access scheme of 2.3.5
be used (see 2.3.2.5).
.C2
"3) File Set"
.br
This descriptor, described below, shall be recorded as a volume descriptor.
For the volume and partition scheme of clause 2,
the File Set Descriptor shall be recorded as an Implementation Use
Volume Descriptor with a particular Implementation Identifier as specified in
3.4.1.
.R1
This subclause tries to describe exactly the hooks the file system needs
outside of the partitions where the data and control structures are recorded.
The mechanism of using a funny implementation identifier to distinguish
a File Set descriptor is not very good.
.R2
.HH "Basic Types"
.HH "Pathname"
A pathname is used to specify a file or directory by name.
It shall consist of an optional beginning SEPARATOR-1,
followed by zero or more identifiers separated by SEPARATOR-1.

A pathname shall be interpreted in the following way.
Each identifier shall be located in the directory specified by its predecessor.
For example, in the pathname
.C1
.CW x\f1SEPARATOR-1\fPy ,
.C2
file
.CW y
is located in directory
.CW x .
If the pathname begins with a SEPARATOR-1, the predecessor is taken to be the
root directory.
If the pathname does not begin with a SEPARATOR-1,
the predecessor is taken to be the current directory.
The reserved identifier SEPARATOR-2 specifies the current directory.
The reserved identifier SEPARATOR-3 specifies the parent of the current directory.
All but the last identifier in a pathname must be a directory identifier.
If it exists, the last identifier may be either
a directory identifier or a file identifier.

A file identifier is a sequence of one or more f-characters,
optionally followed by version specifier.
A version specifier is a SEPARATOR-4 optionally followed
by one or more digits from f-characters representing a number in the range 1 to 32767.
.X1
This is subtly different from the last draft which seemed to allow
the separator-4  to be missing but have a version number.
.X2
A directory identifier is one or more f-characters.

.C1
The separators used above shall be recorded as the following byte values:
.TS
center;
c c.
SEPARATOR-1	(1C)
SEPARATOR-2	(1D)
SEPARATOR-3	(1E)
SEPARATOR-4	(1F)
.TE
.C2
.R1
This section is new and replaces the definitions of file identifier, directory identifier, path identifier and file specification.
It is adapted from ISO 9945-1.
.R2
.HH "Recorded Address"
A logical block address shall be specified by an
.CW address
recorded in the format shown in figure 16.
.xz "!\f(CWaddress\fP"
.Fd figaddress
.de zz
.Fg "16" "\f(CWaddress\fP"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Partition Number	\f(CWuint16\fP (1.6.1.3)
2-5	Block or Segment Number	\f(CWuint32\fP (1.6.1.5)
_
.TE
.zz
.KE
.2C
.HH "Partition Number (BP 0-1)"
This field shall specify the partition sequence number.
.X1
We have not yet resolved the issue of how partition numbers are managed.
.X2
.HH "Block or Segment Number (BP 2-5)"
Local within the partition.
.HH "Allocation Records"
Extents representing recorded data or space yet to be allocated shall
be described by allocation records.
.HH "Long Allocation Record"
The Long Allocation Record, or
.CW long_ar ,
shall be recorded in the format shown in figure 17.
.xz "!Long Allocation Record"
.Fd figLongAllocationRecord
.de zz
.Fg "17" "Long Allocation Record"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-5	Extent Location	\f(CWaddress\fP (3.2.2)
6-9	Data Length	\f(CWuint32\fP (1.6.1.5)
10-15	Implementation Use	6 bytes
_
.TE
.zz
.KE
.2C
.HH "Extent Location (BP 0-5)"
This field shall specify the location of the start of the extent,
if any information has been recorded in the
extent, or may be zero if no information has been recorded in the
extent.
.HH "Data Length (BP 6-9)"
The contents of this field is defined as that
of the same field in 1.6.5.1.2.
.HH "Implementation Use (BP 10-15)"
This field shall be reserved for implementation use.
Its content is not specified by this standard.
.HH "Logical Volume"
A logical volume shall be the set of partitions on which a set of
files is recorded.

A logical volume shall consist of one or more file sets having common
logical volume identification.
All file sets in a logical volume shall be numbered consecutively
starting from 1; this number shall be the logical volume sequence number.
.C1
.X1
Be wary of this numbering stuff.
it is file sets that are being numbered, not partitions
(despite what the field names and descriptions imply).
.X2
.C2

The file set that has the highest logical volume sequence number of
the logical volume shall contain a description of all the directories
and regular files that make up the logical volume.
.X1
This subclause is in a state of flux;
this reflects the committee's thinking.
The previous draft talked about partitions; this has been changed to file sets.
.X2
.HH "File Set"
.HH "File Set Descriptor"
The File Set Descriptor shall describe a set of files and directories and
shall be recorded in the format shown in 18.
.X1
I am unsure of the types of the various Identifiers.
.C1
We may also want an advisory maximum volume sequence number.
.C2
.X2
.xz "!File Set Descriptor"
.Fd figFileSetDescriptor
.de zz
.Fg "18" "File Set Descriptor"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-47	Implementation Identifier	32 a-characters
48-79	Descriptor Character Set	\f(CWcharspec\fP (1.6.2)
80-83	Logical Block Size	\f(CWuint32\fP (1.6.1.5)
84-89	Root Directory File Control Block Location	\f(CWaddress\fP (3.2.2)
90-91	Logical Volume Sequence Number	\f(CWuint16\fP (1.6.1.3)
92-219	Logical Volume Identifier	128 f-characters
220-251	File Set Character Set	\f(CWcharspec\fP (1.6.2)
252-283	Application Identifier	32 a-characters
284-315	Copyright File Identifier	32 a-characters
316-347	Abstract File Identifier	32 a-characters
348-511	Reserved	164 (00) bytes
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Implementation Identifier (BP 16-47)"
This field shall specify the string ``\f(CWX3B11.1 File System\fP''. 
.HH "Descriptor Character Set (BP 48-79)"
This field shall specify the characters in certain fields of this descriptor.
.HH "Logical Block Size (BP 80-83)"
This field shall specify the size, in bytes, of a logical block.
.X1
This currently has to be the same for all volumes in a logical volume.
Given the demarcation into labeling and file structure, I don't think this
restriction need apply (but if it changes, we have to think carefully
about allocation records).
.X2
.HH "Root Directory File Control Block Location (BP 84-89)"
The field shall specify the location of the file control block describing the root
directory associated with the File Set Descriptor.
If this number is zero, it shall mean that the file control block is
not recorded.
.HH "Logical Volume Sequence Number (BP 90-91)"
This field shall specify the ordinal
number of the partition in the logical volume of which the partition
is a member.
.HH "Logical Volume Identifier (BP 92-219)"
This field shall specify an identification of the logical volume of
which the partition is a member.
If all bytes of this field are set to (00), it shall mean that the
partition is not a member of a logical volume.
.HH "File Set Character Set (BP 220-251)"
This field shall specify the characters in certain fields of file
descriptors and directory descriptors that are associated with the
directory hierarchy associated with this descriptor.
.C1
.X1
We need to make this specific; which fields exactly?
.X2
.C2
.HH "Application Identifier (BP 252-283)"
This field shall specify an identification of the specification of how
the data are recorded on those partitions of the logical volume which
have a sequence number less than or equal to the assigned logical
volume sequence number of the partition.
.X1
I don't understand what this means.
.X2

If all bytes of this field are set to (00), it shall mean that no such
application is identified.
.HH "Copyright File Identifier (BP 284-315)"
.C1
This field shall specify a pathname for a file containing
a copyright statement for those
.C2
volumes of the volume set which have a sequence number less than or
equal to the assigned volume sequence number of the volume.

If all bytes of this field are set to (00), it shall mean that no such
file is identified.
.HH "Abstract File Identifier (BP 316-347)"
.C1
This field shall specify a pathname for a file
containing an abstract for those
.C2
volumes of the volume set which have a sequence number less than or
equal to the assigned volume sequence number of the volume.

If all bytes of this field are set to (00), it shall mean that no such
file is identified.
.HH "Reserved (BP 348-511)"
This field shall be reserved for future standardization.
.X1
how much do we need here?
The descriptor need not be 512 bytes long but it might be better if it is.
.X2
.HH Directories
A directory contains zero or more files and subdirectories.
A directory hierarchy shall be a set of directories
descended from a single root directory.

A directory identifying another directory shall be called the parent
directory of the identified directory.
The identified directory shall
be called a subdirectory of the parent directory.
Different
directories may have the same parent directory.
The parent directory of the
root directory shall be the root directory.

A directory shall be a set of directory descriptors.
A directory descriptor is one of
.RS
.DL
Directory Identifier Record (see 3.5.1)
specifying certain attributes of the directory.
.DL
File Identifier Record (see 3.5.2)
specifying a component file or subdirectory of the directory.
.DL
Alias Record (see 3.5.3) specifying an alternative identification for a
component file or subdirectory of the directory.
.RE

A directory shall be recorded as a file containing a
contiguous catenation of directory descriptors subject to
.RS
.DL
The first descriptor of the directory shall be a Directory Identifier Record.
.DL
The descriptors in a directory shall be ordered according to 2.4.2.8
and 3.5.4.
.RE
.HH "Directory Identifier Record"
A Directory Identifier Record shall be recorded in the format
shown in figure 19.
.xz "!Directory Identifier Record"
.Fd figDirectoryIdentifierRecord
.de zz
.Fg "19" "Directory Identifier Record"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-47	Descriptor Character Set	\f(CWcharspec\fP (1.6.2)
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Descriptor Character Set (BP 16-47)"
This field shall specify the characters in the File Identifier Records.
.HH "File Identifier Record"
A File Identifier Record shall be recorded in the format
shown in figure 20.
.xz "!File Identifier Record"
.Fd figFileIdentifierRecord
.de zz
.Fg "20" "File Identifier Record"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-21	File Control Block Location	\f(CWaddress\fP (3.2.2)
22	Length of File Identifier (=L_FI)	\f(CWuint8\fP (1.6.1.1)
23	File Characteristics	\f(CWuint8\fP (1.6.1.1)
24-[L_FI+23]	File Identifier	L_FI f-characters
[L_FI+24]	Padding Field	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "File Control Block Location (BP 16-21)"
The field shall specify the address of the file control block describing the file.
.HH "Length of File Identifier (=L_FI) (BP 22)"
This field shall specify the length, in
bytes, of the File Identifier field.
.HH "File Characteristics (BP 23)"
This field shall specify certain characteristics of the file as
follows.
.ne 5v
Bit 5n
Interpretation
0
Existence: if set to ZERO, shall mean that the existence of the file
shall be made known to the user; if set to ONE, shall mean that the
existence of the file need not be made known to the user.
1
Link: if set to ZERO, shall mean that the File Identifier field of
the File Identifier Record specifies the primary identification
for the file described by the file control block identified by the
.C1
File Control Block Location field of the File Identifier Record.
.C2
if set to ONE,
shall mean that the File Identifier field of the File Identifier
Record specifies an alternative identification for the file described
.C1
by the File Control Block Location field of the File
Identifier Record.
.X1
This bit needs a rationale (I can't think of any).
.X2
.C2
2
Directory: if set to ZERO, shall mean that the file is not a
directory; if set to ONE, shall mean that the file is a directory.
.C1
3
Used: if set to ZERO, it means this File Identifier Record does not refer to a file
and that only the length of File Identifier field is valid.
If set to ONE, all fields are valid.
.R1
This allows a file to be deleted from a directory and only rewriting
the logical block(s) containing the File Identifier Record.
.X1
Except that there is a bug here; the sorting rules need to say something
about such lurking File Identifier Records.
.X2
4-7
Reserved for future standardization.
.C2
.HH "File Identifier (BP 24-[L_FI+23])"
The field shall specify an identification for the file.
.C1
.X1
does this include the terminating nul?
.X2
.C2
.HH "Padding Field (BP [L_FI+24])"
This field shall be present only if necessary to cause the File
Identifier Record to comprise an even number of bytes.
.HH "Alias Record"
An Alias Record shall be recorded in the format
shown in figure 21.
.xz "!Alias Record"
.Fd figAliasRecord
.de zz
.Fg "21" "Alias Record"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16	Length of File Identifier (=L_FI)	\f(CWuint8\fP (1.6.1.1)
17	Length of File Value (=L_FV)	\f(CWuint8\fP (1.6.1.1)
18	File Characteristics	\f(CWuint8\fP (1.6.1.1)
.C1
19	Reserved	1 (00) byte
.C2
20-[L_FI+19]	File Identifier	L_FI f-characters
[L_FI+20]-[L_FV+L_FI+19]	File Value	L_FV f-characters
[L_FV+L_FI+20]	Padding Field	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Length of File Identifier (=L_FI) (BP 16)"
This field shall specify the length, in
bytes, of the File Identifier field.
.HH "Length of File Value (=L_FV) (BP 17)"
This field shall specify the length, in
bytes, of the File Value field.
.HH "File Characteristics (BP 18)"
This field shall specify certain characteristics of the file as
defined in 3.5.2.7.
.HH "Reserved (BP 19)"
Reserved for future standardization.
.HH "File Identifier (BP 20-[L_FI+19])"
The field shall specify an identification for the file.
.HH "File Value (BP [L_FI+20]-[L_FV+L_FI+19])"
The field shall specify an identification for the file referred to
by the File Identifier.
.HH "Padding Field (BP [L_FV+L_FI+20])"
This field shall be present only if necessary to cause the File
Identifier Record to comprise an even number of bytes.
.HH "Order of Directory Entries"
The File Identifier Records and Alias Records
of a directory shall be ordered according to the relative value of
the File Identifier field by the following criteria in descending
order of significance:
1)
in ascending order according to the relative value of File Identifier,
where File Identifiers shall be valued as follows:
.RS
.DL
If two File Identifiers have the same content in all byte
positions, then these two File Identifiers are said to be equal in value.
.DL
If two File Identifiers do not contain the same number of byte
positions, the shorter File Identifier shall be treated as if it were padded
on the right with all padding bytes set to (00) and as if both File
Identifiers contained the identical number of byte positions.

After any padding necessary to treat the File Identifiers as if they
were of equal length, the characters in the corresponding byte
positions, starting with the first position, of the File Identifiers are
compared until a byte position is found that does not contain the same
character in both File Identifiers.  The greater File Identifier is the one that
contains the character with the higher byte value in the coded graphic
character sets used to interpret the File Identifier field of the
directory descriptor.
.RE
2)
in ascending order according to the relative value of File Version
Number, where File Version Numbers shall be valued as follows:
.RS
.DL
If two File Version Numbers have the same content in all
byte positions, then these two File Version Numbers are said to be
equal in value.
.DL
If two File Version Numbers do not contain the same number
of byte positions, the shorter File Version Number shall be treated as
if it were padded on the left with all padding bytes set to (00) and
as if both File Version Numbers contained the identical number of byte
positions.

After any padding necessary to treat the File Version Numbers
as if they were of equal length, the characters in the corresponding
byte positions, starting with the first position, of the File Version
Numbers are compared until a byte position is found that does not
contain the same character in both File Version Numbers.  The greater
File Version Number is the one that contains the character with the
higher code position value in the coded graphic character sets used to
interpret the File Identifier field of the directory descriptor.
.RE
.C1

.X1
The above stuff is somewhat dated.
I believe that as part of the discussion of how to specify file identifiers,
a significant motivation for the current scheme of using a byte stream
was to simplify handling by systems that do not ostensibly support versions.
If so, then the ordering should just be the obvious byte-wise ordering
of the entire file identifier string.
And in this case, it is nontrivial to get at the highest numbered version.
If access to the highest numbered version needs to be efficient, then the
above definition is wrong and 2) needs to compare version numbers after
converting to a number.
.X2
.C2
.HH "Directory Hierarchy Size Restrictions"
.EQ
delim $$
.EN
The length of the pathname for any file or directory in a directory hierarchy
shall not exceed 1023.
.X1
This is sort of right but not rigorous; it assumes a unique pathname for
a file or directory.
.X2

The sum of the number of directories and the number of files
described by the directories of the directory hierarchy shall not exceed
$2 sup 32 - 1$.
.EQ
delim off
.EN
.HH Files
A file shall be specified by a File Control Block.
The File Control Block specifies the attributes of a file and the location
of the recorded data of a file.
Some of the attributes are contained in the File Control Block itself;
the remainder shall be recorded as Extended Attributes.

The data of a file shall be specified as an ordered sequence of extents
(see \f(CWshort_ar\fP (1.6.5.1) and 3.2.3.1).
The extents may be unrecorded.
The extents may be located on different partitions and on different volumes.

Except where specified in this standard,
neither the interpretation of the information in a file
nor the structure of the information in a file is specified by this standard.
.R1
The main motivation for this scheme is efficient access to file data.
With current technology trends, this almost mandates extent-based schemes.
This scheme also allows reserving a contiguous extent for file data
and then recording it with an arbitrary sequence of I/O requests.
.R2
.HH "Direct Entry"
The Direct Entry shall be recorded in the format shown in figure 22.
.xz "!Direct Entry"
.Fd figDirectEntry
.de zz
.Fg "22" "Direct Entry"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Recorded Direct Entry Number	\f(CWuint32\fP (1.6.1.5)
20	Direct Entry Number	\f(CWuint8\fP (1.6.1.1)
21	Indirect Entry Number	\f(CWuint8\fP (1.6.1.1)
22	Flags	\f(CWuint8\fP (1.6.1.1)
23	File Type	\f(CWuint8\fP (1.6.1.1)
.C1
24-27	Uid	\f(CWuint32\fP (1.6.1.5)
.C2
.C1
28-31	Gid	\f(CWuint32\fP (1.6.1.5)
.C2
32-33	File Link Count	\f(CWuint16\fP (1.6.1.3)
34	Record Format	\f(CWuint8\fP (1.6.1.1)
35	Record Attributes	\f(CWuint8\fP (1.6.1.1)
36-37	Record Length	\f(CWuint16\fP (1.6.1.3)
38-45	Data Length	\f(CWuint64\fP (1.6.1.6)
46-53	Logical Blocks Recorded	\f(CWuint64\fP (1.6.1.6)
54-65	Access Time	\f(CWtimestamp\fP (1.6.3.9)
66-77	Modification Time	\f(CWtimestamp\fP (1.6.3.9)
78-89	Change Time	\f(CWtimestamp\fP (1.6.3.9)
90-91	Permissions	\f(CWuint16\fP (1.6.1.3)
92-97	Extended Attribute File Control Block Location	\f(CWaddress\fP (3.2.2)
98-129	Application Identifier	32 a-characters
130-135	Application Use File Control Block Location	\f(CWaddress\fP (3.2.2)
136-139	Generation	\f(CWuint32\fP (1.6.1.5)
140-171	Implementation Identifier	32 a-characters
172-177	Implementation Use File Control Block Location	\f(CWaddress\fP (3.2.2)
178	Length of Implementation Use (=N_IU)	\f(CWuint8\fP (1.6.1.1)
179-210	Escape Sequences	32 bytes
211-212	Number of Allocation Records (=N_AR)	\f(CWuint16\fP (1.6.1.3)
213-[N_AR\(mu16+212]	Allocation Records	N_AR 3.2.3.1
[N_AR\(mu16+213]-[N_IU+N_AR\(mu16+212]	Implementation Use	N_IU bytes
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Recorded Direct Entry Number (BP 16-19)"
This field specifies the number of Direct Entries recorded in this File Control Block hierarchy
prior to this entry.
.HH "Direct Entry Number (BP 20)"
This field specifies the number of Direct Entries in this File Control Block.
.HH "Indirect Entry Number (BP 21)"
This field specifies the number of Indirect Entries in this File Control Block.
.HH "Flags (BP 22)"
This field shall specify recording information as specified in 2.4.2.8.
.HH "File Type (BP 23)"
This field shall specify the file type as specified in 2.4.2.9.
.HH "Uid (BP 24-27)"
.C1
This field shall specify the User ID of the file's owner.
.C2
.HH "Gid (BP 28-31)"
.C1
This field shall specify the Group ID of the file's owner.
.C2
.HH "File Link Count (BP 32-33)"
This field shall specify the
number of File Identifier Records identifying this file control block.
.X1
Not sure if I believe this.
What if I copy a subtree of files to WORM to send to someone
and don't get all the links?
does that mean the link count changes for the files i send?
.X2
.HH "Record Format (BP 34)"
This field shall specify the format of the information in the file.
.ne 5v
Number 8n
Interpretation
0
shall mean that the structure of the information recorded in the
file is not specified by this field
1
shall mean that the information in the file is a
sequence of fixed-length records (see 3.6.2.1)
2
shall mean that the information in the file is a
sequence of variable-length records (see 3.6.2.2)
3
shall mean that the information in the file is a
sequence of variable-length records (see 3.6.2.2)
4
shall mean that the information in the file is a
sequence of stream-print records (see 3.6.2.3)
5
shall mean that the information in the file is
a sequence of stream-LF records (see 3.6.2.4)
6
shall mean that the information in the file is
a sequence of stream-CR records (see 3.6.2.5)
7-255
reserved for future standardization

If the file is not a regular file, the Record Format field shall contain zero.
.HH "Record Attributes (BP 35)"
This field shall specify the
processing of the records in a file when they are displayed on a
character-imaging device.
.C1
If the Record Format field contains zero then the contents of the Record Attribute
field shall be undefined.
.C2
.ne 5v
Number 8n
Interpretation
0
shall mean that each record shall be preceded by a LINE FEED
character and followed by a CARRIAGE RETURN character
1
shall mean that the first byte of a record shall be interpreted
as specified in ISO 1539 for vertical spacing
2
shall mean that the record contains the necessary control information
for the imaging device
3-255
reserved for future standardization.
.HH "Record Length (BP 36-37)"
If the Record Format field contains the number 0, the Record Length
field shall contain zero.

If the Record Format field contains the number 1, the Record Length
field shall specify the length, in bytes, of each record in the file.

If the Record Format field contains the number 2, 3, 4, 5 or 6, the
Record Length field shall specify the maximum length, in bytes, of a
record in the file.
.HH "Data Length (BP 38-45)"
The file size in bytes.
.HH "Logical Blocks Recorded (BP 46-53)"
.C1
The number of logical blocks that have been recorded.
.C2
.HH "Access Time (BP 54-65)"
This field shall specify the most recent time of access to this file
at the time this Direct Entry was recorded.
If all eight numbers in this field are zero, it shall mean
that the date and time are not specified.
.R1
This departs from ISO 9945-1 semantics a little in order to prevent
unnecessary updates (for WORM) on read accesses.
.R2
.HH "Modification Time (BP 66-77)"
This field shall specify the most recent time data was recorded for this file.
If all eight numbers in this field are zero, it shall mean
that the date and time are not specified.
.HH "Change Time (BP 78-89)"
This field shall specify the most recent time data was recorded for this file
or fields in this Direct Entry were changed.
If all eight numbers in this field are zero, it shall mean
that the date and time are not specified.
.HH "Permissions (BP 90-91)"
.C1
This field shall specify access permissions for certain classes of
users as follows:
.RS
.DL
If the user's User ID is the same as the Uid field, then bits 6\-8 shall apply.
.DL
Otherwise,
if the user's Group ID is ithe same as the Gid field, then bits 3\-5 shall apply.
.DL
Otherwise, bits 0\-2 shall apply.
.RE
.ne 5v
Bit 7n
Interpretation
0
Other: If set to ZERO, shall mean that the user may not execute the file;
If set to ONE; shall mean that the user may execute the file.
1
Other: If set to ZERO, shall mean that the user may not write the file;
If set to ONE; shall mean that the user may write the file.
2
Other: If set to ZERO, shall mean that the user may not read the file;
If set to ONE; shall mean that the user may read the file.
3
Group: If set to ZERO, shall mean that the user may not execute the file;
If set to ONE; shall mean that the user may execute the file.
4
Group: If set to ZERO, shall mean that the user may not write the file;
If set to ONE; shall mean that the user may write the file.
5
Group: If set to ZERO, shall mean that the user may not read the file;
If set to ONE; shall mean that the user may read the file.
6
Owner: If set to ZERO, shall mean that the user may not execute the file;
If set to ONE; shall mean that the user may execute the file.
7
Owner: If set to ZERO, shall mean that the user may not write the file;
If set to ONE; shall mean that the user may write the file.
8
Owner: If set to ZERO, shall mean that the user may not read the file;
If set to ONE; shall mean that the user may read the file.
9
System: If set to ZERO, shall mean that the file is not a system file;
If set to ONE; shall mean that the file is a system file.
10
Archive: MS-DOS archive bit (20).
.X1
I don't know what the semantics are.
.X2
11\-15
Reserved: Shall be set to ZERO.
.R1
MS-DOS actually requires 4 bits: readonly, hidden, system and archive.
System and archive are supported directly;
hidden is in the File Identifier Record
and readonly can be deduced by the absence of write permissions
but we need to clarify that.
.R2
.C2
.HH "Extended Attribute File Control Block Location (BP 92-97)"
.C1
The field shall specify the address of the file control block describing the extended
attribute file.
.C2
.HH "Application Identifier (BP 98-129)"
This field shall specify an identification of the specification of how
the data are recorded in the file.
.C1
.X1
I would reword this if i knew what it meant.
.X2
.C2

If all bytes of this field are set to (00), it shall mean that no such
application is identified.
.HH "Application Use File Control Block Location (BP 130-135)"
.C1
The field shall specify the address where the file control block describing the
.C2
application use file is recorded.
.HH "Generation (BP 136-139)"
.C1
This number shall be one for the first revision of a file and incremented by
one when the user so specifies.
.R1
This field allows the user to label sequences of revisions of a file
with a (monotonic increasing) numeric tag.
It has almost the same semantics as the version part of the file name
but has very different syntax.
.R2
.C2
.HH "Implementation Identifier (BP 140-171)"
This field shall specify an identification of an implementation which
can recognize and act upon the content of the Implementation Use field
.C1
and the extent identified by the Implementation Use File Control Block Location
field.
.C2
If all bytes of this field are set to (00), it shall mean that no such
implementation is identified.
.HH "Implementation Use File Control Block Location (BP 172-177)"
The field shall specify the location where the file control block describing the
implementation use file is recorded.
.HH "Length of Implementation Use (=N_IU) (BP 178)"
This field shall specify the length, in
bytes, of the Implementation Use field.
.HH "Escape Sequences (BP 179-210)"
This field shall specify one or more escape sequences according to ISO
2022 that designate and implicitly invoke the coded character sets to
be used in an 8-bit environment according to ISO 2022 to interpret the
content of the file (see 1.6.2.5).
.HH "Number of Allocation Records (=N_AR) (BP 211-212)"
This field shall specify the number (N_AR) of allocation records
recorded in this Direct Entry.
.HH "Allocation Records (BP 213-[N_AR\(mu16+212])"
.C1
This field shall be N_AR allocation records.
The type of allocation record shall be specified by the Flags field.
.X1
The size calculation uses long allocation records; this is sort of wrong
but I am unsure how to present the right answer.
.X2
.C2
.HH "Implementation Use (BP [N_AR\(mu16+213]-[N_IU+N_AR\(mu16+212])"
This field shall be reserved for implementation use.
Its content is not specified by this standard.
.HH "Record Structure"
The information in a file may be organized as a set of records
according to this clause.

A record shall be a sequence of bytes treated as a unit of information.
The length of a record shall be the number of bytes in the record.
A record shall be one of the following types:
.RS
.DL
fixed-length
.DL
variable-length
.DL
stream-print
.DL
stream-LF
.DL
stream-CR
.RE

All records in a file shall be of the same type.
Each record is recorded in a Measured Data Unit (MDU).
The file's contents are a contiguous catenation of one or more MDUs.
.HH "Fixed-Length Records"
All the records in a file containing fixed-length records must be of equal length.
The MDU containing a fixed-length record shall consist of the record,
immediately followed by a (00) byte if necessary to give the MDU an even length.
.HH "Variable-Length Records"
An MDU containing a variable-length record shall consist of either
.RS
.DL
A Record Control Word (RCW) immediately followed by the
variable-length record, immediately followed by a (00) byte if
necessary to give the MDU an even length.
.DL
An RCW.
.C1
.X1
Why do we need this case?
.X2
.C2
.RE
An RCW shall specify a \f(CWint16\fP (1.6.1.4) as follows:
.ne 5v
Number 12n
Interpretation
\-1
shall mean that the RCW is the final RCW of the logical block in
which the RCW is recorded
0\-32767
shall mean that the RCW specifies the length of the record
"any other"
reserved for future standardization value

.X1
The meaning of \-1 is baffling to me; how can anyone care about this?
This is probably a dreg.
.X2
The RCW shall be recorded as an
\f(CWint16\fP (1.6.1.4), if the value in the Record Format field of the Direct Entry
associated with the file is 2, or
\f(CWint16MSB\fP (1.6.1.4.1), if the value in the Record Format field of the
Direct Entry associated with the file is 3.

A maximum record length in the range 1 to 32767 shall be assigned for a file.
The length of any record in the file shall not exceed this value.
The minimum length of a variable-length record shall be 0.
.X1
The last draft had wording which implied that maybe you could mix
any of the four variable-length record types together in the same file.
I have followed the strict wording that says ``one type, one file''.
.X2
.HH "Stream-print Records"
An MDU containing a stream-print record shall be a sequence of
zero or more (00) bytes immediately followed by one of the following
sequences:
.RS
.DL
the stream-print record immediately followed by the two bytes (13) (10)
.DL
the stream-print record with a (10) byte as the final byte of the
stream-print record
.DL
the stream-print record with a (11) byte as the final byte of the
stream-print record
.DL
the stream-print record with a (12) byte as the final byte of the
stream-print record.
.RE

A maximum record length in the range 1 to 32767 shall be assigned for a file.
The length of any record in the file shall not exceed this value.
The first byte of a stream-print record shall not be a (00) byte.
.HH "Stream-LF Records"
An MDU containing a stream-LF record shall consist
of the stream-LF record, immediately followed by a (10) byte.

A maximum record length in the range 1 to 32767 shall be assigned for a file.
The length of any record in the file shall not exceed this value.
The minimum length of a stream-LF record shall be 0.
.HH "Stream-CR Records"
An MDU containing a stream-CR record shall consist
of the stream-CR record, immediately followed by a (13) byte.

A maximum record length in the range 1 to 32767 shall be assigned for a file.
The length of any record in the file shall not exceed this value.
The minimum length of a stream-CR record shall be 0.
.HH "Extended Attributes"
Extended attributes shall be stored as a file.
The file consists of an Extended Attribute Header Descriptor
followed by zero or more Extended Attributes.

The extended attributes are divided into three classes:
those for System use, those for Implementation use, and those for Application use.
The System class starts with the first extended attribute and is terminated
by the start of the Implementation class.
The Implementation class is terminated by the start of the Application class.
The Application class is terminated by the end of the file.
The start of the Implementation and Application classes shall be specified
in the Extended Attribute Header Descriptor.

Attribute types 1-22 are defined below.
Attribute types 23-999 are reserved for future standardization.
Attribute types 1000 and above may be registered.
.HH "Extended Attribute Header Descriptor"
The Extended Attribute Header Descriptor shall be recorded in the format shown
in figure 23.
.X1
This could be done with lengths rather than locations
.X2
.xz "!Extended Attribute Header Descriptor"
.Fd figExtendedAttributeHeaderDescriptor
.de zz
.Fg "23" "Extended Attribute Header Descriptor"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-3	Implementation Attributes Location	\f(CWuint32\fP (1.6.1.5)
4-7	Application Attributes Location	\f(CWuint32\fP (1.6.1.5)
_
.TE
.zz
.KE
.2C
.HH "Implementation Attributes Location (BP 0-3)"
This field shall specify the start of the Implementation extended attributes
relative to the end of the Extended Attribute Header Descriptor.
.HH "Application Attributes Location (BP 4-7)"
This field shall specify the start of the Application extended attributes
relative to the end of the Extended Attribute Header Descriptor.
.HH "Extended Attribute Format"
An Extended Attribute shall be recorded in the format shown in figure
24.
.xz "!Extended Attribute"
.Fd figExtendedAttribute
.de zz
.Fg "24" "Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5)
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3)
22-25	Data Length (=D_L)	\f(CWuint32\fP (1.6.1.5)
26-[D_L+25]	Attribute Data	D_L bytes
[D_L+26]	Padding	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify the type of the extended attribute.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify the subtype of the extended attribute.
.C1
.X1
we might want to make this 32 bits for alignment reasons
.X2
.C2
.HH "Data Length (=D_L) (BP 22-25)"
This field shall specify the length of attribute data.
.HH "Attribute Data (BP 26-[D_L+25])"
The interpretation of this field shall be dependent on the Attribute Type field.
.HH "Padding (BP [D_L+26])"
An extended attribute shall be extended by a (00) byte if necessary
to make the total length even.
.X1
why do we pad to even lengths?
it seems padding to a multiple of 4 would not hurt and would suit
all the 32 bit RISC machines.
The 64 bit machines, like the Cray, need padding to a multiple of 8.
.X2
.HH "Date Extended Attributes"
The date extended attributes have a common format.
The Attribute Subtype shall be 1.
The Data Length shall be 10.
The Attribute Data shall be a \f(CWtimestamp\fP (1.6.3.9) with the following meaning:
.ne 5v
Attribute 8n
Interpretation
Type
1
Information Creation:
This field shall specify the date and time at which the entity
described by the Direct Entry was last created.
2
Information Modification:
This field shall specify the date and time at which the entity
described by the Direct Entry was last modified.
3
Information Expiration:
This field shall specify the date and time at which the entity
described by the Direct Entry may no longer be used.
4
Information Effective:
This field shall specify the date and time at which the entity
described by the Direct Entry may be used.
5
File Creation:
This field shall specify the date and time at which the entity
described by the Direct Entry was last created.
6
File Modification:
This field shall specify the date and time at which the entity
described by the Direct Entry was last modified.
7
File Expiration:
This field shall specify the date and time at which the entity
described by the Direct Entry may no longer be used.
8
File Effective:
This field shall specify the date and time at which the entity
described by the Direct Entry may be used.
9
File Access:
This field shall specify the date and time at which the entity
described by the Direct Entry was last accessed.
10
File Backup:
This field shall specify the date and time at which the entity
described by the Direct Entry was last backed up.
11
File Attribute:
This field shall specify the date and time at which the attributes of
the entity described by the Direct Entry were last modified.
.HH "Associated File"
An associated file has a relationship not specified by this standard
.C1
to the file with which it is associated.
.C2
An associated file shall be recorded in the format shown in
25.
.xz "!Associated File Extended Attribute"
.Fd figAssociatedFileExtendedAttribute
.de zz
.Fg "25" "Associated File Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 12
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	Data Length	\f(CWuint32\fP (1.6.1.5) = 10
26-29	Associated File Type	\f(CWuint32\fP (1.6.1.5)
30-35	File Control Block of Associated File	\f(CWaddress\fP (3.2.2)
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.C1
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.C2
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 12.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "Data Length (BP 22-25)"
This field shall specify 10.
.HH "Associated File Type (BP 26-29)"
This field shall specify a registered Associated File Type.
.HH "File Control Block of Associated File (BP 30-35)"
This field shall specify the location of the File Control Block for the associated file.
.HH "Data compression"
This field shall specify an identification of the specification of the
data compression algorithm used to record the data in the file.
A data compression identifier shall be recorded in the format shown in
26.
.X1
The previous draft supported a file specification.
There were no obvious semantics for this file so I dropped it.
.X2
.xz "!Data Compression Extended Attribute"
.Fd figDataCompressionExtendedAttribute
.de zz
.Fg "26" "Data Compression Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 13
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	Compression Identifier Length (=CI_L)	\f(CWuint32\fP (1.6.1.5)
26-[CI_L+25]	Compression Identifier	CI_L a-characters
[CI_L+26]	Padding	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 13.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "Compression Identifier Length (=CI_L) (BP 22-25)"
.C1
This field shall specify the length of the Compression Identifier.
.C2
.HH "Compression Identifier (BP 26-[CI_L+25])"
This field shall specify an identification of a compression method.
.X1
There is putatively a register of such things being setup within ANSI.
.X2
.HH "Padding (BP [CI_L+26])"
An extended attribute shall be extended by a (00) byte if necessary
to make the total length even.
.HH "Protection"
This extended attribute specifies fields that can be used to
support the file access protection scheme of ISO 9660.
It shall be recorded in the format shown in figure 27.
.xz "!Protection Extended Attribute"
.Fd figProtectionExtendedAttribute
.de zz
.Fg "27" "Protection Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 14
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	Data Length	\f(CWuint32\fP (1.6.1.5) = 10
26-29	Owner Identification	\f(CWuint32\fP (1.6.1.5)
30-33	Group Identification	\f(CWuint32\fP (1.6.1.5)
34-35	Permission	\f(CWuint16\fP (1.6.1.3)
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 14.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "Data Length (BP 22-25)"
This field shall specify 10.
.HH "Owner Identification (BP 26-29)"
This field shall specify as a 16-bit number an identification of the
file owner who is a member of the group identified by the Group
Identification field of the Extended Attribute Record.
.X1
I do not know why we need 32 bits for a 16 bit number
.X2

If the number in this field is 0, this shall indicate that there is no
owner identification specified for the file.  In this case, the Group
Identification field shall contain zero.
.HH "Group Identification (BP 30-33)"
This field shall specify as a 16-bit number an identification of the
group of which the file owner is a member.
.X1
I do not know why we need 32 bits for a 16 bit number
.X2

Certain values, from 1 to a value subject to agreement
between the data preparer and receiving system, shall identify the
group as belonging to the class of user referred to as System.

If the number in this field is 0, this shall indicate that there is no
group identification specified for the file.  In this case, the Owner
Identification field shall contain zero.
.HH "Permission (BP 34-35)"
The bits of this field shall be numbered from 0 to 15 starting
with the least significant bit. 

Bits 0 to 3 may be ignored in interchange.
If requested by the owner, bits 4 to 7 may be ignored in interchange.

This field shall specify access permissions for certain classes of
users as follows.
.ne 5v
Bit 5n
Interpretation
0
If set to ZERO, shall mean that an owner who is a member of a group
of the System class of user may read the file;
If set to ONE; shall mean that an owner who is a member of a
group of the System class of user may not read the file.
1
Shall be set to ONE
2
If set to ZERO, shall mean that an owner who is a member
of a group of the System class of user may execute the file;
If set to ONE, shall mean that an owner who is a member of a
group of the System class of user may not execute the file.
3
Shall be set to ONE.
4
If set to ZERO, shall mean that the owner may read the file;
if set to ONE, shall mean that owner may not read the file.
5
Shall be set to ONE
6
if set to ZERO, shall mean that the owner may
execute the file;
if set to ONE, shall mean that owner may not execute
the file.
7
shall be set to ONE.
8
If set to ZERO, shall mean that
any user who is a member of the group specified by the Group
identification field may read the file;
if set to ONE, shall mean that of the users who are member of
the group specified by the Group Identification field, only the owner
may read the file.
9
Shall be set to ONE
10
if set to ZERO, shall
mean that any user who is a member of the group specified by the Group
Identification field may execute the file.
if set to ONE, shall mean that of the users who are members of
the group specified by the Group Identification field, only the owner
may execute the file.
11
Shall be set to ONE.
12
if set to ZERO, shall
mean that any user may read the file;
if set to ONE, shall mean that a user not a member of the
group specified by the Group Identification field may not read the
file.
13
Shall be set to ONE.
14
if set to ZERO, shall mean that any
user may execute the file;
if set to ONE, shall mean that a user not a member of the
group specified by the Group Identification field may not execute the
file.
15
Shall be set to ONE.

.C1
.X1
This may be picky but how I am supposed to interpret bit 0=ONE and bit 4=ZERO
if I am the owner and in the System class of user.
This is also a bug in ISO 9660.
.X2
.C2
.HH "Application Area"
The Application Area Extended Attribute shall be recorded in the format
shown in figure 28.
.xz "!Application Area Extended Attribute"
.Fd figApplicationAreaExtendedAttribute
.de zz
.Fg "28" "Application Area Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 15
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	Data Length (=D_L)	\f(CWuint32\fP (1.6.1.5)
26-29	Application Identifier	\f(CWuint32\fP (1.6.1.5)
30-[D_L+29]	Application Data	D_L a-characters
[D_L+30]	Padding	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 15.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "Data Length (=D_L) (BP 22-25)"
This field shall specify the number of bytes of Application Data plus 4.
.HH "Application Identifier (BP 26-29)"
This field shall specify an Application Identifier.
There shall be a registration authority for Application Identifiers.
.X1
I am unsure if we have agreed on the need for a registered identifier
.X2
.HH "Application Data (BP 30-[D_L+29])"
This standard does not specify the contents of this field.
.HH "Padding (BP [D_L+30])"
An extended attribute shall be extended by a (00) byte if necessary
to make the total length even.
.HH "Implementation Area"
The Implementation Area Extended Attribute shall be recorded in the format shown in
29.
.xz "!Implementation Area Extended Attribute"
.Fd figImplementationAreaExtendedAttribute
.de zz
.Fg "29" "Implementation Area Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 16
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	Data Length (=D_L)	\f(CWuint32\fP (1.6.1.5)
26-29	Implementation Identifier	\f(CWuint32\fP (1.6.1.5)
30-[D_L+29]	Implementation Data	D_L a-characters
[D_L+30]	Padding	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 16.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "Data Length (=D_L) (BP 22-25)"
This field shall specify the number of bytes of Implementation Data plus 4.
.HH "Implementation Identifier (BP 26-29)"
This field shall specify an Implementation Identifier.
There shall be a registration authority for Implementation Identifiers.
.X1
I am unsure if we have agreed on the need for a registered identifier
.X2
.HH "Implementation Data (BP 30-[D_L+29])"
This field shall be reserved for implementation use.
Its content is not specified by this standard.
.HH "Padding (BP [D_L+30])"
An extended attribute shall be extended by a (00) byte if necessary
to make the total length even.
.HH "Escape Sequences Segment"
The Escape Sequences Segment Extended Attribute shall be recorded in the format
shown in figure 30.
.xz "!Escape Sequences Segment Extended Attribute"
.Fd figEscapeSequencesSegmentExtendedAttribute
.de zz
.Fg "30" "Escape Sequences Segment Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 17
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	Escape Sequences Length (=ES_L)	\f(CWuint32\fP (1.6.1.5)
26-[ES_L+25]	Escape Sequences	ES_L bytes
[ES_L+26]	Padding	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 17.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "Escape Sequences Length (=ES_L) (BP 22-25)"
This field shall specify the length in bytes of the Escape Sequences field.
.HH "Escape Sequences (BP 26-[ES_L+25])"
This field shall specify ISO 1022 style escape sequences.
.X1
I am unclear of the use of this attribute or the object to which it applies.
.X2
.HH "Padding (BP [ES_L+26])"
An extended attribute shall be extended by a (00) byte if necessary
to make the total length even.
.HH "File Abstract"
The File Abstract Extended Attribute shall be recorded in the format
shown in figure 31.
.xz "!File Abstract Extended Attribute"
.Fd figFileAbstractExtendedAttribute
.de zz
.Fg "31" "File Abstract Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 18
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	File Abstract Length (=FA_L)	\f(CWuint32\fP (1.6.1.5)
26-[FA_L+25]	File Abstract	FA_L bytes
[FA_L+26]	Padding	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 18.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "File Abstract Length (=FA_L) (BP 22-25)"
This field shall specify the length of the File Abstract field.
.HH "File Abstract (BP 26-[FA_L+25])"
This field shall specify an abstract for this file.
.X1
don't know type of file abstract
.X2
.HH "Padding (BP [FA_L+26])"
An extended attribute shall be extended by a (00) byte if necessary
to make the total length even.
.HH "Action History"
The Action History Extended Attribute shall be recorded in the format
shown in figure 32.
.xz "!Action History Extended Attribute"
.Fd figActionHistoryExtendedAttribute
.de zz
.Fg "32" "Action History Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 19
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	History Data Length (=HFI_L)	\f(CWuint32\fP (1.6.1.5)
26-29	History Format Identifier	\f(CWuint32\fP (1.6.1.5)
30-[HFI_L+29]	Action History Data	HFI_L bytes
[HFI_L+30]	Padding	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 19.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "History Data Length (=HFI_L) (BP 22-25)"
This field shall specify the sum of the number of bytes of Action History Data
and 4.
.HH "History Format Identifier (BP 26-29)"
This field shall specify an History Format Identifier.
There shall be a registration authority for History Format Identifiers.
.HH "Action History Data (BP 30-[HFI_L+29])"
This standard does not specify the contents of this field.
.HH "Padding (BP [HFI_L+30])"
An extended attribute shall be extended by a (00) byte if necessary
to make the total length even.
.HH "Icon"
The Icon Extended Attribute shall be recorded in the format
shown in figure 33.
.xz "!Icon Extended Attribute"
.Fd figIconExtendedAttribute
.de zz
.Fg "33" "Icon Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 20
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	Icon Data Length (=ID_L)	\f(CWuint32\fP (1.6.1.5)
26-29	Icon Identifier	\f(CWuint32\fP (1.6.1.5)
30-[ID_L+29]	Icon Data	ID_L bytes
[ID_L+30]	Padding	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 20.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "Icon Data Length (=ID_L) (BP 22-25)"
This field shall specify the number of bytes of Icon Data plus 4.
.HH "Icon Identifier (BP 26-29)"
This field shall specify an Icon Identifier.
There shall be a registration authority for Icon Identifiers.
.HH "Icon Data (BP 30-[ID_L+29])"
This standard does not specify the contents of this field.
.HH "Padding (BP [ID_L+30])"
An extended attribute shall be extended by a (00) byte if necessary
to make the total length even.
.HH "File Type"
The File Type Extended Attribute shall be recorded in the format
shown in figure 34.
.xz "!File Type Extended Attribute"
.Fd figFileTypeExtendedAttribute
.de zz
.Fg "34" "File Type Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 21
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	Data Length	\f(CWuint32\fP (1.6.1.5) = 4
26-29	File Type	\f(CWuint32\fP (1.6.1.5)
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 21.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "Data Length (BP 22-25)"
This field shall specify 4.
.HH "File Type (BP 26-29)"
This field shall specify a File Type.
There shall be a registration authority for File Types.
.HH "Environment Type"
The Environment Type Extended Attribute shall be recorded in the format
shown in figure 35.
.xz "!Environment Type Extended Attribute"
.Fd figEnvironmentTypeExtendedAttribute
.de zz
.Fg "35" "Environment Type Extended Attribute"
..
.1C
.KF 
.SP 1
.TS
center;
l l l.
_
BP	Field name	Contents
_
0-1	Descriptor Checksum	\f(CWuint16\fP (1.6.1.3)
2-3	Descriptor Checksum Length	\f(CWuint16\fP (1.6.1.3)
.C1
4-7	Descriptor Version	\f(CWuint32\fP (1.6.1.5)
.C2
8-15	Descriptor Tag	\f(CWuint64\fP (1.6.1.6)
16-19	Attribute Type	\f(CWuint32\fP (1.6.1.5) = 22
20-21	Attribute Subtype	\f(CWuint16\fP (1.6.1.3) = 1
22-25	Environment Data Length (=ED_L)	\f(CWuint32\fP (1.6.1.5)
26-29	Environment Identifier	\f(CWuint32\fP (1.6.1.5)
30-[ED_L+29]	Environment Data	ED_L bytes
[ED_L+30]	Padding	1 (00) byte
_
.TE
.zz
.KE
.2C
.HH "Descriptor Checksum (BP 0-1)"
This field shall specify the checksum (see 1.6.4) of Descriptor Checksum Length bytes
starting at the first byte of the Descriptor Checksum Length field.
.HH "Descriptor Checksum Length (BP 2-3)"
This field specifies how many bytes were used
in calculating the Descriptor Checksum.
.HH "Descriptor Version (BP 4-7)"
This field shall specify the version of this Descriptor.
The value 1 shall indicate the structure of this standard.
.HH "Descriptor Tag (BP 8-15)"
This field shall specify (DEADBEEF).
.HH "Attribute Type (BP 16-19)"
This field shall specify 22.
.HH "Attribute Subtype (BP 20-21)"
This field shall specify 1.
.HH "Environment Data Length (=ED_L) (BP 22-25)"
This field shall specify the sum of the number of bytes of Environment Data and 4.
.HH "Environment Identifier (BP 26-29)"
This field shall specify an Environment Identifier.
There shall be a registration authority for Environment Identifiers.
.HH "Environment Data (BP 30-[ED_L+29])"
This standard does not specify the contents of this field.
.HH "Padding (BP [ED_L+30])"
An extended attribute shall be extended by a (00) byte if necessary
to make the total length even.
.BP
.HH Interchange
.HH "Levels of Medium Interchange"
This standard specifies six nested levels of medium interchange.
.HH "Level 1"
At level 1, the following restrictions shall apply:
.RS
.DL 
.C1
each file shall be recorded as a single extent;
.DL
each \f(CWcharspec\fP (1.6.2) shall have its Character Set Type field set to 0;
.DL
a File Identifier shall contain up to and including 8 f-characters
followed by an optional FULL STOP.
If a FULL STOP is in the file identifier, it may be followed by no
more than 3 f-characters.
.C2
.DL
a File Identifier shall not contain more than one FULL STOP;
.DL
a File Version Number shall consist of one digit of the
f-characters, representing a number from 1 to 9;
.DL
a Directory Identifier shall not contain more than eight
f-characters;
.DL
a Director Identifier shall not contain any FULL STOP characters;
.DL
the file specification length of each regular file shall not exceed
255;
.DL
the path identifier length of each directory shall not exceed 255.
.RE
.HH "Level 2"
At Level 2, the following restrictions shall apply:
.RS
.DL
all file sections of a file shall be recorded on the same volume;
.C1
.DL
each \f(CWcharspec\fP (1.6.2) shall have its Character Set Type field set to one of 0, 1.
.C2
.RE
.HH "Level 3"
At level 3, the following restrictions shall apply:
.RS
.C1
.DL
each \f(CWcharspec\fP (1.6.2) shall have its Character Set Type field set to one of 0, 1, 2.
.C2
.RE
.HH "Level 4"
At Level 4, the following restrictions shall apply:
.RS
.C1
.DL
each \f(CWcharspec\fP (1.6.2) shall have its Character Set Type field set to one of 0, 1, 2, 3.
.C2
.RE
.HH "Level 5"
At Level 5, the following restrictions shall apply:
.RS
.C1
.DL
each \f(CWcharspec\fP (1.6.2) shall have bit 5 of its Character Set Type field set to 0.
.C2
.RE
.HH "Level 6"
At Level 6, no restrictions shall apply.
.HH "Requirements for the Description of Systems"
This standard specifies that certain information shall be communicated
between a user and an implementation
(see 4.3 and 4.4).

An information processing system that conforms to this standard shall
be the subject of a description which identifies the means by which
the user may supply such information, or may obtain it when it is made
available, as specified in this standard.
.HH "Requirements for an Originating System"
.HH "General"
The implementation shall be capable of recording a set of files, and
all descriptors as specified in 4.2,
on a volume set in accordance with
one of the medium interchange levels specified in this standard.
The implementation shall be capable of determining the largest addressable sector
number of the medium.
.HH "Files"
The implementation shall obtain from the user the information that
constitutes the set of files to be recorded.

If the implementation allows the user to specify that the information
constituting a file is to be interpreted according to 3.6.2, the
implementation shall obtain from the user the length of each record in
the file.
.de xx
.br
\(en
..
.de xy
.sp .2i
.in 1n
..
.HH "Descriptors"
.HH "Mandatory Access By User"
The implementation shall allow the user to supply the information that
is to be recorded in each of the descriptor fields listed below, and
shall supply the information for a field if the user does not supply
it.
\&
.xy
Volume Header Record
\&
.xx
Volume Descriptor Set File Control Block Location
.xx
Partition Descriptor Set File Control Block Location
.xy
Volume Header Pointer Record
\&
.xx
Successor Volume Header Sequence Location
.xy
Primary Volume Descriptor
\&
.xx
Volume Identifier
.xx
Volume Set Identifier
.xy
Partition Geometry Descriptor
\&
.xx
Partition Starting Location
.xx
Partition Length
.xx
Unallocated Space Table
.xx
Access Table
.xy
Partition Implementation Use Descriptor
\&
.xx
Descriptor Character Set
.xx
Partition Identifier
.xx
Implementation Identifier
.xx
Implementation Use
.xy
File Set Descriptor
\&
.xx
Descriptor Character Set
.xx
Logical Block Size
.xx
Logical Volume Sequence Number
.xx
Logical Volume Identifier
.xx
File Set Character Set
.xx
Application Identifier
.xx
Copyright File Identifier
.xx
Abstract File Identifier
.xy
Directory Identifier Record
\&
.xx
Descriptor Character Set
.xy
File Identifier Record
\&
.xx
File Characteristics
.xx
File Identifier
.xy
Alias Record
\&
.xx
File Characteristics
.xx
File Identifier
.xx
File Value
.xy
Direct Entry
\&
.xx
Uid
.xx
Gid
.xx
File Link Count
.xx
Permissions
.xx
Generation
.xx
Implementation Identifier
.xx
Implementation Use File Control Block Location
.xx
Length of Implementation Use
.xx
Escape Sequences
.HH "Maximal Access By User"
If the implementation permits the user to supply the information that
is to be recorded in any of the descriptor fields listed below, then
the implementation shall record such information as supplied by the
user, and shall supply the information for a field if the user does
not supply it.
\&
.xy
Volume Header Record
\&
.xx
Predecessor Volume Header Sequence Location
.xx
Unallocated Space Table Location
.xx
Replacement Sector Record Location
.xx
Implementation Use
.xy
Primary Volume Descriptor
\&
.xx
Volume Sequence Number
.xx
Descriptor Character Set
.xy
Implementation Use Volume Descriptor
\&
.xx
Descriptor Character Set
.xy
Replacement Sector Record
\&
.xx
Extent Length
.xx
Number of Sector Addresses
.xx
Next Replacement Sector Record Location
.xx
Previous Replacement Sector Record Location
.xx
Next Replacement Sector Record Extent Location
.xx
Previous Replacement Sector Record Extent Location
.xx
Sector Addresses
.xy
Partition Geometry Descriptor
\&
.xx
Flags
.xx
File System Type
.xx
Unallocated Space Management
.xx
Partition Sequence Number
.xy
Partition Implementation Use Descriptor
\&
.xx
Partition Sequence Number
.xy
Access Entry
\&
.xx
Recording Time
.xy
File Set Descriptor
\&
.xx
Root Directory File Control Block Location
.xy
Direct Entry
\&
.xx
Record Format
.xx
Record Attributes
.xx
Record Length
.xx
Data Length
.xx
Logical Blocks Recorded
.xx
Access Time
.xx
Modification Time
.xx
Change Time
.xx
Extended Attribute File Control Block Location
.xx
Application Identifier
.xx
Application Use File Control Block Location
.xx
Implementation Use
.xy
Extended Attribute Record
.xx
attribute type
.xx
attribute information
.HH "Optional Access By User"
If the implementation is capable of recording the following descriptors
then the implementation shall allow the user to supply the
information that is to be recorded in the descriptor fields listed
below, and shall not be required to record the
descriptor if the user does not supply the information.
\&
.xy
Implementation Use Volume Descriptor
\&
.xx
Implementation Identifier
.xx
Implementation Use
.xy
File Set Descriptor
\&
.xx
Implementation Identifier
.HH "Restrictions"
.HH "Multivolume Volume Sets"
.EQ
delim $$
.EN
The implementation shall not be required to record information on the
volumes of a volume set that have been assigned sequence numbers 1
through $m-1$, where $m>1$, after any information has been recorded on the
volume of the volume set that has been assigned sequence number $m$.

The implementation shall not be required to record information on the
volume of a volume set that has been assigned sequence number $m+1$ if
there is sufficient space to record the information on the volume that
has been assigned sequence number $m$, or on volumes that have been
assigned sequence numbers 1 through $m$.
.EQ
delim off
.EN
.HH "Record Length"
The implementation may impose a limit on the length of a record that
may be recorded in a file.  The implementation is not required to
record any byte beyond the first
.I m
bytes of a record, where
.I m
is the value of the imposed limit.
.EQ
delim off
.EN
.HH "Requirements for a Receiving System"
.HH "General"
The implementation shall be capable of reading the files, and the
recorded descriptors as specified in 4.4, from a volume set that has
been recorded in accordance with one of the medium interchange levels
specified in this standard.
The implementation shall be capable of determining the largest addressable sector
number of the medium.
.HH "Files"
The implementation shall make available to the user the information
that constitutes the recorded files.

If the implementation allows the user to specify that the information
constituting a file is to be interpreted according to 3.6.2, the
implementation shall make available to the user the length of each
record in the file.
.HH "Descriptors"
The implementation shall allow the user to supply information
sufficient to enable the implementation to locate the files required
by the user, and to locate the volumes on which these files are
recorded.
.HH "Restrictions"
.HH "Record Length"
The implementation may impose a limit on the length of a record to be
made available to the user.  The implementation is not required to
make available to the user any byte beyond the first
.I m
bytes of a record, where
.I m
is the value of the imposed limit.
.HH "Requirements for Registration Authorities"
The following fields require a registration authority:
.RS
.de xx
.DL
\\$2 (\\$1)
..
.ns
\&
.xx "Partition Geometry Descriptor" "File System Type"
.xx "Extended Attribute" "Attribute Type"
.xx "Associated File Extended Attribute" "Associated File Type"
.xx "Data Compression Extended Attribute" "Compression Identifier"
.xx "Application Area Extended Attribute" "Application Identifier"
.xx "Implementation Area Extended Attribute" "Implementation Identifier"
.RE
.br
.1C
.BP
.HH "Annex 1: CRC Calculation"
The following C program may be used to calculate the CRC-CCITT checksum
as described in 1.6.4.
.P1
/*
 *	CRC 010041
 */
static unsigned short crc_table[256] = {
    0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7, 
    0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF, 
    0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6, 
    0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE, 
    0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485, 
    0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D, 
    0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4, 
    0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC, 
    0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823, 
    0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B, 
    0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12, 
    0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A, 
    0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41, 
    0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49, 
    0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70, 
    0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78, 
    0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F, 
    0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067, 
    0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E, 
    0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256, 
    0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D, 
    0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405, 
    0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C, 
    0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634, 
    0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB, 
    0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3, 
    0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A, 
    0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92, 
    0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9, 
    0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1, 
    0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8, 
    0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0 
};

unsigned short
cksum(s, n)
	register unsigned char *s;
	register int n;
{
	register unsigned int crc=0;

	while (n-- > 0)
	   crc = crc_table[(crc ^ *s++) & 0xff] ^ (crc>>8);

	return crc;
}

#ifdef	MAIN
unsigned char bytes[] = { 0x70, 0x6A, 0x77 };

main()
{
	unsigned short x;

	x = cksum(bytes, sizeof bytes);
	printf("checksum: calculated=%4.4x, correct=%4.4x\en", x, 0x168E);
	exit(0);
}
#endif
.P2
The table was generated by the following program:
.P1
#include	<stdio.h>

/*
 *	a.out 010041 for CRC-CCITT
 *	a.out 0100005 for CRC-16
 */

main(argc, argv)
	int argc; char *argv[];
{
	unsigned long crc, poly;
	int n, i;

	sscanf(argv[1], "%lo", &poly);
	if(poly & 0xffff0000){
		fprintf(stderr, "polynomial is too large\en");
		exit(1);
	}

	printf("/*\en *	CRC 0%o\en */\en", poly);
	printf("static unsigned short crc_table[256] = {\en");
	for(n = 0; n < 256; n++){
		if(n % 8 == 0)
			printf("    ");
		crc = n << 8;
		for(i = 0; i < 8; i++){
			if(crc & 0x8000)
				crc = (crc << 1) ^ poly;
			else
				crc <<= 1;
			crc &= 0xFFFF;
		}
		if(n == 255)
			printf("0x%04X ", crc);
		else
			printf("0x%04X, ", crc);
		if(n % 8 == 7)
			printf("\en");
	}
	printf("};\en");
	exit(0);
}
.P2
.nm
.BP
.1C
.ce
\f3Index\fP

.FC
.Hh Index
.2C

If a term has been formally defined,
the page number of that definition is given in \f3bold\fP.
.X1
Please send suggested terms to be indexed to the editor.
.X2
.ad l
.sp 2
.de xx
.if \\n(.$=1 \\$1
.if \\n(.$=2 \\$1 \\$2
.if \\n(.$=3 \\$1 \\$2 \\$3
.if \\n(.$=4 \\$1 \\$2 \\$3 \\$4
.if \\n(.$=5 \\$1 \\$2 \\$3 \\$4 \\$5
.if \\n(.$=6 \\$1 \\$2 \\$3 \\$4 \\$5 \\$6
.if \\n(.$=7 \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7
.if \\n(.$=8 \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8
.if \\n(.$=9 \\$1 \\$2 \\$3 \\$4 \\$5 \\$6 \\$7 \\$8 \\$9
..
.in .75i
.fi
.br
