Proposal 5.1: OGDI Proposal Guidelines
Author: Frank Warmerdam, 3i, firstname.lastname@example.org
Last Edited: 2001/02/12
Guidelines for authoring, reviewing, approving, archiving, referencing,
retiring OGDI related proposals within the venue of the OGDI Working Group.
Proposals are intended to include procedural issues (such as this proposal),
and technical proposals for changes to OGDI. OGDI Proposals are intended to
play a similar (if less formal) role to
within the Internet Engineering Task Force.
Provide a streamlined, but uniform and transparent
methodology for managing procedural and
technical proposals within the OGDI Working Group.
- Proposal: A proposal is a document describing technical changes
or clarifications for OGDI as well as procedural definitions for
use within the OGDI Working Group (and by 3i staff working on OGDI).
It is intended that Proposals are for more major changes than bug fixes, and
should be prepared for changes and additions for which a permanent record is
- Proposal Author: The origining person who writes the proposal,
and submits it to the OGDI Working Group. This person should be a member
of the OGDI Working Group, or have a sponsor on the working group willing to
speak on behalf of the proposal.
- Proposal Editor: A person responsible for keeping
maintaining the OGDI Proposals web page, and keeping track of proposals,
their status and so forth. The editor will make minor editorial changes to
proposals as necessary, and may be required to make updates as directed by
the OGDI Working Group after a proposal has been adopted.
This person is designated by the OGDI Working
Group, and will usually be a 3i staff member.
Proposals are authored by a Proposal Author. Proposals may be
solicited by the OGDI Working Group, or submitted unsolited by interested
parties. Proposals authors must be a member of the OGDI Working Group, or
have a sponsor on the working group willing to speak on it's behalf.
Proposals are intended to be written in HTML roughly
following a provided template
(a proposed template is available at
Once prepared, proposals should be submitted to the Proposal Editor who
will place it on the
and the author should also distribute the
proposal to the OGDI Working Group (and other appropriate public venues) for
review and consideration. Ideally there should be at least two weeks for
public review before the OGDI Working Group considers accepting the proposal,
but this is not a strict requirement.
In response to feedback, or for any reason, the author may revise the
proposal and distribute new versions. However, each time this occurs the
revision number should be incremented, and the proposal updated on the
OGDI Proposal web site.
Proposals are intended to contain the following items:
Also, the proposal should try to provide a justification for the proposal,
if practical include examples. Technical changes should be spelled out
as precisely as possible, as the proposal will become the reference on
technical change for future reference. A reasonable effort should be
made to keep the proposal document independent of links or reference to
other resources likely to have a limited lifespan.
This is a proposal number, followed by a document revision
number, and a name. For instance "5.1 OGDI Proposal Guidelines" would be
proposal number 5, revision 1, named Proposal Guidelines. The proposal number
is assigned by the Proposal Editor. While in the Proposed status the author
may produce new revisions at will, but should increment the revision number
The author (and the sponsors if applicable) name and contact information.
- Proposed/Last Edited Date:
The date the proposal was initially prepared, as well as the date it was
- Status: Initially this is always "Proposed". If
accepted by the OGDI Working Group it becomes "Accepted". If not accepted
by the OGDI Working Group it becomes "Declined". If withdrawn by the
author before a decision it becomes "Withdrawn". If after acceptance it is
superceeded by newer proposals, subsumed in a specification, or ended by
the OGDI Working Group, the status becomes "Retired".
- Summary: This is one or two paragraphs giving a general
description of what the proposal is about. This should be the first
section of any proposal, and named "Summary".
- Compatibility Issues: Any proposed technical changes to OGDI
should have a section on what backward compatibility issues the proposal
will raise, and it is proposed that they be dealt with.
This section should also address what reversion of OGDI the proposal applies
to, and what extension tags if any indicate support for a proposed extension.
Proposals or ammendments
may be accepted or declined by a majority vote of OGDI Working Group members
present (in person or by proxy) in a meeting of the OGDI Working Group.
At this point, the proposal (with ammendments) is passed on to the 3i Board
of Directors for final approval.
Proposals, or amendments to proposals may be approved outside a working
group meeting by issuing the proposal on the OGDI Working Group mailing
list if there is no opposition within five working days.
Proposals may be accepted with verbal amendments in a meeting. The
Proposal Author, or Editor should apply the amendments, and redistribute
the amended document for five days review on the OGDI Working Group email
list before the document becomes accepted.
The Proposal Editor may revise accepted proposals for clarity without
a review period, as long as the changes do not alter the original intent.
The Proposal Editor is responsible for only updating accepted proposals
if the change has been accepted in accordance with the above procedures.
Changes and updates to an existing approved proposal are normally accomplished
by issueing a new revision of the proposal rather than issuing a whole
new proposal. Substantial changes may be accomplished by issuing a new
proposal, with a new proposal number. Superceeded proposals should
be retired by the OGDI Working Group, with a notation referencing the new
proposal that superceeds the old proposal.
Proposals adopted into new revisions of the OGDI Specification document
may be retired.
Retired proposals are always kept available for reference. Older proposal
revisions should also be preserved (perhaps only within CVS). Proposals
withdrawn by the author, or declined by the working group may be kept available
for review as the Proposal Editor sees fit.
Proposals should not contain restricted intellectual property. Proposals
may define ways of integrating, or utilizing proprietary technology, but
the proposed interfaces should be open for anyone to implement. In situations
where this is impossible, and a proposal is still called for it, should make
clear any copyright, patent or other encumberance applying to the proposal.
Approved Proposal Authority
It is intended that proposals be used to establish and documenting working
procedures for the OGDI Working Group, and document technical clarifications
and improvements to the OGDI technology. In general they would be considered
recommendations, and do not carry the same weight as an OGDI Specification
document approved by the 3i Board.
Furthermore, approved proposals do not have the power to force 3i to spend
money, modify staffing and so forth. However, they should be considered to
be strong recommendations for how existing 3i staff resources allocated to
OGDI be applied, and how 3i maintains OGDI. Proposals for new projects
to be undertaken by 3i, or requests for funding should not be directed
through this mechanism.
Previous proposals did not match this proposal, and have been updated to
do so. No other compatibility issues are forseen.