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@xxxxxxxxxxxxxxxxxxx]
Sent: Sat 27/10/2007 11:57 AM
To: ietf@xxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf