On 2007-12-11 09:24, John C Klensin wrote:
--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.
It's a new way into the maze and I think it's worth doing quickly, since
it doesn't misrepresent the formal standards process in any way. Ideally,
www.rfc-editor.org/smtp and www.rfc-editor.org/STD10 would also
take you straight there too. (Tools prototype?)
<snip>
(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.
I agree with this. Thus a standard would be somewhere in a loop:
PS10-->DS10-->STD10-->|
^ |
|_____________________|
Brian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf