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@xxxxxxx]
Sent: Mon 10/12/2007 2:24 PM
To: John C Klensin
Cc: ietf@xxxxxxxx
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf