What the IETF cares about is that proprietary algorithms not be
REQUIRED, or even mentioned, in Standards Track specifications when
suitable non-proprietary alternatives are available. Freely-available
symmetric algorithms exist in abundance, hence RC2 does not belong in the
IETF-S/MIME Standard.
The specific language is at the end of section 7.1.2 in RFC 2026:
The IESG generally should not favor a particular proprietary
specification over technically equivalent and competing
specification(s) by making any incorporated vendor specification
"required" or "recommended".
Note that this constrains the IESG, not an IETF working group, and it
has to do with whether the IESG should recommend or require one
technology over another, not whether a technology can be placed on the
standards-track. (Note also that it says "generally should not", not
"must not".)
IETF process rules do not prevent a working group from choosing a
proprietary technology, even when non-proprietary alternatives are
available. Instead, we trust the working groups to make informed and
intelligent choices based on all appropriate criteria -- not just on
whether someone claims that a technology is their property.
Regardless of the legal standing of the clean-room implementation,
regardless of the existence of a published specification for RC2 (as an
Information RFC, for example), there will always be the the threat of
legal action unless RSA changes it's position. The IETF's agnosticism
on the validity of the claims is irrelevant - RSA's opinion, valid or
not, is what counts.
This may indeed be what counts in the minds of some working group
participants, and such individual considerations may have an effect on
the group's consensus.
Keith