On Feb 16, 2010, at 5:23 PM, Peter Murray-Rust wrote:
> One of the most valuable sets of specifications is the IETF drafts. They have
> no legal force but they are explorations of whether a particular
> specification would be useful to the community. Utlimately with time many
> become de facto. They are characterised by
>
> "rough consensus and running code"
When you say "IETF draft" you can mean several different things. RFC 2026 says
The Internet Standards Process -- Revision 3
...
An Internet-Draft is NOT a means of "publishing" a specification;
specifications are published through the RFC mechanism described in
the previous section. Internet-Drafts have no formal status, and are
subject to change or removal at any time.
********************************************************
* *
* Under no circumstances should an Internet-Draft *
* be referenced by any paper, report, or Request- *
* for-Proposal, nor should a vendor claim compliance *
* with an Internet-Draft. *
* *
********************************************************
Quite clearly this is not the draft of which you speak. Instead, you likely
mean the "draft standard" which is the 2nd of 3 IETF standards track maturity
levels. (There are also non-standards track maturity levels.)
RFC 2026 section 4.1.2 goes into the details of what a "draft standard" means:
A specification from which at least two independent and interoperable
implementations from different code bases have been developed, and
for which sufficient successful operational experience has been
obtained, may be elevated to the "Draft Standard" level.
It gives a very stringent criteria for what's acceptable. For example:
In cases in which one or more options or features
have not been demonstrated in at least two interoperable
implementations, the specification may advance to the Draft Standard
level only if those options or features are removed.
I don't think SMILES passes this test, because I'm not aware of tools which
handle the higher symmetry definitions, including the Daylight toolkit.
On the other hand, you said a drafts are "explorations of whether a particular
specification would be useful to the community", and that's weaker even than
the "Proposed Standard" definition (first of the three standards maturity
levels):
A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.
since even a Proposed Standard has to "enjoy community interest" in the present
tense, vs. "would be useful" in the future.
So I don't know what you mean when you say "IETF draft." Has RFC 2026 been
superseded?
> If you try to formalize this by requiring various processes it will start to
> kill it. If you insist that anyone can modify it and redistribute other
> versions which are incompatible with the original you destroy its value.
No copyright statement can prevent "embrace, extend and extinguish". No
copyright protections prevented the Browser War of the late 1990s. Indeed, the
specs played catch-up to Netscape and (to a lesser extent) IE.
Or, if you want to prevent "embrace, extend and extinguish" then you have to be
very careful to not prevent "embrace, extend then innovate."
> I am happy to draft some principles which address what an Open Specification
> is.
"in the context of Blue Obelisk", yes? Since "Open Specification" and
variations already have existing meanings which I have no problems with:
- http://en.wikipedia.org/wiki/Open_specifications
- http://en.wikipedia.org/wiki/Open_standard
- http://en.wikipedia.org/wiki/Open_format
- http://perens.com/OpenStandards/Definition.html
- http://OpenWebFoundation.Org/legal/agreement/
These came up during the previous discussions of this topic on this list. It's
the additional requirements (paraphrasing and exaggerating a bit "must have a
reference open source implementation", "must be available for free download and
redistribution") that I have specific problems with.
I also have specific problems with the idea that format specifications which
are fully documented in the open literature (like SMILES) are considered not
open because they a RAND fee to get a copy of the document (or free through a
good library) and copies cannot be redistributed freely.
And I have problems with the idea that someone must maintain the project in
perpetuity in order for it to be "open." Is WLN not open because there is no
real community and no one is accepting updates to the documented specifications?
Andrew
[email protected]
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Blueobelisk-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
