parent
903a3b8bb0
commit
347eabdd44
739
AAIP.md
Normal file
739
AAIP.md
Normal file
@ -0,0 +1,739 @@
|
|||||||
|
Coordinated with SUSP 1.12 and RRIP 1.12 this specification
|
||||||
|
defines a matching extension for storing ACLs and xattr with the file
|
||||||
|
objects in the ISO image. (See `man 5 acl` , `man 5 attr`)
|
||||||
|
|
||||||
|
ISO 9660 aka ECMA-119 describes a non-POSIX hierachical filesystem
|
||||||
|
suitable mainly for directories and plain data files. Within that
|
||||||
|
specification there is some extension space for each file object,
|
||||||
|
the System Use Area. SUSP specifies a framework for using this area
|
||||||
|
as storage for add-on data. RRIP specifies within that framework
|
||||||
|
how to represent the classical POSIX file attributes (ownership,
|
||||||
|
permissions), special file types (device nodes, symbolic links)
|
||||||
|
and long file names. Regrettably it does not cover ACL and xattr.
|
||||||
|
This gap shall be closed by AAIP.
|
||||||
|
|
||||||
|
Fundamental idea is to use the same field format as the RRIP field
|
||||||
|
SL which is able to represent target paths of symbolic links.
|
||||||
|
There is nearly no limit for the length of a single component or
|
||||||
|
for the number of components but only the overall size limit of an
|
||||||
|
ISO 9660 image: 8 TB.
|
||||||
|
|
||||||
|
SL paths and AAIP attribute lists are isomorphic via the representation
|
||||||
|
```
|
||||||
|
/ name1 / value1 / name2 / value2 / name3 / value3 / ...
|
||||||
|
```
|
||||||
|
The format of SL allows any byte value in the components,
|
||||||
|
including 0-bytes and "/"-characters.
|
||||||
|
|
||||||
|
This choice gives hope that existing Rock Ridge readers can re-use
|
||||||
|
their SL parser code for an AAIP field parser.
|
||||||
|
|
||||||
|
A binary representation of ACLs is defined in order to make this kind
|
||||||
|
of attributes as compact as possible. Within that ACL definition
|
||||||
|
there is an optional translation table for names versus id numbers
|
||||||
|
of users and groups.
|
||||||
|
|
||||||
|
The following specification is implemented since `libisofs-0.6.18`.
|
||||||
|
Its predecessor AAIP-1.0 is implemented since `libisofs-0.6.14` and will
|
||||||
|
stay readable by `libisofs-0.6.18` and later.
|
||||||
|
TRANSLATE entries are neither produced nor interpreted yet.
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
Arbitrary Attribute Interchange Protocol
|
||||||
|
|
||||||
|
Version 2.0
|
||||||
|
|
||||||
|
Mar 18 2009
|
||||||
|
|
||||||
|
Interchange of Persistent File Attributes
|
||||||
|
|
||||||
|
by Thomas Schmitt - mailto:scdbackup@gmx.net
|
||||||
|
Libburnia project - mailto:libburn-hackers@pykix.org
|
||||||
|
|
||||||
|
|
||||||
|
AAIP is intended as companion of the Rock Ridge Interchange Protocol RRIP
|
||||||
|
which under the general design of System Use Sharing Protocol SUSP extends
|
||||||
|
ISO 9660 aka ECMA-119 filesystem semantics to match POSIX needs.
|
||||||
|
|
||||||
|
Goal is to have for each file an arbitrary number of attributes which consist
|
||||||
|
of two components (Name and Value) of arbitrary length and to have a compact
|
||||||
|
representation of ACLs.
|
||||||
|
|
||||||
|
This document describes a SUSP entry with Signature Word "AL" which collides
|
||||||
|
neither with SUSP 1.12 nor with RRIP 1.12. The AL entry has been designed
|
||||||
|
to be as similar to the RRIP entry SL as possible.
|
||||||
|
The presence of AAIP shall be announced by a particular ER entry.
|
||||||
|
|
||||||
|
Since the size of a SUSP entry is limited to 255, multiple entries may be
|
||||||
|
needed to describe one component. The CE mechanism of SUSP shall be used to
|
||||||
|
address enough storage if needed.
|
||||||
|
|
||||||
|
AL entries and the ER entry of AAIP shall only be present if the ER entry
|
||||||
|
of RRIP is present.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
System Entries Provided by this Specification
|
||||||
|
|
||||||
|
* AL
|
||||||
|
|
||||||
|
Description of the "AL" System Use Entry
|
||||||
|
|
||||||
|
The entry has exactly the same layout as RRIP entry SL. One has to expect
|
||||||
|
more data bytes than with SL, though, and any of the 256 possible byte values.
|
||||||
|
The reader shall be prepared to detect and handle oversized data.
|
||||||
|
|
||||||
|
One or more AL entries form the Attribute List of a file object with
|
||||||
|
an even number of components. Each two consequtive components form a pair of
|
||||||
|
Name and Value.
|
||||||
|
|
||||||
|
The empty name indicates that the value is a compact representation of ACLs.
|
||||||
|
Names must not contain byte value 0x00. Names which begin by bytes 0x01 to 0x1f
|
||||||
|
represent names in particular namespaces. See below: Namespaces.
|
||||||
|
The meaning of any other names or name parts is not specified by this document.
|
||||||
|
|
||||||
|
All AL entries except the last one shall have the CONTINUE flag set. An AL
|
||||||
|
entry with CONTINUE set to 0 indicates the end of the Attribute List.
|
||||||
|
|
||||||
|
The format of the AL System Use Field is as follows:
|
||||||
|
|
||||||
|
[1] "BP 1 to BP 2 - Signature Word" shall be (41)(4C) ("AL").
|
||||||
|
|
||||||
|
[2] "BP 3 - Length" shall specify as an 8-bit number the length in bytes of
|
||||||
|
the AL entry recorded according to ISO 9660:7.1.1.
|
||||||
|
|
||||||
|
[3] "BP 4 - System Use Entry Version" shall be 1 as in ISO 9660:7.1.1.
|
||||||
|
|
||||||
|
[4] "BP 5 - Flags" shall contain bit field flags numbered 0 to 7 starting
|
||||||
|
with the least significant bit as follows:
|
||||||
|
0 CONTINUE This AL entry continues in the next AL entry.
|
||||||
|
All other bits shall be set to 0.
|
||||||
|
|
||||||
|
[5] "BP 6 to Length - Component Area" shall contain Component Records
|
||||||
|
as described below.
|
||||||
|
|
||||||
|
| 'A' | 'L' | LENGTH | 1 | FLAGS | COMPONENT AREA |
|
||||||
|
|
||||||
|
|
||||||
|
Within AL entries each component (Name or Value) shall be recorded as one
|
||||||
|
or more component records. If a component does not fit into the remaining
|
||||||
|
space of an AL entry then it shall be continued in following AL entries.
|
||||||
|
|
||||||
|
All Component Records of a component except the last one shall have the
|
||||||
|
CONTINUE flag set. A Component Record with CONTINUE set to 0 indicates the end
|
||||||
|
of the component. An eventually following Component Record starts the next
|
||||||
|
component.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
The Component Record format is identical to the one of the SL entry.
|
||||||
|
The complete form of the following summary can be found in RRIP 1.12 "4.1.3.1".
|
||||||
|
In case of discrepancies, RRIP 1.12 is the decisive specification. Please
|
||||||
|
inform the author of this document if you find such a discrepancy.
|
||||||
|
|
||||||
|
Component Records shall be recorded contiguously within each Component Area,
|
||||||
|
starting in the first byte of the Component Area. The last Component Record
|
||||||
|
in the Component Area of an AL System Use Entry may be continued in the
|
||||||
|
Component Area of the next recorded AL System Use Entry in the same
|
||||||
|
System Use Area.
|
||||||
|
|
||||||
|
Each Component Record shall have the following format:
|
||||||
|
|
||||||
|
[A] "BP 1 - Component Flags" shall contain bit field flags numbered 0 to 7,
|
||||||
|
starting with the least significant bit, as follows:
|
||||||
|
0 CONTINUE This Component Record continues in the next
|
||||||
|
AL Component Record.
|
||||||
|
all others are RESERVED and shall be 0.
|
||||||
|
|
||||||
|
[B] "BP 2 - Component Length (LEN_CP)" shall specify as an 8-bit number the
|
||||||
|
number of component bytes in the Component Record. This length shall not
|
||||||
|
include the first two bytes of the Component Record.
|
||||||
|
If any of the bit positions 1-3 is set, the value of this field shall be
|
||||||
|
set to ZERO and no Component Content shall be recorded.
|
||||||
|
This field shall be recorded according to ISO 9660 Format section 7.1.1.
|
||||||
|
|
||||||
|
[C] "BP 3 to 2 + LEN_CP - Component Content" shall contain the component
|
||||||
|
bytes in the Component Record.
|
||||||
|
|
||||||
|
| COMPONENT FLAGS | LEN_CP | COMPONENT BYTES |
|
||||||
|
|
||||||
|
|
||||||
|
Example: Two pairs of "name"="long...content" and "one"="more" encoded as
|
||||||
|
two AL entries
|
||||||
|
|
||||||
|
Field 1 contains the Component Record of Name and one Component Record of
|
||||||
|
Value :
|
||||||
|
{ 'A', 'L', 255, 1, 1,
|
||||||
|
0, 4, 'n', 'a', 'm', 'e',
|
||||||
|
1, 255, 'l', 'o', 'n', 'g', ... 238 more bytes, 13 go to next AL ... }
|
||||||
|
Field 2 contains the rest of "long...content" and the complete second pair.
|
||||||
|
It marks the end of the Attribute List :
|
||||||
|
{ 'A', 'L', 38, 1, 0,
|
||||||
|
... 13 remaining bytes of the Component Record in first entry ...
|
||||||
|
0, 7, 'c', 'o', 'n', 't', 'e', 'n', 't',
|
||||||
|
0, 3, 'o', 'n', 'e',
|
||||||
|
0, 4, 'm', 'o', 'r', 'e' }
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Namespaces
|
||||||
|
|
||||||
|
AAIP provides a short notation for namespaces which uses a single non-printable
|
||||||
|
byte at the start of the name.
|
||||||
|
Reserved start bytes of names are
|
||||||
|
0x01 to 0x1F
|
||||||
|
|
||||||
|
The names of extended file attributes are traditionally organized in
|
||||||
|
namespaces, which get expressed as first part of an attribute name up to a
|
||||||
|
period "." character. It is also tradition that names are printable text,
|
||||||
|
single words and especially contain no 0-bytes.
|
||||||
|
|
||||||
|
AAIP does not enforce the use of any namespace but it urges that names in the
|
||||||
|
following registered namespaces are used according to traditions.
|
||||||
|
|
||||||
|
The namespaces "system." and "user." are available with many file system
|
||||||
|
types. "system." is file system dependent and often restricted in the
|
||||||
|
choice of names. "user." is portable and allows the application to choose
|
||||||
|
about any name.
|
||||||
|
|
||||||
|
Namespace "isofs." is defined for internal use of AAIP enhanced ISO 9660
|
||||||
|
file systems. Names in this namespace should be registered at libburnia-project.org.
|
||||||
|
|
||||||
|
Further namespaces may be registered at libburnia-project.org.
|
||||||
|
|
||||||
|
The reserved start bytes of names have the following meaning
|
||||||
|
0x01 escape reserved character at start of name
|
||||||
|
0x02 namespace "system."
|
||||||
|
0x03 namespace "user."
|
||||||
|
0x04 namespace "isofs."
|
||||||
|
0x05 namespace "trusted."
|
||||||
|
0x06 namespace "security."
|
||||||
|
0x07 to 0x1F shall not be used yet.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
Name "user.abc" with and without short notation. Both is allowed.
|
||||||
|
0, 4, 0x03, 'a', 'b', 'c'
|
||||||
|
0 8, 'u', 's', 'e', 'r', '.', 'a', 'b', 'c'
|
||||||
|
|
||||||
|
Name "\003abc" (if really desired)
|
||||||
|
0, 5, 0x01, 0x03, 'a', 'b', 'c'
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Specification of binary ACL representation as special Arbitrary Attribute
|
||||||
|
|
||||||
|
The Name component of a binary ACL shall be of length 0.
|
||||||
|
|
||||||
|
The Value shall be an arbitrary number of ACL Entries:
|
||||||
|
|
||||||
|
[a] "BP 1 - Entry Flags" shall contain bit field flags numbered 0 to 7,
|
||||||
|
starting with the least significant bit, as follows:
|
||||||
|
0 EXEC indicates that this entry grants execute permission
|
||||||
|
1 WRITE write permission
|
||||||
|
2 READ read permission
|
||||||
|
3 QUALIFIER indicates that one or more Qualifier Records follow
|
||||||
|
4 - 7 TYPE
|
||||||
|
shall contain the tag type of the ACL entry as four bit code:
|
||||||
|
0 TRANSLATE Entry for a global map of name to numeric id
|
||||||
|
Qualifier is a record of number and text
|
||||||
|
1 ACL_USER_OBJ Permissions of owning user (as of PX entry)
|
||||||
|
3 ACL_GROUP_OBJ Permissions of owning group (as of PX entry)
|
||||||
|
5 ACL_MASK Restricts 10, 3, and 12 via logical AND
|
||||||
|
6 ACL_OTHER Permissions of non-listed, non-owning users
|
||||||
|
8 SWITCH_MARK Switch from "access" ACL to "default" ACL
|
||||||
|
10 ACL_USER_N Permissions of arbitrary user. Qualifier is
|
||||||
|
the numeric user id (max. 4 bytes).
|
||||||
|
12 ACL_GROUP_N Permissions of arbitrary group. Qualifier is
|
||||||
|
the numeric group id (max. 4 bytes).
|
||||||
|
15 FUTURE_VERSION Will indicate that this document
|
||||||
|
does not apply to the entry.
|
||||||
|
The other values are reserved. Readers shall ignore them if
|
||||||
|
they are not aware of updates of this document which would
|
||||||
|
assign a meaning to them.
|
||||||
|
|
||||||
|
The entries must match the permission bits of the PX entry. This shall obey the
|
||||||
|
rule that ACL_USER_OBJ must match S_IRWXU, ACL_OTHER must match S_IRWXO,
|
||||||
|
ACL_MASK - if present - must match S_IRWXG, else ACL_GROUP_OBJ must match
|
||||||
|
S_IRWXG. If there is ACL_USER_N or ACL_GROUP_N there must also be ACL_MASK.
|
||||||
|
|
||||||
|
A numeric qualifier is a binary number of variable length up to 4 bytes. The
|
||||||
|
Most Significant Byte comes first. The number shall be the "POSIX File User ID"
|
||||||
|
or "POSIX File Group ID" as also used in RRIP PX entries. The ids of owning
|
||||||
|
user and owning group shall be taken from the PX entry of the file object.
|
||||||
|
|
||||||
|
Optional TRANSLATE entries may associate user or group names with numeric
|
||||||
|
ids to allow the reading system to remap the numeric ids. See below.
|
||||||
|
The writer is not obliged to write them and the reader is not obliged to
|
||||||
|
interpret them.
|
||||||
|
|
||||||
|
The ACL entries belong to the "access" ACL of a file object. An optional
|
||||||
|
SWITCH_MARK entry may direct further entries to the "default" ACL which
|
||||||
|
is defined for directory objects. The EXEC bit of SWITCH_MARK shall be 1.
|
||||||
|
The bits for WRITE, READ, QUALIFIER shall be 0.
|
||||||
|
|
||||||
|
An eventually needed qualifier is stored in one or more Qualifier Records.
|
||||||
|
|
||||||
|
[b] "BP 2 - Qualifier Record Head" shall be present only if QUALIFIER is set
|
||||||
|
to 1. It shall give the number of Qualifier Bytes and eventually
|
||||||
|
indicate that the qualifier continues in a Qualifier Record which comes
|
||||||
|
imediately after this record.
|
||||||
|
0 to 127 Q_LENGTH, the qualifier is complete by this record
|
||||||
|
128 to 255 Q_LENGTH+128, the qualifier is continued by next record
|
||||||
|
So a Qualifier Record can contain at most 127 Qualifier Bytes.
|
||||||
|
This field shall be recorded according to ISO 9660 Format section 7.1.1.
|
||||||
|
|
||||||
|
[c] "BP 3 to BP 2 + Q_LENGTH - Qualifier Bytes" shall be present only if
|
||||||
|
QUALIFIER is set to 1 and hold the announced number of bytes of the
|
||||||
|
user or group name.
|
||||||
|
|
||||||
|
| ENTRY FLAGS [ | QUALIFIER HEAD | QUALIFIER BYTES | ]
|
||||||
|
|
||||||
|
|
||||||
|
Example: From man 5 acl: u::rw-,u:lisa:rw-,g::r--,g:toolies:rw-,m::r--,o::r--
|
||||||
|
"lisa" has user number 123, "toolies" has group number 65534
|
||||||
|
{ 'A', 'L', 20, 1, 0,
|
||||||
|
0, 0,
|
||||||
|
0, 11, 0x16,
|
||||||
|
0xAE, 1, 123,
|
||||||
|
0x34,
|
||||||
|
0xCE, 2, 255, 254,
|
||||||
|
0x54,
|
||||||
|
0x64 }
|
||||||
|
|
||||||
|
Example: "Access" ACL and "default" ACL (0x81 is the switch mark)
|
||||||
|
u::rwx,g::r-x,o::r-x, du::rwx,dg::r-x,dm::rwx,do::r-x,du:lisa:rwx
|
||||||
|
{ 'A', 'L', 20, 1, 0,
|
||||||
|
0, 0,
|
||||||
|
0, 11, 0x17, 0x35, 0x65,
|
||||||
|
0x81,
|
||||||
|
0x17, 0x35, 0x57, 0x65,
|
||||||
|
0xA7, 1, 123 }
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Association of Names and Numeric Identifiers
|
||||||
|
|
||||||
|
The entry flag value 0x08 TRANSLATE is not a ACL entry of the hosting object
|
||||||
|
but rather a global hint about the relation of roles, names and numeric ids.
|
||||||
|
If it is recorded at all, then it shall be recorded with the first Directory
|
||||||
|
Entry of the volume's root directory. According to the description of SUSP
|
||||||
|
entry ER, this has to be "dot" or (00). Other than with ER, a TRANSLATE entry
|
||||||
|
may not appear in the root of directory sub trees.
|
||||||
|
|
||||||
|
An interested reader shall examine the Arbitrary Attributes of this Directory
|
||||||
|
Entry in order to collect a translation table.
|
||||||
|
The advised translation is: PX or AL Id number -> name -> local id number.
|
||||||
|
|
||||||
|
The Qualifier Bytes of a TRANSLATE entry shall have the following format:
|
||||||
|
|
||||||
|
[i] "BP 0 - Role" shall tell whether it is about a user name (role 0) or
|
||||||
|
a group name (role 1). Other values are not allowed.
|
||||||
|
|
||||||
|
[ii] "BP 1 to BP 8 - Numeric Id" shall hold the 32 bit POSIX Id number of the
|
||||||
|
entry. This field shall be recorded according to ISO 9660:7.3.3.
|
||||||
|
|
||||||
|
[iii] "BP 9 to End Of Qualifier - Name" shall hold the name bytes of this
|
||||||
|
entry.
|
||||||
|
|
||||||
|
| ROLE | NUMERIC ID | NAME |
|
||||||
|
|
||||||
|
Example: User id number 123 gets associated with user name "lisa"
|
||||||
|
|
||||||
|
0x08, 13, 0, 123,0,0,0, 0,0,0,123, 'l', 'i', 's', 'a',
|
||||||
|
|
||||||
|
|
||||||
|
Example: A very long qualifier naming "His_Excellency_..._the_Boss" as user #1.
|
||||||
|
This needs two qualifier records.
|
||||||
|
0x08, 255, 0, 1,0,0,0, 0,0,0,1,
|
||||||
|
'H', 'i', 's', '_', 'E', 'x', 'c', 'e', 'l', 'e',
|
||||||
|
... 108 more bytes ...
|
||||||
|
8, 't', 'h', 'e', '_', 'B', 'o', 's', 's',
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Specification of the ER System Use Entry Values for AAIP:
|
||||||
|
|
||||||
|
This ER system entry shall only be present if the ER entry of RRIP is present.
|
||||||
|
To be compliant with SUSP-1.12, this ER entry must be present if AL entries
|
||||||
|
are present, and ES entries have to mark RRIP and AAIP entries.
|
||||||
|
If for some reason compliance with SUSP-1.10 is intended, then this ER entry
|
||||||
|
and the ES entries must not be present, although SUSP-1.10 would allow ER.
|
||||||
|
(See below: Compatibility considerations.)
|
||||||
|
|
||||||
|
The Extension Version number for this version of AAIP shall be 1.
|
||||||
|
|
||||||
|
The Extension Identifier field shall be "AAIP_0200" with Identifier Length 9.
|
||||||
|
|
||||||
|
The mandatory content form of the Extension Descriptor is
|
||||||
|
"AL PROVIDES VIA AAIP 2.0 SUPPORT FOR ARBITRARY FILE ATTRIBUTES IN ISO 9660 IMAGES"
|
||||||
|
The Description Length is 81.
|
||||||
|
|
||||||
|
The recommended content of the Extension Source is
|
||||||
|
"PLEASE CONTACT THE LIBBURNIA PROJECT VIA LIBBURNIA-PROJECT.ORG".
|
||||||
|
The corresponding Source Length is 62.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Compatibility Considerations
|
||||||
|
|
||||||
|
This extension is supposed not to disturb any reader system which complies
|
||||||
|
to SUSP-1.10:
|
||||||
|
"6.2 Requirements for a Receiving System
|
||||||
|
[...]
|
||||||
|
Any System Use Field which the receiving system does not recognize
|
||||||
|
is to be ignored and skipped."
|
||||||
|
|
||||||
|
SUSP-1.12 extends this prescription by:
|
||||||
|
"Any System Use Entry, with the exception of the set of System Use Entries
|
||||||
|
defined in this document, following an "ES" System Use Entry that indicates
|
||||||
|
an extension specification which the receiving system does not recognize
|
||||||
|
shall be ignored and skipped."
|
||||||
|
|
||||||
|
According to SUSP-1.12 the ER entry is mandatory for a conformant extension.
|
||||||
|
It also prescribes that in the case that ER entries of RRIP and AAIP are
|
||||||
|
present, then ES entries shall be used to separate RRIP entries from AAIP
|
||||||
|
entries.
|
||||||
|
SUSP-1.12 frowns on extensions which are not announced by ER. Nevertheless
|
||||||
|
is does not totally outrule them.
|
||||||
|
|
||||||
|
SUSP-1.10 does not specify ES entries at all and does not demand to announce
|
||||||
|
extension entries by an ER entry. But if there is the AAIP ER then there
|
||||||
|
must be ES at the appropriate places. Else the format would explicitely
|
||||||
|
violate SUSP-1.12.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
Model Relations:
|
||||||
|
|
||||||
|
Attribute List ------------- [1:0..1] ------------- ACL
|
||||||
|
[1:0..n] [1:0..n]
|
||||||
|
Arbitrary Attribute ( [1:0..1] ACL ) Entry
|
||||||
|
[1:2..2n] [1:0..1]
|
||||||
|
Component ( [1..m:1..n] AL Field ) Qualifier
|
||||||
|
[1:1..n] << one of >>
|
||||||
|
Component Record / \
|
||||||
|
[1..m:1..n] Translation Entry , Numeric Id
|
||||||
|
AL Field | |
|
||||||
|
[1:1..n] [1:1]
|
||||||
|
\ /
|
||||||
|
Qualifier Record
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
Revoked drafts:
|
||||||
|
|
||||||
|
The following outdated versions may be interpreted at read time but they
|
||||||
|
shall not be written any more.
|
||||||
|
|
||||||
|
AAIP-1.0
|
||||||
|
|
||||||
|
Previous versions up to AAIP 1.0 used field signature "AA" rather than "AL".
|
||||||
|
This nearly collides with "Apple ISO 9660 Extensions". The Apple "AA" field of
|
||||||
|
version 1 has a length of 7, whereas the shortest first AAIP field "AA" had
|
||||||
|
length 9.
|
||||||
|
|
||||||
|
Beginning with AAIP 2.0, the field name has been changed to "AL".
|
||||||
|
If a reader interprets old AAIP "AA" fields, then it must take precautions to
|
||||||
|
distinguish them from Apple "AA" fields. But it is well compliant with AAIP 2.0
|
||||||
|
to just ignore any kind of "AA" fields.
|
||||||
|
|
||||||
|
AAIP 1.0 had ER signature "AAIP_0100".
|
||||||
|
|
||||||
|
AAIP-0.2
|
||||||
|
|
||||||
|
AAIP 0.2 with ER signature "AAIP_0002" provided means to announce and use a
|
||||||
|
different signature than "AA". This was revoked because ES entries serve the
|
||||||
|
purpose to distinguish AAIP entries from eventual "AA" entries of any other
|
||||||
|
extension.
|
||||||
|
Regrettably no reader (kernel) was found which neatly interprets ES. Many do
|
||||||
|
not even recognize the RRIP-1.12 ER signatures "IEEE_P1282", "IEEE_1282".
|
||||||
|
|
||||||
|
AAIP 0.2 defined two ACL types which did not make it into AAIP 1.0
|
||||||
|
2 ACL_USER of arbitrary user, with name as qualifier
|
||||||
|
4 ACL_GROUP of arbitrary group, with name as qualifier
|
||||||
|
Their job was transferred to ACL_USER_N and ACL_GROUP_N which have numeric
|
||||||
|
qualifiers.
|
||||||
|
|
||||||
|
AAIP-0.0
|
||||||
|
|
||||||
|
There was a draft AAIP 0.0 with ER signature "AAIP_2008A". It did not resemble
|
||||||
|
the existing entry SL and was never implemented.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
References:
|
||||||
|
|
||||||
|
ECMA-119 aka ISO 9660
|
||||||
|
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf
|
||||||
|
|
||||||
|
SUSP 1.12 (entries CE , PD , SP , ST , ER , ES)
|
||||||
|
ftp://ftp.ymi.com/pub/rockridge/susp112.ps
|
||||||
|
|
||||||
|
RRIP 1.12 (entries PX , PN , SL , NM , CL , PL , RE , TF , SF , obsolete: RR)
|
||||||
|
ftp://ftp.ymi.com/pub/rockridge/rrip112.ps
|
||||||
|
|
||||||
|
Apple ISO 9660 Extensions (entries AA and BA)
|
||||||
|
http://developer.apple.com/technotes/fl/fl_36.html
|
||||||
|
|
||||||
|
Amiga AS entry
|
||||||
|
http://www.estamos.de/makecd/Rock_Ridge_Amiga_Specific
|
||||||
|
|
||||||
|
zisofs entry ZF (prepared by zisofs-tools, written by mkisofs)
|
||||||
|
http://freshmeat.net/projects/zisofs-tools/
|
||||||
|
http://libburnia-project.org/wiki/zisofs
|
||||||
|
|
||||||
|
Program mkisofs emits entry XA
|
||||||
|
ftp://ftp.berlios.de/pub/cdrecord/alpha
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
This text is part of the libisofs release as `doc/susp_aaip_2_0.txt` .
|
||||||
|
|
||||||
|
-------
|
||||||
|
|
||||||
|
Libburnia maintains a directory where names from namespace "isofs." may be registered.
|
||||||
|
Interested application programmers are invited to submit own names and their description.
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
Arbitrary Attribute Interchange Protocol
|
||||||
|
Interchange of Persistent File Attributes
|
||||||
|
|
||||||
|
Directory of Namespace "isofs."
|
||||||
|
|
||||||
|
by Thomas Schmitt - mailto:scdbackup@gmx.net
|
||||||
|
Libburnia project - mailto:libburn-hackers@pykix.org
|
||||||
|
|
||||||
|
|
||||||
|
The following names are defined for AAIP namespace "isofs." as mentioned in
|
||||||
|
specification of AAIP. Unless explicitly stated otherwise, numbers with
|
||||||
|
names like *_LEN are 8 bit unsigned integers, those with *_BYTES are 32 bit
|
||||||
|
unsigned integers.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Name:
|
||||||
|
isofs.ca
|
||||||
|
|
||||||
|
Purpose:
|
||||||
|
Records the range of checksummed image data (START, END), the number
|
||||||
|
of checksum items (COUNT), the number of bytes in a single checksum item
|
||||||
|
(SIZE), and the name of the checksum algorithm (CHECKSUM_TYPE).
|
||||||
|
END is also the block address of the start of the checksum recording
|
||||||
|
area in the image.
|
||||||
|
See also isofs.cx .
|
||||||
|
This attribute shall be attached to the root directory entry
|
||||||
|
and be global for the whole image.
|
||||||
|
|
||||||
|
Format of Value:
|
||||||
|
START_LEN | START_BYTES | END_LEN | END_BYTES |
|
||||||
|
COUNT_LEN | COUNT_BYTES | SIZE_LEN | SIZE_BYTES | CHECKSUM_TYPE
|
||||||
|
Each number is encoded as _LEN byte and _BYTES value string.
|
||||||
|
The _LEN fields comply to ISO 9660 Format section 7.1.1.
|
||||||
|
The byte strings START_BYTES, END_BYTES, COUNT_BYTES, SIZE_BYTES begin
|
||||||
|
with the most significant byte. Leading zero bytes are allowed.
|
||||||
|
CHECKSUM_TYPE consists of the bytes after
|
||||||
|
START_LEN + END_LEN + COUNT_LEN + SIZE_LEN + 4.
|
||||||
|
It shall be a string of printable characters without terminating 0-byte.
|
||||||
|
Type names shall be registered here.
|
||||||
|
For now there is:
|
||||||
|
"MD5" 128 bit message digest, see RFC 1321, see man md5sum
|
||||||
|
|
||||||
|
Example:
|
||||||
|
LBA range 32 to 1000000 , 520 checksums recorded, MD5
|
||||||
|
{ 1, 32,
|
||||||
|
3, 15, 66, 64,
|
||||||
|
2, 2, 8,
|
||||||
|
1, 16,
|
||||||
|
'M', 'D', '5' }
|
||||||
|
or
|
||||||
|
{ 4, 0, 0, 0, 32,
|
||||||
|
4, 0, 15, 66, 64,
|
||||||
|
4, 0, 0, 2, 8,
|
||||||
|
1, 16,
|
||||||
|
'M', 'D', '5' }
|
||||||
|
|
||||||
|
Registered:
|
||||||
|
16 Jul 2009 by Thomas Schmitt for libisofs.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Name:
|
||||||
|
isofs.cs
|
||||||
|
|
||||||
|
Purpose:
|
||||||
|
Records the name of the character set that was used as output character
|
||||||
|
set when writing the RRIP name tree of the ISO 9660 image. It shall be
|
||||||
|
suitable as parameter for function iconv_open(3).
|
||||||
|
This attribute shall be attached to the root directory entry and be
|
||||||
|
global for the whole image.
|
||||||
|
|
||||||
|
Format of Value:
|
||||||
|
Shall hold the character set name without terminating 0-byte.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
{ 'I', 'S', 'O', '-', '8', '8', '5', '9' , '-', '1' }
|
||||||
|
|
||||||
|
Registered:
|
||||||
|
18 Mar 2009 by Thomas Schmitt for libisofs.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Name:
|
||||||
|
isofs.cx
|
||||||
|
|
||||||
|
Purpose:
|
||||||
|
Records the index of the file's checksum in the checksum area at the
|
||||||
|
end of the image. The byte address of the checksum is
|
||||||
|
checksum_area_lba * 2048 + isofs.cx * checksum_size
|
||||||
|
Default checksum algorithm is MD5 with a size of 16 byte.
|
||||||
|
See also isofs.ca .
|
||||||
|
|
||||||
|
Format of Value:
|
||||||
|
A byte string which begins with the most significant byte.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
Index 123456
|
||||||
|
{ 1, 226, 64 }
|
||||||
|
|
||||||
|
Registered:
|
||||||
|
16 Jul 2009 by Thomas Schmitt for libisofs.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Name:
|
||||||
|
isofs.di
|
||||||
|
|
||||||
|
Purpose:
|
||||||
|
Records .st_dev and .st_ino of struct stat of the file source in the
|
||||||
|
local filesystem. See man 2 stat.
|
||||||
|
Both values may be unsigned integers up to 255 bytes.
|
||||||
|
|
||||||
|
Format of Value:
|
||||||
|
DEV_LEN | DEV_BYTES | INO_LEN | INO_BYTES
|
||||||
|
The _LEN fields comply to ISO 9660 Format section 7.1.1.
|
||||||
|
The byte strings begin with the most significant byte.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
Device number 2001, inode number 176343
|
||||||
|
{ 2, 7, 209,
|
||||||
|
3, 2, 176, 215 }
|
||||||
|
|
||||||
|
Registered:
|
||||||
|
17 Feb 2009 by Thomas Schmitt for xorriso.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Name:
|
||||||
|
isofs.hb
|
||||||
|
|
||||||
|
Purpose:
|
||||||
|
Records the IsoHfsplusBlessings blessing of a IsoNode as defined
|
||||||
|
in libisofs.h. At image load time, this info may be converted back
|
||||||
|
into a relation between IsoImage and IsoNode so that it is available for
|
||||||
|
the HFS+ writer when a new ISO 9660 / HFS+ image gets produced.
|
||||||
|
|
||||||
|
Format of Value:
|
||||||
|
BLESSING
|
||||||
|
This is a single byte out of {'p', 'i', 's', '9', 'x'} for
|
||||||
|
ISO_HFSPLUS_BLESS_PPC_BOOTDIR, ISO_HFSPLUS_BLESS_INTEL_BOOTFILE,
|
||||||
|
ISO_HFSPLUS_BLESS_SHOWFOLDER, ISO_HFSPLUS_BLESS_OS9_FOLDER,
|
||||||
|
ISO_HFSPLUS_BLESS_OSX_FOLDER.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
{ 'p' }
|
||||||
|
|
||||||
|
Registered:
|
||||||
|
07 Jun 2012 by Thomas Schmitt for xorriso.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Name:
|
||||||
|
isofs.hx
|
||||||
|
|
||||||
|
Purpose:
|
||||||
|
Records the iso_hfsplus_xinfo_data information as defined in libisofs.h.
|
||||||
|
At image load time, this info may be converted back into an xinfo
|
||||||
|
attachment for iso_hfsplus_xinfo_func so that it is available for
|
||||||
|
the HFS+ writer when a new ISO 9660 / HFS+ image gets produced.
|
||||||
|
|
||||||
|
Format of Value:
|
||||||
|
VERSION_LEN | VERSION | CREATOR | TYPE
|
||||||
|
VERSION_LEN complies to ISO 9660 Format section 7.1.1.
|
||||||
|
The byte string VERSION begins with the most significant byte.
|
||||||
|
VERSION == 0 is the only one that is currently defined. It assures the
|
||||||
|
existence of 4 bytes CREATOR and 4 bytes TYPE.
|
||||||
|
Higher versions will keep these 8 bytes and possibly add new ones.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
{ 1, 0, 'Y', 'Y', 'D', 'N', 'T', 'E', 'X', 'T' }
|
||||||
|
|
||||||
|
Registered:
|
||||||
|
07 Jun 2012 by Thomas Schmitt for xorriso.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Name:
|
||||||
|
isofs.nt
|
||||||
|
|
||||||
|
Purpose:
|
||||||
|
Records the name truncation mode and the truncation length for Rock Ridge
|
||||||
|
names. See iso_image_set_truncate_mode() in libisofs.h.
|
||||||
|
This attribute shall be attached to the root directory entry and be
|
||||||
|
global for the whole image.
|
||||||
|
|
||||||
|
Format of Value:
|
||||||
|
MODE_LEN | MODE_BYTES | LENGTH_LEN | LENGTH_BYTES
|
||||||
|
|
||||||
|
Example:
|
||||||
|
{ 1, 1, 1, 255 }
|
||||||
|
|
||||||
|
Registered:
|
||||||
|
24 Sep 2015 by Thomas Schmitt for libisofs.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Name:
|
||||||
|
isofs.st
|
||||||
|
|
||||||
|
Purpose:
|
||||||
|
Records a time point at least 1 second before any nodes were added to a
|
||||||
|
freshly loaded or created ISO image. Nodes in the image which have
|
||||||
|
younger timestamps are suspect to have changed their content during
|
||||||
|
image production and might bear inconsistent content.
|
||||||
|
The RRIP timestamps have a blind second during which a change after
|
||||||
|
node registration would not be recognizable for incremental backups
|
||||||
|
which are based in "isofs.di" rather than on content comparison.
|
||||||
|
This attribute shall be attached to the root directory entry
|
||||||
|
and be global for the whole image.
|
||||||
|
|
||||||
|
Format of Value:
|
||||||
|
Shall hold UTC seconds since 1970 as decimal number string without
|
||||||
|
terminating 0-byte.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
{ '1', '2', '3', '8', '7', '4', '2', '2', '9', '6' }
|
||||||
|
|
||||||
|
Registered:
|
||||||
|
03 Apr 2009 by Thomas Schmitt for xorriso.
|
||||||
|
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
-------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
This text is under
|
||||||
|
Copyright (c) 2009 - 2011 Thomas Schmitt <scdbackup@gmx.net>
|
||||||
|
It shall only be modified in sync with libisofs and other software which
|
||||||
|
makes use of AAIP. Please mail change requests to mailing list
|
||||||
|
<libburn-hackers@pykix.org> or to the copyright holder in private.
|
||||||
|
Only if you cannot reach the copyright holder for at least one month it is
|
||||||
|
permissible to modify this text under the same license as the affected
|
||||||
|
copy of libisofs.
|
||||||
|
If you do so, you commit yourself to taking reasonable effort to stay in
|
||||||
|
sync with the other interested users of this text.
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
This text is part of the libisofs release as `doc/susp_aaip_isofs_names.txt` .
|
||||||
|
|
||||||
Loading…
x
Reference in New Issue
Block a user