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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf