Yes. My position is that RC2 cannot even be an optional part of the
specification unless it is released from trade secret restrictions. As a
trade
secret the most it can be is an informational part of the specification, and
preferably in a separate, informational document.
I don't see the difference between my saying that the algorithm "can be
used, but not as a MUST" and you saying that it can be "an informational
part of the specification". Both seem to refer to optional algorithms
that can be used with the protocol.
I beg to differ. An optional part of a formal protocol specification is still
part of the specification. As such, it carries with it the IETF imprimateur and
all it implies -- it must undergo design and security analysis, it must meet
interoperability requirements, and so on. And perhaps more to the point,
anything described as a formal part of the protocol will be seen as something
implementations must provide; the labelling of mandatory versus optional tends
to be overlooked for the most part.
An informational document or appendix, on the other hand, is lightyears away
from this. An informational document is simply something someone decided to
publish. It is nothing more than that. It can be entirely cogent and relevant
or it can be the documented ravings of a lunatic. (And I'm afraid there are
RFCs that come very close to falling in the latter category.) It can be
extremely useful or an April Fool's prank. Other than the RFC editor and an
occasional IESG disclaimer, the IETF doesn't assess, bless, or condemn
informational documents in any way, shape, or form.
This is why the standards track designation is so important and why there's
an essential and fundamental difference between informational documents and
optional protocol elements in standards-track specifications.
As far as a separate, informational document, Steve Dusse and the
original S/MIME vendors had originally drafted the S/MIME spec using
both a message specification (that talked about the MIME types and the
use of multipart/signed), and an interoperability profile (describing
the exact algorithms to be used in the specification). The latest
S/MIME draft fused these two documents together, and I'm not sure if
that was the best idea.
The form the material takes it totally irrelevant. As a practical matter the
RFC editor will require separation of informational material from
standards-track material prior to publication, but this isn't something we
need to worry about at this time.
I agree that algorithm specifics are best left
to a separate document -- that way, in the event that the algorithms
change for cryptographic or other reasons, the only document that needs
to change is the one that specifies the algorithms. The other documents
(in this case, the overall MIME message format and the S/MIME
certificate handling) will be unchanged.
We've been down this path many times before and dealt with this particular
problem in various different ways in different protocols. The bottom line is
that there's no good answer -- if you separate the material people will have
trouble putting the pieces together and if you don't people will have trouble
taking them apart. Experience has shown you cannot win on this one.
But be this as it may, it still simply isn't at all relevant to the issues at
hand.
P.S. I am also somewhat offended by your dismissive term "cranky" here.
There are sound technical and procedural reasons for the position I've
taken here.
Yes, you've voiced them, and you've whipped yourself into a frenzy (the
"vociferous objection" paragraph from your last message. I have trouble
spelling it). The point that I was making by trivializing your position
as "being cranky" is to lighten the mood. I'm sorry if it offended you,
but I think that you got much too fired up about this.
You just can't seem to get away from being dismissive and condescending, can
you? Anyway, as far as "whipped into a frenzy" goes, I am not in anything even
remotely resembling a frenzy over this issue. (Some of you probably remember
some of the heated exchanges during the development of MIME; this present
matter pales into insignificance in comparison to those.)
All I have done here is make the extent and depth of my opposition to the
inclusion of RC2 with IP baggage attached in an IETF standard clear. And if you
think I'm joking, that this is simply a passing fancy of mine, or that I'm
making a mountain out of a molehill you are seriously mistaken. I meant every
word I said and I will do everything I said I would do should it become
necessary to do so.
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.
And as far as I can tell it is. I will also point out that I sustantive
experience in this area, as I have in the past been forced to remove optional
protocol elements on the basis of IETF rules from documents I've edited, and
I'm pretty sure I will have to a lot more of these removals from documents I
edit in the future. (And no, I don't like having to do this, but I also
understand that there are very good reasons for us having the rules we do and I
have to follow them just like everyone else.)
Please let me know if I have misunderstood
your statement about its inclusion as an informational part of the
specification as being equivalent to the OPTIONAL use of RC2.
My statement stands. My assessment is that RC2 cannot even be an optional part
of a standards track specification unless its IP status changes.
Ned