I don't see the relevance of a service label such as 'email' in the context of standards identifier either.
I do not think that there is any real likelihood that SMTP will be displaced by another email protocol ever. When SMTP is displaced it is going to be displaced by something that offers more functionality than mail. Probably some form of hybrid protocol that seamlessly integrates asynchronous and synchronous messaging.
So lets return to my actual proposal rather than the strawman. IETF-SMTP is the designator for the class of SMTP protocols, IETF-SMTP-2007 would be the designator for the latest incarnation to be designated as a standard.
STD10 corresponds to IETF-SMTP. In my view it is an almost useless designator as currently used because it means nothing. If someone tries to refer to STD10 they cannot refer to a specific version.
There is a context in which I would like to be able to refer to an abstract class and that is in the area of crypto protocols. Imagine that IETF-CRYPTO refers to the set of currently recommended algorithms for use in IETF protocols.
IETF-CRYPTO-2007 probably looks something like RSA-2048, SHA256, AES-128.
IETF-CRYPTO-2020 will probably look something like ECC-XX, SHA3-512, AES-256
I would argue that if we have done the job of specifying a cryptographic protocol standard correctly we have also specified the interface to cryptographic algorithms. It should be possible for a specification to make a statement of the form 'implementations MUST support the bulk encryption cipher specified as required in IETF-CRYPTO-2007 and successors.'
What this then allows us to do is to define specifications for S/MIME, TLS, IPSEC, etc. in such a way that they upgrade automatically. Once an algorithm is a MUST implement it becomes essential for interoperation more or less in perpetuituy.
Clearly there would be a likelihood of some fixup work that was protocol specific to be specified. I would expect that the IETF-CRYPTO-XXXX RFCs would point to other RFCs defining algorithm identifiers, parameters and in some cases fixups for specific protocols (e.g. definition of CBC mode).
This approach has the potential to save the IESG a whole heap of work in future years. Instead of having to re-process every one of the underlying protocol specifications independently there is a single set of work. We are likely to get better consistency as well, we are more likely to discover peculiar situations where different specifications take different positions on padding, endian-ness and such.
The crypto area is somewhat constrained, we have a fairly strong consensus as to what crypto algorithms make up the cannon. I don't think the same applies to many other areas. I don't think we are likely to come to a unanimous agreement as to what a single canonical IETF-WEBSERVICES-XXXX might be, but we might be able to come to agreement on what IETF-WSHTTP, IETF-WSBEEP, IETF-WSSOAP mean and then let market forces, support in Web Services platforms etc eliminate the superfluous options.
I simply cannot see the same mechanisms evolving if we stick to the STD-10 approach. Its a machine code approach. I know that we worked at the machine code level in the 1980s. I was programming machine code myself in those days. Later on I wised up and got myself an asembler.
I have a limited number of memory slots for opaque numeric identifiers and they are all full.
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