Normative references cleanup
Nick Stoughton <[email protected]> Tue, 02 Aug 2005 11:29:15 -0700
| Newsgroups | gmane.linux.lsb.specification |
|---|---|
| Message-ID | <1123007354.32489.22932.camel@collie> |
One item we have discussed several times, mainly in the light of ISO
requirements, is how to clean up the normative references chapter. One
requirement is for normative refs to fit the following from the ISO
directives:
<quote src='iso_directives_2.pdf'>
6.2.2 Normative references
This optional element shall give a list of the referenced documents
cited (see 6.6.7.5) in the document in such a way as to make them
indispensable for the application of the document. For dated references,
each shall be given with its year of publication, or, in the case of
enquiry or final drafts, with a dash together with a footnote “To be
published.”, and full title. The year of publication or dash shall not
be given for undated references. When an undated
reference is to all parts of a document, the publication number shall be
followed by the indication “(all parts)” and the general title of the
series of parts (i.e. the introductory and main elements, see Annex D).
In principle, the referenced documents shall be documents published by
ISO and/or IEC. Documents published by other bodies may be referred to
in a normative manner provided that:
a) the referenced document is recognized by the ISO and/or IEC committee
concerned as having wide acceptance and authoritative status as well as
being publicly available,
b) the ISO and/or IEC committee concerned has obtained the agreement of
the authors or publishers (where known) of the referenced document to
its inclusion and to its being made available as required — the authors
or publishers will be expected to make available such documents on
request,
c) the authors or publishers (where known) have also agreed to inform
the ISO and/or IEC committee concerned of their intention to revise the
referenced document and of the points the revision will concern, and
d) the ISO and/or IEC committee concerned undertakes to review the
situation in the light of any changes in the referenced document.
The list shall be introduced by the following wording:
“The following referenced documents are indispensable for the
application of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.”
</quote>
I propose splitting the current list into two tables, one normative and
one informative. If we look right now as to which other standards are
used to draw interfaces from, we have the following counts:
mysql> select SShort, count(Iid) from Standard, Interface
-> where Istandard=Sid and Sarch=1 and Istatus in
('Included','Deprecated')
-> AND Sname NOT IN (
'Xlib','XSM','Xt','X-dbe','X-DPMS','X-Record','X-security','X-shape','X-shm','X-sync','X-test','XICE','XINPUT','OGL','ISOCXX','CXXABI','LANANA','Gdk','Gdk-pixbuf','Glib','Gobject','Gtk','X-evi' )
-> group by Sid;
+--------------------+------------+
| SShort | count(Iid) |
+--------------------+------------+
| SUSv2 | 10 |
| this specification | 444 |
| SVID Issue 3 | 40 |
| ISO C (1999) | 46 |
| X/Open Curses | 283 |
| Large File Support | 24 |
| SVID Issue 4 | 8 |
| ISO POSIX (2003) | 921 |
+--------------------+------------+
8 rows in set (0.11 sec)
Remove 'this specification' from that list, and we have our normative
references (for completeness, I looked at the equivalent list of
underlying specs for Commands: only POSIX is used there). We should also
add FHS to that list (no interfaces or commands, but it does describe
paths used extensively in the execenv and sysinit chapters). And the
System V ABI documents for the ELF book.
Of these, ISO C and ISO POSIX clearly fit the "documents published by
ISO and/or IEC" rule.
Then we have SUSv2, Large File Support and X/Open Curses ... all owned
by The Open Group. These certainly fit the "wide acceptance and
authoritative status as well as being publicly available" requirement.
I also believe that The Open Group will cooperate with the remaining
criteria.
Then there's SVID issue 3 and 4 ... these are historic, unmaintained
documents. But we have 48 interfaces split between them - the RPC/XDR
stuff. It is possible that these exist in other specs (I have a feeling
there may be an RFC out there on this...not sure). These are definitely
in the "dubious" category! The documents are stable, respected. not
subject to change, but we are unlikely to find anyone at home in AT&T to
agree to the other provisions required.
And finally, there's the System V ABI. Owned by SCO/Caldera. Say no more
...
---
The following docs where originally marked as "Reference":
mysql> select Sshort, Sname from Standard where Stype='Reference';
+--------------------------------------------+-----------+
| Sshort | Sname |
+--------------------------------------------+-----------+
| BSD 4.4 Lite | BSD |
| RFC 1831/1832 RPC & XDR | RPC & XDR |
| IEEE Std 1003.1c | pthreads |
| GNU/Linux | Linux |
| zlib Manual | zlib |
| RPM Package Format | RPM |
| Linux Assigned Names And Numbers Authority | LANANA |
+--------------------------------------------+-----------+
7 rows in set (0.10 sec)
These might want to move to some other class, or at least BSD 4.4 and
GNU/Linux might want to ... perhaps a "Implementation" status?
The following documents move to the "informative" or "reference" class:
+------------------------------------------------------------+
| Sshort |
+------------------------------------------------------------+
| RFC 1831/1832 RPC & XDR |
| IEEE Std 1003.1c |
| zlib Manual |
| RPM Package Format |
| Linux Assigned Names And Numbers Authority |
| Li18nux Globalization Specification |
| PAM |
| RFC 1952: GZIP File Format Specification |
| DWARF Debugging Information Format, Revision 2.0.0 |
| RFC 2440: OpenPGP Message Format |
| Itanium C++ ABI |
| RFC 1833: Binding Protocols for ONC RPC Version 2 |
| RFC 1951: DEFLATE Compressed Data Format Specification |
| RFC 1321: The MD5 Message-Digest Algorithm |
| RFC 1950: ZLIB Compressed Data Format Specication |
| ITU-T V.42 |
| ISO/IEC TR14652 |
| RFC 791:Internet Protocol |
| RFC 2822:Internet Message Format |
| RFC 2821:Simple Mail Transfer Protocol |
| DWARF Debugging Information Format, Revision 3.0.0 (Draft) |
+------------------------------------------------------------+
Does this seem reasonable? I have a sample of this viewable at
http://www.msbit.com:82/LSB/booksets/LSB-Core-generic/LSB-Core-generic/normativerefs
--
Nick