Phillip Hallam-Baker wrote: > > On a lexical level I would suggest that the default mnemonic be > IETF-<wgname>[-<specifier>]-<year> where the specifier is optional. I expect specialists will continue to prefer the raw RFC numbers and I doubt that others (including many decision makers) care about working group acronyms. Keep it short, as was originally proposed: IETF-<protocol> and IETF-<protocol>-<minimal-date> <minimal-date> can be a 4-digit year where that suffices, or something longer (year + letter suffix?) when multiple documents superseding or extending each other are published in the same year. I foresee another problem, however. SMTP remains the Internet's email protocol, after decades of use and extending. Yet things could have turned out differently. Protocols *can* get pushed aside by challengers that aren't their descendants. For example, suppose a completely different protocol called IEP (Internet Email Protocol) arises in the future and, due to its vastly superior characteristics, becomes the dominant mail transport system. SMTP would then become historic and IEP would need to be marked as the current standard. Under these circumstances, an IETF-SMTP label proves a poor choice. The usefulness of the STD-10 label, however, is unaffected. So perhaps the generic, undated labels proposed above should be based on service descriptions rather than protocol names: IETF-<service type> and IETF-<protocol>-<minimal-date> Eg: IETF-EMAIL = STD-10 -> IETF-SMTP-1986 IETF-SMTP-1986 = RFC-821 IETF-SMTP-2001 = RFC-2821 > [but this lacks a] means of distinguishing FTP (a > standard) from HTTP (not a standard). I would argue that the real world thinks both are equally standard. Which brings me to my final point. I am fully in favour of a symbolic naming convention for STDs. But that won't help rejuvenate the STD series -- symbolic names are *already* used by people who aren't immersed in the standards process. Eg people refer to the email transport protocol as SMTP, not STD-10. I think that, for implementors and adopters alike, a single, absolute definition is too simplistic a view to be meaningful in today's world. Merely renaming the STD series won't solve the problem of deciding when/if the STD-10 / IETF-EMAIL pointer should be changed from RFC-821 to RFC-2821. But that's a bigger can of worms. BTW, can anyone point me to documentation of previous attempts to solve that bigger can of worms? -ic _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf