Iain Calder wrote:
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.
I think that that depends upon whether the <protocol> label defines a technology or a function. (This is in line with your later discourse, I believe.) The word <protocol> is rather specific and says that the label applies to a particular technology.
The usefulness of the STD-10 label, however, is unaffected.
Well, it's difficult to go below zero utility...
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
I think that we ask for trouble if we use a service-oriented label. It invites the conflict that you cite, as well as trying to encompass too much.
There are simply too many technologies that are covered by service terms, like "email" or "web" or "routing" or "transport".
In fact, particular technologies, like SMTP and SIP, have more than enough specification pieces, to warrant a particular label, IMO.
d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf