Re: Revising full standards

[John C Klensin <john-ietf at jck.com>]

--On Monday, December 10, 2007 11:16 AM -0800 Bob Braden 
<braden at ISI.EDU> 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 mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf