The only reason I stepped into this discussion was to clarify whether or
not the OPTIONAL use of RC2 is a violation of IETF guidelines, and as
far as I can tell it isn't.
At least for the case of MIME content-type names, we allow assignment
of names for proprietary content-types. This was simply pragmatic:
there were (unfortunately!) too many proprietary content-types that
people wanted to use in MIME, (and were going to be used no matter what
the IETF said) and we're better off having them clearly labeled.
I don't think this comparison is appropriate or useful. A much better
comparison would be to the members of the base set of content types defined in
the MIME specification. And in this case, as part of a standards-track
document, I have had to fight very hard to retain the set that's there now. (At
one point it even looked like there would be no primitive types in there other
than text/plain.)
In particular, it has been a major struggle to retain application/postscript,
even though this is an entirely optional part of the specification, the
specifications for PostScript are readily available and have no associated
confidentiality restrictions of any kind, there are lots of interoperable
implementations, a reasonably complete and comprehensive security analysis was
done early one, and so on. It also looks fairly likely that I'll be asked to
remove multipart/parallel from the base MIME specification and instead move it
to an informational document, simply because there don't seem to be a
sufficient number of agents that generate it on a regular basis to demonstrate
interoperability.
I imagine that the working group will want to use some kind of
algorithm identifier to specify what kind of encryption is being used.
If so, the working group could decide the rules governing assignment
of algorithm identifiers, and (for example) whether the algorithm had
to have a published and openly available specification. My guess
is that a set of workable rules would end up being much like those
for MIME types.
I agree but I don't think this is the point. The point is what ends up in the
base standards-track document defining S/MIME. I have no problem whatsoever
with a separate informational document that begins with a big disclaimer saying
the IETF hasn't blessed this in any way and then defines RC2 to some extent and
then says that its OID should you care to use it is such-and-such.
Ned