NOTA BENE - WORK IN PROGRESS - Your Inputs & Thoughts
To CAcert.org Policies / COD's - To CAcert.org Policies & Significant Technical Standards - Overview - To CAcert.org Policies - Progress Status
Purpose - Official Document Policy
- Explanation / Compurgation?
General Section - Official Document Policy
COD - CAcert.org Official Document
03
Name of CAcert.org Policy
Official Document Policy
Shortcut of Policy
COD
Author/Editor
Date of WIP
2008225
Date of DRAFT
YYYYMMDD
Date of POLICY Approval
YYYYMMDD
Author/Editor Last Change
Date of Last Change
YYYYMMDD
Place of Policy OFFICIAL VERSION
SVN CAcert.org
Status
WIP
Text - Official Document Policy
FOR INFORMATION PURPOSE ONLY - Place of Policy OFFICIAL VERSION SVN CAcert.org
Table of Contents
- 0. General
- 0.1. Document Information
- 0.2. References
- 1. Introduction
- 1.1. Background on COD document series
- 1.2. How does the documentation work?
- 2. General COD editorial policies
- 2.1. Immutability
- 2.2. Publication Language
- 2.3. Publication Format
- 2.4. Consistent Document Style
- 2.5. Assignment of COD Numbers
- 2.6. References and Citations
- 2.7. URLs in Documents
- 2.8. Abbreviations
- 2.9. Requirement-Level Words
- 2.10. Translating CODs
- 3. Sections in a COD
- 3.1. Title
- 3.2. Table of Contents
- 3.3. "General"-section
- 3.4. Body Section
- 3.5. Citation Sources
- 3.6. Appendices
- 3.7. End-of-Document and Author's (E-Mail) Address
- 4. EOD-Section
0. General
- 0.1. Document Information
- Document-ID: COD3
- Status: wip V0.2
- (C): 2007 Sebastian Kueppers
- 0.2. References
- This document refers to:
-> RFC 2606 (required)
-> RFC 2119 (required)
1. Introduction
- This document provides information for authors of CAcert Official Documents (COD).
- "Official" documents are all documents issued by CAcert Inc. that shall be supervised and versionized for legal (e.g. policies) or handy (e.g. the document how to organize events) reasons.
Policies and other documents that are covered by the Configuration Control Specification (-> COD2) contain a corresponding note in their "general" section (see below).
- It summarizes COD editorial policies and formatting requirements, answers frequently asked questions, and serves as a model for constructing a properly formatted COD.
- 1.1. Background on COD document series
- The CAcert official documents series, short COD, form an archive of documents issued officially by CAcert, Inc.
- 1.2. How does the documentation work?
- The documentation process and the need for officially issued documents can be initiated by CAcert Inc. (by stating the need for an official document on a special subject) or by individuals.
- A document starts in WIP-status (Work In Progess). When it is finished, it will be published on the homepage in DRAFT-mode.
- Draft documents are assigned to a COD-ID by the documentation officer and will be published on the website/SVN. While it is a draft document everybody is asked to revise the document and send comments, errors and additions to the author.
- After a while in draft-status without revision the document will be given "approved" status.
- When a document has reached "approved" status, changes will not be accepted any more. All changes and additions have to be filed as new versions in draft-status. This new version will stay in draft-status for revision as stated above. When a new version of a document finally reaches "approved" status the older version will be marked as obsolete and the new version will officially be published by the documentation officer.
2. General COD Editorial Policies
- 2.1. Immutability
- Since CODs form an archival series they cannot be altered.
- If changes to an approved document are required it has to be filed as a new version and run through the approval process again.
- If a new version of an existing COD is approved it will keep its COD-number but will be given a new Version-ID by the Documentation Officer.
- 2.2. Publication Language
- Official language for CODs is English, in cases of doubt it is en_AU (Australian English).
- Translations are welcome, but will only serve to inform the reader and will not have any legally binding quality.
- 2.3. Publication Format
- CODs are published as HTML files.
- CODs should use HTML-code as simple as possible.
- Other file formats may be used if approved of by the Documentation Officer (e.g. for graphical content or officially issued presentations).
- If file formats other than HTML are used free and interchangeable formats will be preferred.
- 2.4. Consistent Document Style
- The Documentation Officer attempts to enforce a consistent style of CODs. To do this, the Documentation Officer may choose to reformat a submitted COD or ask the author to reformat it. This effort can be minimized if the submitted document matches the style of the most recent CODs.
- 2.5. Assignment of COD Numbers
- COD-numbers are not assigned until late draft status and are assigned by the Documentation Officer.
- 2.6. References and Citations
If a COD refers to another COD or external document these documents must be named in section 0.2. of the specific COD. In text references to external documents they shall be marked with "->". If the named document is essential for understanding and using the COD the tag "(required)" shall be added. References for information only will have no tag or the tag "(informational)".
- Citation sources shall be numbered sequentially in square brackets (e.g. "[1]"). A comprehensive list of citation sources should then be given in an appendix.
References within the same COD-document can be noted as "-> COD x (this document)". Even if the document is an HTML-file the use of (internal) links is not allowed (since links will not work if the document is e.g. printed).
- If a COD requires any other document (another COD or an external document) it can not be given approved status until any required document is given "approved" status.
- 2.7. URLs in Documents
- Since URLs are no stable reference they should not be used in CODs. Exceptions may be made for references in those cases where the URL is the most stable reference available.
DNS names given to examples should make use of the examples defined in ->RFC 2606 ("Reserved Top-Level DNS Names") to avoid conflicts with existing domains.
- 2.8. Abbreviations
- Abbreviations should be written out when used for the first time, except for common abbreviations which everybody will easily recognize. The Documentation Officer will make the final judgement weighing obscurity against complexity.
- 2.9. Requirement-Level Words
Some documents contain certain capitalized words ("MUST", "SHOULD", etc.) to specify precise requirements for technical points. In COD's these words are interpreted according to ->RFC2119. If other capitalized words are used the correct interpretation must be specified in the document. Abusive use of required-level words must be avoided. The words are intended to provide guidance to implementors about specific technical features or legal affairs.
- 2.10. Translating COD's
- The translation of COD's into another language is permitted. However, the original author and/or the Documentaton Officer should be informed of such translations. . Translations will be listed on the documentation homepage. Translated versions are for informational use only, see section 2.2. of this document.
3. Sections in a COD
- A published COD should contain the sections in the following list. Some of these sections are compulsory, as noted. The shown order is required if no good reasons are given as to why the order should be different.
- I. Title (required)
- II. Table of contents (required)
- III. "General"-section (containing document information and references, required)
- IV. Body Section (required)
- V. Citation Sources
- VI. Appendixes
- VII. End-of-Document and Author's (email) address (required)
- 3.1. Title
- Choosing a good title can be a challenge. A good title should represent the scope and purpose of the document without being either too general or too specific.
- 3.2. Table of Contents
- A table of contents (TOC) section shall provide a quick overview of the different sections in a COD.
- It can be left out in very small CODs, in cases of doubt the Documentation Officer will decide.
- 3.3. "General"-Section
- The "general" section contains the general document information (COD-ID, status, copyright) and the list of references. If a table of contents is available this section is usually lablled as section "0".
If a COD is a policy of CAcert Inc and/or controlled by the "Configuration Control SpecificationConfiguration Control Specification" (-> COD2) this fact is stated in this section, too.
- 3.4. Body Section
- The general section is followed by the document body.
- Each COD should have an introduction that explains the motivation for the COD and (if appropriate) describes the applicability of the document.
- 3.5. Citation sources
- If citations are used in the document the specific citation sources should be listed here. There is no specific format required since citation sources can vary.
- 3.6. Appendices
- The appendix-section can be used e. g. for detailed information on technical focuses. Usually appendices are numbered from "A"..."Z" (e.g. "Appendix A") and can be sub-sectioned ("A.1", "A.2").
- 3.7. End-of-Document and Author's (E-Mail) address
- The last section of any COD-document should contain the author's email-address (so that comments and additions can be addressed directly to the author). If no author is known or if he is otherwise unavailable this will be the Documentation Officer's address.
The very last item of any document is the end-of-document-note coded as "<-- END OF COD xx -->". All text below this note does not belong to the document any more.
End of Official Document Policy
Inputs & Thoughts
YYYYMMDD-YourName
Text / Your Statements, thoughts and e-mail snippets, Please
YYYYMMDD-YourName
Text / Your Statements, thoughts and e-mail snippets, Please
Category or Categories