To return to John's issue. It is not enough to have a unique identifier, there
is a stability issue. Here there are two types of stability:
1) The ability to refer to a specific version of a standard in perpetuity: e.g.
our mail server implements IETF-SMTP-2007
2) The ability to refer to a protocol specification without reference to the
specific version, e.g. OCSP over IETF-HTTP transport.
In programming terms the second identifier may be considered to be an abstract
class which must be realised as a concrete class. If IETF-FOO has a dependence
on IETF-HTTP then IETF-FOO-YYY1 and IETF-HTTP-YYY2 must exist such that YYY1 >=
YYY2.
The nice thing about this approach is that we can apply it retrospectively
without having to do a lot of work as we already have mnemonics. The problem is
that we do not have a means of distinguishing FTP (a standard) from HTTP (not a
standard).
On a lexical level I would suggest that the default mnemonic be
IETF-<wgname>[-<specifier>]-<year> where the specifier is optional.
This allows for the various PKIX standards to be grouped together: IETF-PKIX,
IETF-PKIX-OCSP, IETF-PKIX-SCVP and so on.
In the case of a WG that is chartered to revise an existing protocol the name
of the protocol it is chartered to revise is used.
Knowing in advance what the standard name is going to be is very helpful. It
means that we can save an edit pass on documents for the RFC editor. But the
IETF prefix makes it easy to grep for dependencies that are not yet declared a
standard.
But I also agree with John in that this is all pointless unless the IESG can
give direction as to what process they will support.
________________________________
From: Bob Braden [mailto:braden(_at_)ISI(_dot_)EDU]
Sent: Mon 10/12/2007 2:24 PM
To: John C Klensin
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Revising full standards
STD 10" for "support SMTP". Try the exercise of determining
what STD 10 is today
Starting from where we are now, this is not the interesting question.
I would claim that STD 10 is rcurrrently "Reserved for SMTP standard" but the
interesting issue is a hint on where to find the expected
replacement for RFC 821 and friends, ie 2821, in the standards
track.
Bob Braden
_______________________________________________
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