--On Monday, December 10, 2007 11:16 AM -0800 Bob Braden
<braden@xxxxxxx> wrote:
* The RFC Editor discovers that the community doesn't
quite know what to do with the STD number: It can't be
reassigned to the new document because it is at
Proposed. I shouldn't be left on the original
document because it really isn't our latest and best
thinking on the subject. And it shouldn't be
withdrawn because that leads to silly states in
documents that have been written to call on "STD 999"
precisely because those numbers were expected to
refer to current specs.
As I told you at IETF, I believe we can temporarily patch this
problem by adding information to
http://www.rfc-editor.org/rfcxx00.html#STDbySTD; entries like:
RFC#: (none) STD#: 10 SMTP Simple Mail Transfer Protocol
[Was RFC 821,
obsoleted by RFC 2821
(Proposed Standard)]
RFC#: (none) STD#: 10 SMTP Service Extensions [Was RFC 1869,
obsoleted by RFC 2821
(Proposed Standard)]
RFC#: (none) STD#: 10 Mail routing and the domain system
[Was RFC 974,
obsoleted by RFC 2821
(Proposed Standard)]
But this might help newbies, but it would only be a patch.
It is only a patch. If you do it, it is not clear to me what
the STD number (still) accomplishes.
The proposals (from others) to go to IETF-foo-2010 types of
names solves one problem, but does not solve the problem of
needing a _stable_ reference to the current state of a standard,
nor the problem of assignment of designators to Proposed and
Draft Standards. It, too, almost certainly requires an update
to RFC 2026.
I see two fairly simple ways out of this. I also see
opportunities for a whole series of better solutions, but any of
them would require some serious writing and discussion.
IETF-mnemonic-date is included in that list because dates would
need either resolution to days or a suffix and we'd have to
decide whether normative errata changed the dates.
The simple ways:
(1) Decide that STD numbers raise too many complex issues and
just drop them, despite the desire for a standard reference.
(2) Assign STD numbers to Proposed Standards, retaining them
through the process and permitting the STD number to shift to a
Proposed Standard that replaces a Full one. Note that I
proposed essentially that in draft-ietf-newtrk-docid-00, but it
followed ISDs down the NEWTRK hole.
More complex ways include completely different identifier models
(see above), pulling ISDs out of the trash bin, pulling "rfc
sets" out of the trash bin, or trying to patch the various
indexes to simulate one or the other of the latter two.
And, to be a little more explicit than my earlier note was, I
think the entire discussion is a waste of time until the IESG
spends a few minutes deciding what sorts of proposal they would
take seriously enough to process. I'm unlikely to spend more
time on this until they do.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf