If we create confusion by labelling everything RFC we are going to feel the ill
effects caused by that confusion.
I know we keep comming across the problem that the RFC numbers are welded into
the infrastructure and nobody seems to want STDs. But we still have a problem.
Perhaps a variant of Klensin's suggestion of documents describing a set of
standards. If this was reduced down to the bare essentials of merely a set of
references we might have documents of the form:
IETF-SMTP-2007
[boilerplate]
The following documents are normative components of the SMTP standard:
RFC 2821
RFC 2822
The following documents are not part of the SMTP standard but SMTP has
normative references to them:
None
The following documents are non normative:
[whatever]
[IPR boilerplate]
There would be no other content. The document would be credited to IETF.
Such a document would replace the current STANDARD designation. All the
documents referenced in such a document would have to be DRAFT or better on
submission and would automatically become STANDARD status on the document being
published.
This would not represent a significant change in current practice except to the
extent that at present almost all protocols stick at DRAFT.
I would anticipate there being relatively few such standards but the terms are
much more likely to be used. I am not going to remember two sets of numeric
designations and I don't think anyone else will either.
Switching from the term STD to IETF reminds people of where the documents come
from. It also avoids an unfortunate choice of acronym. Semiotics do matter.
The use of a year designator would allow reference to be made to a particular
version of the SMTP specification if that was appropriate. Year designators are
preferred over version numbers in this case as version numbers have semantics
associated with them. They also remind people when a standard has not been
revised for some time.
________________________________
From: RJ Atkinson [mailto:rja(_at_)extremenetworks(_dot_)com]
Sent: Sat 27/10/2007 11:57 AM
To: ietf(_at_)ietf(_dot_)org
Subject: Silly TLS Auth lobbying
Some important things that the FSF folks seem NOT to understand,
and frankly seem to aggressively NOT want to understand, are:
- Many RFCs are *not* on the IETF standards track.
- Any "Experimental RFC" is *not* on the IETF standards track.
So there is no "endorsement" by IETF in publishing such.
- The IETF has published real standards-track documents that
required patented technology and were known to have
*difficult* license terms on the publication date (think
cryptographic algorithms and scan backwards in rfc-index.txt).
- There is no history of IETF requiring technology to be freely
available (for either common definition of free).
I support the idea that virtually any document ought to be able
to be published as an Informational RFC or Experimental RFC.
Technology that is useful will be adopted if economically sensible,
whether in an RFC or not, whether made a formal standard or not.
By having an open specification, users can at least understand
the properties of the technology that is documented openly.
Just to be crystal clear, I do support publishing draft-housley-*
as either Informational RFC or Experimental RFC.
Yours,
Ran
rja(_at_)extremenetworks(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf