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.
________________________________
From: Dave Crocker [mailto:dhc2(_at_)dcrocker(_dot_)net]
Sent: Tue 11/12/2007 12:24 PM
To: Iain Calder
Cc: ietf(_at_)ietf(_dot_)org; Hallam-Baker, Phillip; John C Klensin; Bob Braden
Subject: Re: Revising full standards
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