*> *> 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 I believe that moving specs to HISTORIC is sometimes problematic. It it intended to give the highest-order one bit of a much more complex applicability specification. Even if IEP begins to take over from SMTP, SMTP will continue to be in use in many, many places. It seems to me it should continue to be a STANDARD, with another document saying that IEP > SMTP for most applications. Postel took the (reasonable) viewpoint that once a standard, always a standard. So, I would favor giving IEP a new STD number (or name, or whatever), since it is a DIFFERENT standard than SMTP. *> circumstances, an IETF-SMTP label proves a poor choice. *> The usefulness of the STD-10 label, however, is unaffected. *> ... *> *> 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. Actually, I most often hear people refer to it as "RFC 821", which MUST be wrong... a document designation (like an ISBN number) should not be the label for a standard, particularly since some (many?) standards will have multiple component documents. Bob Braden *> *> 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